Your project runs, measures, and beats the baseline. What remains is the last stretch, the one that separates a private exercise from professional work: communicating it so that another person can understand it, judge it and reproduce it. In this final lesson you will write the project report with a concrete template, prepare the repository so anyone can run it, assess yourself with a serious rubric — the same one we will use to evaluate, warts and all, the Rutalia reference project — and, if you get the chance to present it live, you will have a ten-minute script. And since this is the last lesson of the course, we will end where a course should end: looking back at the whole road and forward to what comes next.

1. The final report: structure and template
2. Justifying decisions: the "why this algorithm and not another" table
3. Presenting results honestly
4. The README and the reproducible repository
5. Self-assessment rubric
6. The reference project, evaluated
7. Short oral presentation (if applicable)
8. Course conclusion

The report is not a diary of what you did; it is a document for a reader who was not there. 4 to 8 pages (or the Markdown equivalent), with this fixed structure:

Writing tip: draft sections 4-5 first (you already have the CSV and the tables from 07-02) and then the rest. The results are the skeleton; the narrative is built around them.

The methods section wins or loses credibility on one point: did you choose each algorithm for a reason, or because it was the last one you had studied? The most effective way to prove it is a table that confronts each decision with the alternatives you rejected — this is where the DECISIONS.md you kept in 07-02 shines. The reference project's:

Note the pattern in every row: a named alternative, an explicit criterion (quality, cost, risk) and, when one exists, a number. "I chose X because I like it" never appears.

The temptation when writing results is to show only the good run. It is the editorial version of the cherry-picking we criticized in the metrics of 05-02, and a competent reader smells it from a distance. Three rules:

• Report variability, not a single number. "−41% mean over 10 instances × 5 seeds, range [−33%, −47%]" tells the truth; "up to 47% improvement" is marketing. If there is an instance where your method loses, it appears in the table.
• Tell what did not work. In Rutalia: the Hungarian barely moved the needle (all couriers leave from the same depot) and a neural network for the times did not beat the regression. Documenting both adds credibility: it proves you tried alternatives and measured before deciding.
• Always compare on equal terms. Same instances, same data seeds for all variants, same metric computed by the same evaluator. If one variant uses information another does not have, say so.

Format of the report's main table (the one you designed up front in 07-01):

The report persuades; the repository proves. The standard is simple: a person with Python and zero context must get from git clone to reproducing your main table in under ten minutes. The minimal README:

Repository checklist before calling it done:

• [ ] requirements.txt with versions; nothing installed "from memory".
• [ ] No absolute paths and no dependency on your machine.
• [ ] Seeds fixed: two runs produce the same table.
• [ ] The data is generated by a script (or there are download instructions); do not commit heavy datasets nor, under any circumstances, personal data.
• [ ] The report lives inside the repository (report/REPORT.md).
• [ ] Acid test: clone it into a clean directory and follow your own README to the letter.

Grade yourself with this rubric before considering the project finished; each level is cumulative ("good" includes everything in "acceptable").

Practical reading: all "acceptable" is a passing project; the reasonable target for 20-40 hours is "good" on every criterion and "excellent" on the two that best align with your project. An "insufficient" on any criterion rules: it gets fixed before polishing anything else.

We run the rubric over the Rutalia planner as it stood at the end of 07-02, with the honesty we asked for a couple of sections above:

Honest strengths: the measurement and the integration, which is exactly what the course has trained the most. Honest weaknesses: the edges — untested edge cases and under-discussed limitations of the synthetic data. It is a "good with two excellents" project, and that sentence, with its justification, is exactly what you should be able to write about yours.

If you get the chance to present the project (a team meeting, a meetup, a technical interview), ten minutes are enough if structured like this:

Rehearse it once against the clock: the universal mistake is spending six minutes on context and rushing the results, which is exactly what the audience came to see.

• Mistake: the diary report. "First I tried X, then I realized that Y…" — the reader wants the organized result, not the chronology. The process only appears when it justifies a decision.
• Mistake: unintentional cherry-picking. Regenerating results "one last time" and keeping the run that came out best. The report's numbers come from the experiments CSV, with its fixed seeds, and from nowhere else.
• Mistake: the aspirational README. Instructions that "should work" but nobody has followed from scratch. The clean-clone test is not optional.
• Mistake: grading yourself upward. The rubric only works if each level is justified with evidence you can point to (where are those tests? where is that range across seeds?). Grade as if the project were someone else's.
• Tip: ask for an external read. A colleague who reads only the report must be able to answer: what problem does it solve, how much does it improve, and how do I know? If any of these fails, the report — not the reader — has the problem.
• Tip: the repository is your portfolio. A reproducible project with serious measurement says more in a technical interview than ten certificates. Polish it with that reader in mind.

