Capstone roadmap
Work a full example
A worked project proves the method by showing decisions, failures, corrections, and evidence.
Before you start
Why this matters
Without opening an AI tool, write the acceptance test for this job: plan and ship a personal knowledge assistant in staged, testable layers. Name one fact that must be exact, one judgment a person must make, and one condition that should stop the workflow. Compare your answer with the professional standard below; the gap is what you should practice.
1Learn the idea
Read
Project brief
The project is to ship a cited personal knowledge assistant from thin vertical slice through monitored release. The user is a mentor or hiring manager reviewing engineering judgment. Definition of done: the intended action is clear, the candidate uses approved evidence, blocking safety checks pass, and another person can reproduce the key result.
Stage 1: prepare
Create the job card and collect one user problem, success metric, constraints, architecture sketch, milestone dependencies, evaluation set, risk register, and weekly capacity. Remove or replace prohibited material: use synthetic or personally owned documents initially; separate secrets, user content, telemetry, and model prompts with least-privilege access. Add one ordinary case, one boundary case, and one hostile or misleading case. Record unknowns instead of filling them with plausible guesses.
Stage 2: draft
Turn this capstone goal into six two-week milestones: an assistant answers questions from my approved notes with citations. Sequence API, structured output, retrieval, citations, tools, memory, evals, injection defense, tracing, retries, deploy, and monitoring. For each milestone define a demo, test, dependency, risk, and stop rule. Do not pretend all layers fit at once.
The first candidate should be A dependency-aware roadmap that ships a narrow cited-answer slice early, then adds quality and operational layers behind explicit gates. In this worked run, imagine it also exhibits one realistic defect from this set: building twelve disconnected demos; adding memory before correctness; no eval baseline; hidden infrastructure work; deploying without tracing or rollback. Do not hide the defect. Mark the exact criterion it violates and decide whether the cause belongs to context, instruction, model capability, or the surrounding process.
Stage 3: repair narrowly
Issue a targeted revision:
Revise only the failed criterion identified below.
Preserve all verified content and the original output contract.
Do not add facts or assets.
Return the corrected artifact plus a one-line change note.
Failed criterion: [paste criterion and evidence]
A narrow repair keeps the review surface understandable. If the model cannot repair without new authoritative information, pause and obtain that information.
Stage 4: verify and release
Now demo each milestone against golden tasks, inspect citations, run eval gates, test hostile inputs, review traces, exercise retries, and rehearse rollback. Record pass/fail evidence for each criterion and have the named reviewer make the release decision. One evolving codebase tells a stronger story than twelve unrelated labs. Every layer must improve a user outcome and leave evidence that the improvement is real. Save limitations in language the audience can understand.
Read
Retrospective
The durable deliverable is not only the final result. It is a capstone evidence portfolio with roadmap, architecture decisions, demos, eval reports, risk log, traces, release notes, and retrospective. Write what surprised you, which check found it, what you changed, and which control should become the default. A clean retrospective distinguishes a prompt improvement from a data, tool, or policy change.
Continue learning · glossary & guides
- Can the reviewer see the failed first attempt and why the correction was justified?
- Does the release packet contain evidence, ownership, and known limitations?
- Reference · Related concept
- Previous
- Next