Serving and Documentation

Step 1: Review the Serving and Documentation Tickets

Open materials/tickets.md and find tickets T20-T23. The tasks: serve the best model as a FastAPI endpoint, produce board-facing evaluation documentation, update the PRD with actual results, and get Emeka's sign-off on the documentation.

Step 2: Serve the Model

Direct Claude to build a FastAPI endpoint for the best model from Unit 4. The endpoint should accept subscriber features as JSON and return a churn probability and a binary prediction. This is familiar from P1 -- the serving pattern is the same.

Test with curl. Send a sample subscriber's features and verify the response includes a probability between 0 and 1. This should be faster and more confident than P1's serving work. The endpoint itself is not the new terrain here -- the documentation is.

Step 3: Write the Evaluation Documentation

Direct Claude to produce a board-facing evaluation results document. This is not a technical report. It's what Emeka puts in front of people who don't know what F1 means.

The document should include: an executive summary, the approach taken, per-segment results in business language, comparison against baselines, and recommendations. "The model correctly identifies approximately 6 out of 10 prepaid customers who are about to leave, compared to the previous model which caught fewer than 3 out of 10" says more to a board than "prepaid recall improved from 0.28 to 0.58."

Direct Claude to draft it, then review. Every metric should have a business-language translation alongside the number.

Step 4: Update the PRD

Open the PRD you wrote in Unit 1. The Success Criteria section defined what you were trying to achieve. Now compare: did the model meet those criteria? Where did it exceed them? Where did it fall short?

Direct Claude to add an "Actual Results" section to the PRD. This closes the loop on the planning artifact -- the PRD started as a promise, and now it records what actually happened. The gap between planned and actual is itself useful information.

Step 5: Emeka's Review

Send the evaluation documentation to Emeka for board readiness review. He'll read it and give feedback.

His likely reaction: "This is good, but my board won't know what 'F1 score' means. Can you add a line that says something like 'the model correctly identifies X out of Y prepaid customers who are about to leave'?" He wants business language, not metric names.

This pushes one more translation round. The documentation is done when someone who has never seen a confusion matrix can understand what the model does, where it works, and where it doesn't.