Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Proposal"]
N2["44.2 Non-goals"]
N3["44.3 Milestone 1"]
N4["44.2b Risk register for the capstone"]
N5["44.3b Advisor checkpoints"]
N6["44.1b Success metrics for the capstone"]
N7["Practice note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Proposal"]
N2["44.2 Non-goals"]
N3["44.3 Milestone 1"]
N4["44.2b Risk register for the capstone"]
N5["44.3b Advisor checkpoints"]
N6["44.1b Success metrics for the capstone"]
N7["Practice note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Proposal]
|
v
[44.2 Non-goals]
|
v
[44.3 Milestone 1]
|
v
[44.2b Risk register for the capstone]
|
v
[44.3b Advisor checkpoints]
|
v
[44.1b Success metrics for the capstone]
|
v
[Practice note]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) propose a capstone that ships a measurable platform improvement; (2) define scope and non-goals; (3) set a verification plan.
44.1 Proposal
Problem, users, requirements (safety first), architecture sketch, milestones, verification lab plan, ethics paragraph. Capstones that need exploit work are rejected.
Safety-first requirements and an ethics paragraph are gates, not decorations. Exploit-centred proposals return unread. Sam's template opens with users and fail-closed requirements before any architecture sketch, which is why "auto-pwn" drafts never passed the first checkpoint. Safety requirements are numbered and traced to Lab II rows in the same document. Proposals that fail this check go back with the missing section named.
44.2 Non-goals
Explicitly list what you will not build (exploit modules, live client scanning, ML risk oracles).
Writing non-goals early is what makes freeze possible later. Exploit modules, live client scanning and ML risk oracles are named so a mid-term demo cannot smuggle them in. Sam's proposal listed those three explicitly and advisors graded scope against that list. Mid-term demos are graded against that list before anyone watches the video. Adding a non-goal mid-term requires advisor approval recorded in the risk register.
44.3 Milestone 1
Something demoable on synthetic data in week 3: e.g. kill-switch honored in ≤30s with a test.
Synthetic case — Riverstone Transit. Capstone I proposals that mentioned "auto-pwn" were returned; "signed policy distribution with fail-closed" advanced.
Vague "research spikes" are not. Sam's milestone-1 video shows the stop control, the measured halt time and the ROE clause it satisfies, which is the pattern that advanced past "auto-pwn" returns. Videos without a measured halt time fail the checkpoint even if the UI looks polished.
44.4 Errors and limits
Capstone scope creep is the main killer — freeze non-goals.
Scope creep kills more capstones than hard bugs. Freezing non-goals and parking sequel ideas is the control. Sam's mid-term review rejected a ticket-system integration that was not in the proposal, even though a mentor liked the demo. Sequel ideas get a one-page parking doc dated on freeze day. Freeze day is on the shared calendar with the same seriousness as an engagement window. Calendar invites for freeze include the advisor and the ops owner.
44.2b Risk register for the capstone
List project risks: scope creep, dependency delay, reviewer unavailability, ethics boundary confusion. Each risk has an early warning and a mitigation. Review the register weekly in studio.
Early warnings beat heroics in week eleven. Sam's register flagged advisor travel in week six and booked the checkpoint early; the mitigation was a recorded demo, not a silent slip. Risks without early warnings are rewritten before the meeting ends. Each mitigation names who acts and by which week. Closed risks stay in the register with the date they closed, so the final report can show which warnings fired and what was done.
44.3b Advisor checkpoints
Capstone I has mandatory checkpoints: proposal accepted, milestone 1 demo, mid ethics check. Missing a checkpoint freezes coding until recovered — silent drift produces unreviewable piles.
Sam's ethics check mid-capstone caught a plan to use anonymized but still host-internal hostnames; coding stayed frozen until the synthetic set was substituted. Frozen coding is visible on the board so teammates do not merge dependent work. Dependent PRs from teammates are held in draft while the freeze is on. Recovering a missed checkpoint means meeting the advisor and getting the gate signed, not just sending an apology.
44.1b Success metrics for the capstone
Define two metrics you will show at defense (e.g. deny-all time, percent of merges with AUTH tickets). If you cannot name them in Capstone I, the proposal is not ready.
Sam wrote "deny-all ≤30s after policy loss" and "100% of scope widens have AUTH tickets" on page one of his proposal. Each metric needs a measurement method and a target that can be checked on synthetic data before the defense. Vague goals such as "better safety" are returned at the proposal checkpoint. Sam also named how he would measure each one: a timed Lab II run for deny-all, and a query over merge history for AUTH tickets. Both were measured once on synthetic data before the proposal was submitted, so the targets were known to be reachable.
Practice note
Capstone I proposals that cannot name a verification lab row for each Must requirement return to draft. Mapping requirements to lab rows early prevents beautiful designs that cannot be shown to fail closed under Lab I.
Attach the ethics paragraph to the proposal so advisors can reject dual-use scope before coding starts.
Milestone demos that skip fail-closed are graded zero for that checkpoint regardless of UI polish.
Proposals without lab-row mapping are returned before studio time is booked.
44.4b Scoping the capstone honestly
The capstone proposal states what will be built in the time available — a scope-diff tool for TrackScope with tests and a short evaluation — and what will not, such as integration with every client's ticket system. Advisors judge the project against the stated scope, not against an imagined larger one.
Sam's non-goals included "every client's ticket system," which stopped a late scramble to add Jira during freeze. Non-goals are listed in the proposal next to the goals, so freeze reviews can check new requests against them. A feature that appears on neither list goes back to the advisor before any code is written. The advisor signs the list at the proposal checkpoint.
Exercises
- EX130 — Non-goal. Write three non-goals for a PulseMap capstone. Rubric: 3 = three clear; 2 = two; 1 = one; 0 = none.
- EX131 — Milestone. One week-3 milestone with acceptance test. Rubric: 3 = demo + test; 2 = demo only; 1 = vague; 0 = none.
- EX132 — Ethics. Four-sentence ethics paragraph. Rubric: 3 = auth, synthetic, dual-use, disclosure; 2 = partial; 1 = weak; 0 = none.
Synthesis
Ship safety-relevant platform value; freeze non-goals early.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →