Module 6 ended with a promise: the case study is yours to choose. Over six modules you watched Rutalia — our fictional last-mile logistics company — turn real problems into models, models into algorithms, and algorithms into measurable decisions. Now it is your turn to walk that same road with a problem of your own. This first lesson of the capstone project has a single goal: that you leave it with a written, validated, realistic specification of your project. It may sound like a small step, but this is the phase where most self-taught projects die: whoever starts coding without a specification usually ends up with one enormous script that answers no question at all. Here we will define what makes a capstone project good, browse a catalog of ideas, learn to write the specification with a concrete template, and apply that template in full to the Rutalia reference project that will accompany us through the whole module.

1. What makes a capstone project good: integrative, measurable, bounded
2. A catalog of project ideas
3. The specification template
4. The Rutalia reference project, fully specified
5. Validating the specification before writing any code

A capstone project for this course is not "a program that works". It is a documented algorithmic experiment: you pose a problem, solve it by combining techniques from the course, and prove with numbers that your solution beats a simple alternative. Three properties define it:

It must combine techniques from at least 2-3 different modules of the course. This is not academic whim: in module 6 you saw that real problems are never solved by a single algorithm. Rutalia's operational day (06-01) chained clustering, the Hungarian algorithm, nearest neighbor and 2-opt; the recommendation system (06-04) mixed collaborative filtering with classification metrics. A project that only implements Dijkstra is a one-lesson exercise, not a capstone project.

There must be a numeric success metric and a baseline to compare it against. The baseline is the dumbest solution that solves the problem end to end: routes in random order, "always predict the mean", assignment in arrival order. Without a baseline you can claim nothing: is an 18% error good? It depends on whether the trivial solution scores 19% or 60%.

Between 20 and 40 hours of work. Any less and there is no time to integrate several modules with serious measurement; any more and the self-taught student abandons it. The tool for bounding is the "out of scope" section of the specification: writing down explicitly what you will not do is as important as writing down what you will.

You can follow the Rutalia reference project as is, adapt it to another domain, or pick a different idea. This catalog gives you eight proven starting points; all of them satisfy the three properties if they are bounded well. Difficulty is indicative (★ = doable in ~20 h, ★★★ = demands the full 40 h).

Tips for choosing:

• Pick a domain you know or that draws you in. You are going to spend 20-40 hours with it; motivation is the self-taught learner's scarcest resource.
• Don't choose by difficulty, choose by clarity of the metric. Project 5 (★) measured well is worth more than project 6 (★★★) half done.
• Porting the reference project to your own domain is legitimate and recommended: the same "predict → cluster → assign → order → compare" scheme works for deliveries, maintenance technicians, sales visits or waste collection.

The specification is a one- or two-page document you write before the first line of code. Copy it verbatim and fill in every field:

Two notes on the fields people neglect the most:

• Data (field 2). The default option in this course is to generate it synthetically, as we did with the 2000-delivery dataset in module 5: you control the volume, the distribution and the seed, and there is zero ethical or legal risk. If you use public data, check the license and that it is anonymized at the source. Using real data about people — even "just for testing" — is out of scope for this project, no exceptions.
• Milestones (field 7). Every milestone must produce something runnable or measurable, not "make progress on X". "M2: the regression model predicts times with test MAE < 4 min" is a milestone; "M2: work on the model" is not.

We now apply the template, complete and with no blanks, to the project we will build in 07-02 and evaluate in 07-03. Note the level of concreteness: this is the standard your specification must reach.

Before signing off on the specification, put it through this feasibility checklist. Every "no" is a mandatory revision, not a detail:

• [ ] Does a trivial baseline exist? You must be able to write it in less than an afternoon. If even the dumb solution is hard, the problem is badly bounded.
• [ ] Can the metric be computed by a script? If measuring success requires human judgment ("the routes look reasonable"), it is not a metric.
• [ ] Can the data be generated or obtained in under 1 hour? A 50-line numpy synthetic generator qualifies; "I'll find a dataset online" does not qualify until the dataset is downloaded and loaded.
• [ ] Does every planned algorithm have its lesson in the table? If a technique appears that the course has not covered, either replace it or justify it as a small extension.
• [ ] Do the milestone hours add up to between 20 and 40? And no milestone exceeds 8 hours: if one does, split it.
• [ ] Does the "out of scope" section have at least 3 entries? If you cannot think of any, you have not yet thought about everything the project could swallow.

A useful technique: write the final table of your report before you start (columns: variant, total time, improvement %, compute time). If you know exactly which table you want to be able to fill in at the end, every intermediate decision becomes easier.

• Mistake: the platform project. "I'll build a website with login where orders get uploaded and…" — that is a web development project, not an algorithms project. Anything that is not generating data, running algorithms and measuring results goes into "out of scope".
• Mistake: the retroactive metric. Deciding how to measure after implementing invites self-deception: you will end up choosing the metric your solution looks good on. Metric and baseline are fixed here, in writing.
• Mistake: real data "because it's more authentic". Beyond the ethical and legal problem (remember 06-04: bias, privacy, the EU AI Act), real data brings endless cleaning that eats your hour budget. Synthetic data lets you control the difficulty.
• Mistake: silent scope creep. The symptom is the phrase "while I'm at it, I'll add…". The antidote is rereading section 6 of your specification every time you say it.
• Tip: keep the specification short and frozen. One to two pages. Once it passes the checklist, treat it as a contract with yourself: changes get written down and justified, never improvised.
• Tip: if you are torn between two ideas, specify both. It's 30 minutes per template, and the checklist almost always decides on its own which one is feasible.

The exercises in this module are the milestones of your own project: they do not have a single solution, but self-assessment criteria.

Choose your project (from the catalog, adapted, or your own) and write one paragraph justifying that it is integrative (which 2-3 modules does it combine and how do their outputs chain together?), measurable (which number, against which baseline?) and bounded (what do you leave out?).

Fill in the 7-section template for your project, with the level of detail of the Rutalia example: an algorithms table with lessons, a metric with instances and a numeric target, and a milestone plan with hours.

Run the feasibility checklist over your specification. For every point that fails, change the specification (not the checklist) and write down what you changed.

Exercise 1 — self-assessment criteria. Your paragraph is solid if: (a) it names concrete lessons, not vague modules ("I use k-means from 05-05", not "I use ML"); (b) it explains the chaining — the output of one technique is the input of the next, like time matrix → clustering → assignment in Rutalia; (c) the metric fits in one sentence with a numeric target. Failure sign: if on rereading you would not know where to start coding, it is too vague.

Exercise 2 — reference solution. Compare your document with Rutalia's section by section and ask yourself: is my section just as concrete? In particular: the data section must include volume, fields and seed; the algorithms table must have one row per pipeline phase; every milestone must be verifiable by a third party who only reads the deliverable. If your full specification runs under half a page, it lacks concreteness; if it exceeds two pages, there is platform in it.

Exercise 3 — self-assessment criteria. The expected outcome is that something changed: in practice, no first specification passes the checklist clean. The most common adjustments (and a good sign that you are really validating) are: trimming the data scope, replacing an uncovered algorithm with one from the course, and splitting a 12-hour milestone in two. If your checklist came out perfect on the first try, re-examine the trivial-baseline point more harshly: that is where optimism sneaks in the most.

You now have the hardest part: a chosen project and a validated specification that fits on one page and in 20-40 hours. We have seen that a good capstone project is integrative (2-3 chained modules), measurable (metric + baseline fixed up front) and bounded (with an explicit "out of scope"), and we have left the Rutalia reference project — the delivery planner with predicted travel times — fully specified as a yardstick. In the next lesson (07-02) it is time to turn paper into code: we will set up the project structure, build first the baseline that works end to end, and add the algorithmic layers one by one, measuring at every milestone. The specification you just wrote will be the map; keep it in sight.