Capstone Overview and Assessment Criteria

By the end of this lesson you will know what the capstone asks for, what a finished version of each deliverable looks like on one machine as well as on several, how to judge your own work when nobody else is going to, roughly how long each piece takes, and which earlier project each one is built on top of.

The six deliverables

#	Deliverable	What is finished when	Written from
1	Hardware and model plan	Every memory figure is arithmetic you can show, every model has a role and a licence, every link says what it carries, and the risks name the check that would catch each one early	Parts 4, 5 and 18
2	The inference service	A gateway with keys, a front-end people use, dashboards answering questions you wrote first, an alert proved to fire, TLS in front, and a backup you have restored	Parts 7, 9, 10 and 23
3	Cluster or tiered deployment	A baseline measured before the new architecture existed, the distributed or tiered measurement beside it, network utilisation, failure behaviour observed on purpose, and what a further machine would change	Parts 18 to 22
4	An improved small model	An evaluation set dated before the first run, a noise floor, a before-and-after over enough repeats, the quantised export measured as the separate model it is, and the regressions stated	Parts 11 and 13 to 16
5	The agentic workstation	Two agents of different kinds, their tools and permissions, a sandbox whose boundary test passes by failing, a setup script you have run from clean, and suite results over three repeats	Parts 24 to 27
6	The report	Every number in a table with its context, every claim pointing at a measurement, the cost model with its inputs, what did not work, what changed in your understanding, and what you did not measure	All of it, and your notebook

Each deliverable has its own page, its own template and its own validation. Nothing on those pages is new material: the capstone assembles what the course already taught, which is why the pages are shorter on instruction and longer on evidence than the labs were.

The single-machine variant

The course has said since Part 18 that a single-machine path is a first-class path, and the capstone is where that promise is kept. Every deliverable has a variant that needs one computer, and it is a complete submission rather than a reduced one.

Deliverable	On one machine
1. Plan	One machine holding every role; the network section becomes the client link and the section on machines you do not have
2. Service	Engines, gateway, front-end and monitoring on the same host, still with authentication and TLS in front, because the household still reaches it over the network
3. Deployment	The tiered design: several engines at different sizes behind one gateway, with a cache tier, measured against the single-engine baseline
4. Improved model	Unchanged; this deliverable never needed a second machine, only a memory tier
5. Workstation	Unchanged; the sandbox and the agents run beside the service, and the interference between them becomes a measurement worth having
6. Report	Unchanged, plus the paragraph that every single-machine variant owes: what a second machine would take on, which link it would need, and which measurement says so

⌂Single-machine path

The extra paragraph is the whole obligation. A capstone built on one computer is not a smaller capstone; it is one that has to name the condition under which its answer would change. In practice that paragraph is often the most rigorous thing in the report, because it is the only place where the author has to say what a purchase would actually buy.

How it is judged

There is no marker. This is a self-study course, so the assessment criteria are a rubric you apply to your own work, and every question in it is written so that you can answer it from two files you already have: the lab notebook you have kept since Part 1, and the report you write in Capstone 6. A question you cannot answer from those two files is a “no”, however confident you feel about it.

Criterion	The check	Applies to
Numbers carry their context	Every figure sits in a table naming the machine, operating system, engine and version, model, quantisation, context length and date; no figure appears in a sentence on its own	Everything
Claims point at measurements	Every sentence asserting faster, better, smaller or sufficient names a labelled measurement in the notebook; the rest are marked as arithmetic or as a vendor figure with its source	Everything
The single-machine variant names its second machine	A specific machine, a role, a link class and the measurement that motivates it	Deliverables 1, 3 and 6
Someone else could rebuild it	Pinned versions, exact model identifiers, the configuration files, and the commands you actually ran	Deliverables 2, 5 and 6
Budgets are arithmetic	Weight memory from parameters and bytes per parameter; cache from the per-token formula with the layer and key-value head counts named; a stated context length	Deliverable 1
Checks are evidence, not intentions	Every checklist row names the command that was run and what it printed	Deliverables 2 and 5
Baselines came first	The single-machine measurement was taken before the new architecture existed, under the same load with the same model file	Deliverable 3
A noise floor exists	The same configuration measured more than once, so that a difference smaller than the spread is reported as no difference	Deliverables 3, 4 and 5
Regressions are reported	What got worse, by how much, against that noise floor, and whether the trade is acceptable	Deliverable 4
The sandbox passes by failing	Every boundary attempt refused, and a control check proving the agent can still reach what it legitimately needs	Deliverable 5
The report says what it does not know	A section listing what was not measured, what is arithmetic and what came from documentation unverified	Deliverable 6

The full version, with the sub-questions per deliverable and a place to count the “no” answers, is the file below. Work through it twice: once when you think you are finished, and once a week later, reading your own report the way a stranger would.

Fragment — not complete on its own

capstone-rubric.md

# Capstone rubric — the checks you apply to your own work

<!--
Purpose: the self-assessment for Part 28. This course has no marker, so the rubric is
         written as questions you can answer yes or no from two files you already have:
         the lab notebook you kept since Part 1, and the report you write in Capstone 6.
         A question you cannot answer from those two files is a "no", however sure you
         feel. That rule is the whole rubric.
Platform: all
Minimum memory: not applicable; this is a document
Assumes: labbook.md from Part 1 onwards, and the six capstone deliverables in whatever
         state they have reached. Work through it twice: once when you think you are
         finished, and once a week later, when you are reading your own report as a
         stranger would.

How to use it: answer every question in the column that says what would satisfy it.
Count the "no" answers rather than scoring yourself out of anything. Each "no" is one
sentence to add to the report's "what is not true here" section, and that section is
what makes the rest of the document worth reading.
-->

**Reader:** <you> · **Date of this pass:** <YYYY-MM-DD> · **Pass:** <first / second>

---

## A. The four questions that apply to every deliverable

These are the course's standard, applied to your own work. If a deliverable fails one of
these, fixing it is worth more than adding anything new.

| # | Question | What a "yes" looks like | Where to look |
| --- | --- | --- | --- |
| A1 | Does every number carry its context? | Each figure sits in a table naming the machine, the operating system, the engine and its version, the model, the quantisation, the context length and the date. No figure appears in a sentence on its own. | The report's tables; the records in `labbook.md` |
| A2 | Does every claim point at a measurement? | Every sentence asserting that something is faster, better, smaller or sufficient names a labelled measurement that exists in the notebook. Sentences that cannot are marked as arithmetic or as a vendor figure, with the source. | The report's prose, sentence by sentence |
| A3 | Does the single-machine variant say what a second machine would change? | A named machine, the role it would take, the link it would need, and the measurement that motivates it. "It would be faster" is a "no". | Capstone 3, section on further machines; the report |
| A4 | Could somebody else rebuild this from what you wrote? | The versions are pinned, the configuration files are in the report or beside it, the model identifiers are exact, and the commands are the ones you actually ran. | The report's reproduction section |

## B. Capstone 1 — the hardware and model plan

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| B1 | Is every memory budget arithmetic rather than a guess? | Each model's weight memory is parameter count times bytes per parameter, and each key-value cache figure comes from the per-token formula in Part 4 with the layer and key-value head counts named. |
| B2 | Does the plan state the context length each budget assumes? | A budget without a context length is not a budget. Each row names the context you will actually configure, not the model's trained maximum. |
| B3 | Is a headroom allowance written down and justified? | Operating system, engine working memory, cache growth and any second model, each with a figure and a sentence. |
| B4 | Does every model in the plan have a role and a licence? | Role in one phrase, licence from the model card, and "gated" noted where an acceptance step is needed. |
| B5 | Are the risks specific? | "The 30B model does not fit at 32k context on the 64 GB machine, so the fallback is 16k" is a risk. "Memory might be tight" is not. |

## C. Capstone 2 — the inference service

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| C1 | Does every item on the checklist have the check that proves it? | Each row names the command that was run and what it printed, not an intention. |
| C2 | Is nothing reachable beyond the machine without authentication and TLS? | A listening-socket check and a request from another device, both recorded. |
| C3 | Do the dashboards answer a question you wrote down first? | The questions were listed before the panels were built, and each panel maps to one. |
| C4 | Has at least one alert been proved to fire? | A deliberately induced condition, the alert's state change, and the time it took. |
| C5 | Has a backup been restored, not just taken? | A restore into a scratch location, with the comparison that showed it was intact. |
| C6 | Is there a rollback you have actually performed? | An upgrade and a return to the previous version, with the evidence that the service worked afterwards. |

