Deliver and close

Step 1: Send the findings to Wanjiku

The analysis is done. The report is verified. Every number in it traces back to the notebook, and the notebook runs clean from top to bottom. Now deliver it.

Send the findings report to Wanjiku through the chat. Do not just attach the file — include a brief message summarizing what you found. Something like: the overall no-show rate is in the low teens (with the confidence interval), and vaccination follow-ups are the worst category by a clear margin. Give her the headline so she knows what she is opening.

This is the moment where the analysis meets the question that started it. Wanjiku asked how bad the no-show problem is, what the patterns look like, and whether it is getting worse. The report answers all three. If it does not — if one of those questions fell through the cracks — you will find out in the next step.

Step 2: Read Wanjiku's response

Wanjiku responds the same evening. She is pleased. She has been guessing at these numbers for months, and now she has real ones she can show her staff. She mentions that the vaccination follow-up finding matches what she suspected — those clients book the follow-up and then decide their pet seems fine and skip it.

She says she is printing the visit-type chart for the wall behind reception so her team can see which appointment types need the most follow-up calls.

If your analysis included the client tenure breakdown, she asks about it — she had not thought about new versus returning clients before, and the difference surprises her. If you did not include it, she asks whether new clients and returning clients behave differently. Either way, she is pointing at something in the data you may or may not have explored.

This is the client feedback loop. You delivered work. The client read it. Now she is asking a question that either confirms your analysis covered the right ground or reveals a gap. Both outcomes are useful.

Step 3: Address Wanjiku's feedback

If Wanjiku asked about something your report already covers, point her to the relevant section. If she asked about something you did not include — like the client tenure breakdown — go back to the notebook and the analysis specification (materials/analysis-specification.md). The specification includes client tenure as one of the breakdown categories. If you computed it but left it out of the report, add it. If you did not compute it, direct Claude to run the breakdown now, verify the result against the verification targets, and update the report.

Then re-verify. Open materials/report-template.md and confirm the updated report still follows the template structure. Check that any new numbers match the notebook output. A last-minute addition that introduces an unchecked number undoes the verification work you did in the previous unit.

Step 4: Write a decision record

You made analytical choices during this project. The most important one was the denominator decision in Unit 3 — using scheduled appointments (excluding cancellations) instead of all records. That choice changed the no-show rate by several percentage points.

Write a brief decision record. It does not need to be long. State what the choice was, what the alternative was, and why you chose the way you did. Something like:

• Decision: Computed the no-show rate using scheduled appointments only (excluding advance cancellations) as the denominator.
• Alternative: Using all records including cancellations as the denominator, which produces a lower rate.
• Rationale: Cancellations are a different behavior from no-shows. A client who cancels in advance is not the same as one who simply does not appear. Including cancellations in the denominator dilutes the no-show rate and makes the problem look smaller than it is.

Save this as decision-record.md in your project folder. This is professional documentation — a record of why the analysis looks the way it does, written while the reasoning is fresh. Six months from now, if someone asks why you used that denominator, the answer is in the file.

Step 5: Write the README

A repository without a README is a list of files with no explanation. Anyone visiting the repo -- including you, three months from now -- needs to understand what this analysis found and how to reproduce it.

Direct Claude to write a README for the project: "Write a README.md that describes what this project analyzed, the key findings, how to run the notebook, and what files are in the repository. Keep it concise."

Review what Claude produces. Does it accurately describe the no-show analysis for Wanjiku's clinic? Does it mention the confidence intervals and the key finding? If the README overstates or understates what the analysis found, fix it.

Step 6: Commit and push to GitHub

The project is complete. The notebook runs cleanly, the report is verified, the decision record explains the key analytical choice, and Wanjiku has her numbers. Close it out.

Direct Claude to stage the files, commit with a meaningful message, and push to GitHub. The commit message should describe what the project produced -- not "final commit" but something like "Add no-show analysis for Muthoni Veterinary Clinic -- verified findings report with CIs." A good commit message tells the next person what is in the box without opening it.

After the push, check that it succeeded. Go to GitHub and confirm your files are visible in the repository.

Your repository should contain the notebook, the findings report, the decision record, and the materials folder. That is the complete deliverable — analysis, communication, documentation, and version control. Every piece of this project is now recoverable, reviewable, and shareable.