The three final milestones of your project — and of the course.

Write your project's report with the 8-section template, including the decision table (at least 3 rows with real alternatives) and the results table with mean and range across seeds.

Bring the repository to its final state: README with reproduction steps, requirements, fixed seeds, and pass the clean-clone test by following your own instructions.

Grade your project criterion by criterion with the rubric, justifying each level with concrete evidence, and identify: (a) your strongest criterion, (b) the weakest, and (c) the single improvement you would make with 4 more hours.

Exercise 1 — self-assessment criteria. External-reader test: someone who does not know your project must extract from the report the problem, the numeric improvement and how it was measured, in under five minutes. Also verify: every row of the decision table names a real alternative and a criterion (not "it was the most suitable"); the results section contains at least one negative or neutral result; no number in the report is impossible to trace back to your experiments CSV.

Exercise 2 — reference solution. The standard is literal: clone into a clean directory, follow the README word for word, obtain the main table. Typical failures this test uncovers: an import that depended on your PYTHONPATH, a data file that existed on your machine but is never generated, an unversioned dependency that no longer installs the same. If reproducing takes more than 10 minutes of human work (the computation can take as long as it needs), simplify the steps, not the instructions.

Exercise 3 — self-assessment criteria. A credible self-assessment is almost never flat: the norm is a mix of levels, like the reference project's. Be suspicious of yourself if you gave yourself "excellent" on everything (recheck with the evidence in hand) and also if you gave yourself "acceptable" on everything (you are probably being unfair on your strong criterion). The answer to (c) is the most valuable one: if the improvement you would pick is about code or measurement, your engineering instinct is well calibrated; if it is "add yet another technique", reread the when-to-stop section of 07-02.

And with your report written, your repository reproducible and your rubric filled in, the course ends.

Look at the road behind you. You started in module 1 learning to put a name on the cost of things — asymptotic notation, complexity analysis, recursion and dynamic programming, the structures that make it possible — back when Rutalia was just a company with packages to deliver and we could not even measure what delivering them cost. In module 2 you learned to optimize: linear programming, knapsacks and traveling salesmen (that 35.22 km optimum), backtracking, genetics and ants competing on the same problems. Module 3 turned the city into a nine-zone graph and gave you BFS, Dijkstra, spanning trees, flows and matchings. Module 4 sharpened search and sorting, from binary search on the answer all the way to A*. Module 5 added the missing piece — learning from data: regression, classification, neural networks from scratch, clustering over 2000 deliveries — and module 6 blended it all into real cases, from the operational day with its 72% improvement to the ethics of models with consequences. And in this module 7 you stopped following the case study and built your own: specification, layered development, honest measurement and professional communication.

That is what you now know how to do, and it is worth saying plainly: you know how to model a fuzzy problem as a formal one, choose the algorithm with criteria (and reject alternatives with numbers), predict the cost before running, measure against a baseline with variability, and communicate the result reproducibly. That complete chain — not any single algorithm — is the competence that separates someone who has studied algorithms from someone who solves problems with them.

Next steps, concretely:

• Competitive programming (Codeforces, AtCoder, Advent of Code) to gain speed and reflexes with the techniques from modules 1-4; start with medium-difficulty problems and give yourself time.
• Google's OR-Tools for industrial optimization: we left it cited in 06-01; you now have the foundation to use its VRP and integer programming solvers while understanding what they do under the hood.
• The classics: Introduction to Algorithms (CLRS) as the deep reference, The Algorithm Design Manual (Skiena) for modeling instinct, and Algorithms (Sedgewick) if you prefer to start from the code.
• Specialization: if module 5 hooked you, continue with a serious machine learning course and take your models to production with the precautions of 06-04; if modules 2 and 3 hooked you, operations research and combinatorial optimization hold enough depth for years.

Rutalia was fictional; what you have built on top of it is not. The next time someone brings you a tangled problem — routes, timetables, recommendations, data that doesn't fit — you will recognize the pattern: model, combine, measure. The tools are yours and you know how to use them. It has been a pleasure making this journey with you. Until next time, and happy coding.