## D. Capstone 3 — the cluster or tiered deployment

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| D1 | Is there a baseline measured before the distributed configuration? | A single-machine number taken first, under the same load, with the same model file. |
| D2 | Is the comparison honest about what changed? | One variable at a time, or an explicit list of everything that differed. |
| D3 | Is network utilisation measured rather than assumed? | Bytes across the link, or the link's own counters, against the measured throughput from Part 18. |
| D4 | Is failure behaviour observed rather than described? | A machine taken away mid-request, and what the client saw. |
| D5 | Does the conclusion follow from the numbers, including when it is "do not do this"? | A configuration that lost is reported as having lost, with the measurement. |

## E. Capstone 4 — the improved model

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| E1 | Was the evaluation set built before the training run? | A dated file, with its item count, written before the first run record. |
| E2 | Is the noise floor measured? | The same configuration evaluated more than once, and the spread of that repeat stated, so that a difference smaller than it is reported as no difference. |
| E3 | Is the before-and-after comparison run on the same file with the same settings? | Same task file, same shots, same chat template, same sampling settings, same seeds, both recorded. |
| E4 | Are regressions reported? | The categories that got worse, with the numbers, and a sentence on whether the trade is acceptable for your use. |
| E5 | Is the exported model the one that was measured? | The quantised file's evaluation is reported separately from the unquantised adapter's, because they are different models. |
| E6 | Is decontamination recorded? | What the evaluation set was checked against, what overlap was found, and what was done about it. |

## F. Capstone 5 — the agentic workstation

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| F1 | Does the sandbox test pass by failing? | Each boundary attempt was refused, and there is a control check that the agent can still reach what it legitimately needs. |
| F2 | Is the setup script the thing you actually ran? | A fresh run of the script produced the working configuration, and the report names what it did not cover. |
| F3 | Does each agent's model choice have a reason with evidence? | A measurement or an observed failure, not a preference. |
| F4 | Are the agent evaluation numbers from more than one run? | Three repeats at minimum for any comparison between configurations, with the spread reported. |
| F5 | Is every MCP server's permission stated? | What each server can read, what it can change, and what would happen if its output were hostile. |

## G. Capstone 6 — the report

| # | Question | What a "yes" looks like |
| --- | --- | --- |
| G1 | Does the architecture diagram match what is running? | Every box exists; nothing running is missing from the diagram. |
| G2 | Does the cost model name its inputs? | Measured idle and load power, the price per unit of electricity, the aggregate output rate, and the utilisation assumption, each as a figure you can point at. |
| G3 | Is there a section on what did not work? | At least three things, each with what you tried and what the evidence was. |
| G4 | Is there a sentence about what changed in your understanding? | Something you believed at Part 5 and no longer believe, with the measurement that changed it. |
| G5 | Is the maintenance plan actionable by somebody else? | Dated tasks, the commands, and where the state lives. |
| G6 | Does the report say what it did not measure? | A list, not an apology, and it is the section you would read first if it were somebody else's report. |

---

## The count

| Section | "no" answers | The sentences they become |
| --- | --- | --- |
| A. Applies to everything | <n> | <one line each> |
| B. Hardware and model plan | <n> | <one line each> |
| C. Inference service | <n> | <one line each> |
| D. Cluster or tiered deployment | <n> | <one line each> |
| E. Improved model | <n> | <one line each> |
| F. Agentic workstation | <n> | <one line each> |
| G. Report | <n> | <one line each> |

<!--
A capstone with a dozen honest "no" answers written into the report is a better piece of
work than one with none and no evidence. The failure the rubric is built to catch is not
an incomplete platform; it is a complete-looking document whose numbers nobody, including
its author, can trace back to a measurement.
-->

Download capstone-rubric.md120 lines

!Important

Count the “no” answers rather than scoring yourself. Each one becomes a single sentence in the report’s final section, and a capstone with a dozen honest “no” answers written down is better work than one with none and no evidence. The failure this rubric exists to catch is not an incomplete platform. It is a complete-looking document whose numbers nobody, including its author, can trace back to a measurement.

The time budget

