Project Close

Step 1: Commit the Project to Git

The model is trained, evaluated, and serving predictions. The work is done — but right now it only exists on your machine. If your laptop dies tomorrow, everything disappears: the data pipeline, the training code, the evaluation output, the serving endpoint, the prediction logs.

Check materials/CLAUDE.md for the commit convention. Direct Claude to stage and commit all project files with meaningful commit messages — not one giant commit, but logical units of work. Something like: "Commit the project files to Git. Use separate commits for the data pipeline, the training and evaluation code, the serving code and prediction logs, and the project materials. Use imperative mood in the messages — 'Add data profiling notebook', 'Train RandomForest with balanced class weights', 'Build FastAPI serving endpoint with request logging'."

Review what Claude stages before each commit. You should see the full arc of the project: the data profiling and preprocessing work, the model training and evaluation, the API endpoint and logging, and the materials that started it all. Each commit message should tell a future reader what that piece of work accomplished — not "update files" or "add code," but what was actually done and why.

Step 2: Push to GitHub

Direct Claude to create a GitHub repository and push the project: "Create a new GitHub repository called ml-p1 and push all commits to it."

Once the push completes, open the repository in your browser. Verify the files are there — the notebooks, the serving code, the materials directory, everything you just committed. This is the first time your ML work exists somewhere other than your local machine. If you share the URL, anyone can see what you built.

Step 3: Write the README

A repository without a README is a locked box. Someone visiting the repo — including you, three months from now — sees a list of files with no explanation. The README is the front door.

Direct Claude to write a README for the project: "Write a README.md that describes what this project does, what the model predicts, the evaluation results in plain terms, and how to run the API endpoint. Keep it concise — someone should understand the project in under a minute."

The README should cover four things: what Emeka's problem was (subscriber churn eating into Tunde Mobile's base), what the model does (predicts churn probability for individual subscribers using a RandomForest trained on twelve months of billing data), how well it performs (translating the recall figure into something concrete — out of every 100 subscribers who actually churn, the model catches roughly 55-60 of them), and how to use the API (start the server, send a POST request with subscriber features, get back a probability).

That translation — from "recall >= 0.55" to "catches 55 out of 100 churners" — is professional communication. The metric is for you. The translation is for everyone else.

Commit the README and push it. Refresh the GitHub page. The README now renders below the file listing.

Step 4: Deliver to Emeka

Emeka has been waiting. He sent you subscriber data and a clear request: tell me which customers are about to leave, ranked by risk, through an API my team can call every week. You built that.

Write him a final message. Not a technical report — a delivery note. Cover what matters to him: the model predicts churn probability for individual subscribers, his team can query the API with a subscriber's features and get back a risk score, the highest scores go to the top of the call list. Translate the evaluation results into his language: "Out of every 100 subscribers who would actually leave, the model flags roughly 55-60 of them. Your team calls those first."

Mention one thing about the road ahead. The model was trained on twelve months of historical data — subscriber behavior as it was, not as it will be. If Tunde Mobile launches a new pricing plan, expands to a new city, or changes their onboarding flow, the patterns in the data shift. The model does not know about changes it has never seen. Six months from now, the predictions may drift.

Emeka responds: "This is exactly what I needed. My team starts using it Monday." Then he pauses. "What happens in six months? If our subscribers' behavior changes, will the predictions still be good?"

That is the right question. The honest answer is: probably not, at least not as good as they are today. The prediction logs you added in Unit 4 are the early warning system — if the model starts returning the same probability for every subscriber, or if Emeka's team reports the calls are not working, the logs will show the drift. Retraining on fresh data is the fix, but that is a future project. For now, acknowledge the concern and tell him the monitoring is in place.

Step 5: Review the Loop

Step back and look at what you did across the entire project.

You started with Emeka's brief and a dataset. You profiled the data — 7,000 subscribers, 8% churn, fourteen features — and that profile shaped everything that followed. The class imbalance meant accuracy was a trap. The missing values in monthly charges and total charges required imputation decisions. The categorical features needed encoding.

Then you trained a model and evaluated it against a target Emeka cared about: can it catch the subscribers who are leaving? Not "is it accurate" — the 92% accuracy number would have been meaningless. Recall on the churn class was the metric that mattered, and the inline check caught it.

Then you moved the model from a notebook to a running API — a service anyone can call. You tested it, handled edge cases, added logging. And you delivered it with documentation and a message Emeka could act on.

That sequence — profile the data, preprocess, train, evaluate against a meaningful target, serve, document, deliver — is the loop. Every project after this one repeats it. The terrain gets harder: messier data, more complex models, trickier evaluation targets, real deployment constraints. But the loop is the same. What changes is the difficulty of each step, not the steps themselves.