Page	Kind	Time on task
This overview	Lesson	20 minutes
1. Hardware and model plan	Project	60 minutes
2. The inference service	Project	90 minutes
3. Cluster or tiered deployment	Project	120 minutes
4. Improve a small model	Project	150 minutes
5. The agentic workstation	Project	90 minutes
6. The report	Project	90 minutes

Those figures are time at the keyboard on the capstone itself, and they assume the earlier labs are behind you with their results in the notebook. Two of them mislead if read literally. Deliverable 4 is mostly unattended: the training run happens while you do something else, and the attended part is the evaluation on either side of it. Deliverable 2 is the one that reliably overruns, because it is where you find out which of your earlier labs left something half-configured.

Plan the training run first, whatever order you do the rest in. It is the only deliverable with a long wait in the middle, and starting it early means the wait overlaps with work rather than with waiting.

What to reuse

Nothing here should be built from nothing. Each deliverable has a parent project, and the capstone version differs from it in scope rather than in technique.

Deliverable	Reuse	For
1	Part 4’s model shortlist lab and the memory-budget lesson	The fit arithmetic, the bytes-per-parameter table and the four headroom allowances
1	Part 18’s cluster-network lab	The measured link figures and the annotation of what each link carries
2	Part 9’s gateway project	The permanent model names, the per-application keys and the gateway document
2	Part 7’s private chat service lab	The front-end, the reverse proxy with TLS, and the backup that was restored
2	Part 23’s dashboards lab, its security lesson and its backup lesson	The six questions a dashboard answers, the alert you prove fires, key life cycle, and the estate manifest
3	Part 19’s bigger-than-one-machine lab	The layer split across machines, and the honest comparison against one machine
3	Part 20’s Spark-pair lab or Part 21’s two-Mac lab	The platform-native multi-machine path, if your machines are of one kind
3	Part 22’s tiered architecture project	The design document, the link annotation and the single-machine tiered design
4	Part 13’s specialist assistant project, Part 14’s preference lab and Part 15’s distillation pipeline	Whichever technique your memory tier supports, and the run logging around it
4	Part 16’s benchmark-suite lab and its quantisation lab	The three-run rule, the noise floor and the divergence measurement against the unquantised model
5	Part 25’s workstation project and its sandbox lab	The agent configurations and the boundary test with its control check
5	Part 26’s multi-agent project and its evaluation lesson	The role split, the task suite and the rule about repeats
6	Part 1’s lab notebook and Part 23’s cost lesson	Every record the report is written from, and the cost-per-million-tokens method

If a row above names a lab you skipped, you have two honest options: do it now, or write the capstone deliverable without that piece and say in the report which section is missing and why. Inventing the number is not on the list.

The order, and why

The capstone in six steps

1. 11. PlanArithmetic first. Decides which models the service can hold and at what context, and finds the fit problems before they become failures.
2. 22. ServiceBuilt to the plan. Everything after this is measured against it or served by it, so it comes second whatever else you are keen to do.
3. 34. Start the training runOut of order on purpose: it is the one long unattended wait, so it should be running while you do step 3.
4. 43. DeploymentThe baseline is measured first, then the architecture you chose. Do this while the trainer runs.
5. 54. Finish the modelEvaluate against the noise floor, quantise, export, serve it under a gateway name.
6. 65. WorkstationAgents on the service, driving the improved model where it is good enough, inside a sandbox you have tested.
7. 76. ReportWritten from the notebook, with the rubric applied twice.

The numbers are the deliverables; the sequence is the order to work in. Only two orderings matter: the plan comes before the service, and the training run starts before the deployment work rather than after it.

The report is last for a reason that is easy to miss. Writing it is where you discover which measurements you never took, and by then it is often still possible to take them. Leaving the report until the platform is dismantled is the one scheduling mistake this part cannot recover from.

▷Exercise

Before you start deliverable 1, open your notebook and write one sentence: what you expect the whole platform to cost per million tokens, and how many concurrent people you expect it to serve at your chosen context length. Two guesses, dated, before any of this work. In Capstone 6 you will compare them with the measurements, and the comparison is worth more than either number.

Build a chain of evidence from requirement to operation

Treat every deliverable as an answer to a requirement. The hardware plan explains capacity; the service demonstrates access and request handling; the deployment comparison justifies topology; the model improvement shows a controlled quality change; the workstation demonstrates bounded useful actions; the report connects those claims to raw evidence.

Create a traceability table before beginning. For each requirement, name the artefact, acceptance test, result file and remaining limitation. Mark a test not run when the necessary hardware is unavailable. A single-machine deployment is complete when it satisfies its declared scope; it should not claim unperformed cluster measurements.

Freeze the evaluation tasks and starting configurations early. Record changes as new experiments rather than rewriting the original baseline. At the end, ask another reader to follow the report’s reproduction steps using only the committed configuration and retained artefacts. Any undocumented alias, missing helper or unexplained manual step is a gap to repair. The capstone demonstrates an understandable, recoverable system, not just a collection of successful screenshots.

Recap

• Six deliverables: a plan, a service, a deployment, an improved model, an agent workstation and a report. Each has a page, a template and its own validation.
• Every deliverable has a single-machine variant that counts as complete, and the price of that variant is one paragraph naming what a second machine would take on and which measurement says so.
• The rubric is self-applied and every question in it is answerable from the lab notebook and the report. A question you cannot answer from those two files is a “no”.
• Count the “no” answers and write each one into the report’s final section rather than scoring yourself.
• Start the training run early, build the service second, and write the report while the platform is still standing.

Check your understanding

Question 1. You have one computer. Which of these is true of your capstone?

• It is a partial submission and should be labelled as such
• It is a complete submission, provided each single-machine variant names what a second machine would take on, which link it would need, and the measurement that motivates it
• You should skip deliverable 3 entirely
• You should borrow a second machine before starting

Show the answer and why

Answer: It is a complete submission, provided each single-machine variant names what a second machine would take on, which link it would need, and the measurement that motivates it

The course has treated the single-machine path as first-class since Part 18, and deliverable 3 has a single-machine form: several engines at different sizes behind one gateway, measured against the single-engine baseline. What the variant owes is the paragraph about the second machine, and that paragraph is frequently the most rigorous thing in the report.

Question 2. Why does the suggested order start the training run out of sequence, before the deployment work?

• Because the improved model is needed by deliverable 3
• Because it is the only deliverable with a long unattended wait in it, so starting it early means the wait overlaps with the deployment work instead of with waiting
• Because the trainer needs the cluster
• Because the evaluation set has to exist before the plan

Show the answer and why

Answer: Because it is the only deliverable with a long unattended wait in it, so starting it early means the wait overlaps with the deployment work instead of with waiting

The attended part of deliverable 4 is the evaluation on either side of the run; the run itself happens while you do something else. Deliverable 3 needs the service and your attention, not the trainer, so the two fit together.

Question 3. Which of these count as satisfying the rubric? Select all that apply.

• A table of throughput figures carrying the machine, operating system, engine version, model, quantisation, context length and date
• A sentence saying the new architecture is faster, with the two measurement labels named
• A memory budget stating the context length it assumes and showing the per-token cache arithmetic
• A sentence saying the fine-tune clearly improved the model, based on one evaluation run of each

Show the answer and why

Answer: A table of throughput figures carrying the machine, operating system, engine version, model, quantisation, context length and date, A sentence saying the new architecture is faster, with the two measurement labels named, A memory budget stating the context length it assumes and showing the per-token cache arithmetic

The last one fails on the noise floor. A single run of each configuration cannot separate a difference from run-to-run variation, which is why Part 16 measures one file twice before comparing two, and why the rubric asks whether a noise floor exists before it asks what the difference was.

Question 4. The rubric asks a question you cannot answer from your notebook or your report, although you are fairly sure of the answer. What do you record?

• Yes, since you remember it clearly
• No, and the sentence it becomes goes into the report section on what you did not measure
• Leave it blank
• Yes, with a note that it is from memory

Show the answer and why

Answer: No, and the sentence it becomes goes into the report section on what you did not measure

The rubric is built on the two files, not on recollection, because that is the standard a reader can apply to your work as well. Turning the gap into one sentence in the final section is what the count of "no" answers is for.

Question 5. True or false: the capstone report should be written after the platform has been taken apart, so that it can describe the whole life of the project.

• True
• False

Show the answer and why

Answer: False

Writing the report is where you find out which measurements you never took. Done while the platform is still standing, most of those gaps can still be closed; done afterwards, they become entries in the section on what you did not measure. That is the one scheduling mistake this part cannot recover from.

Check my answersClear