Practice: design, build, defend
The capstone’s real practice is the build itself, and the lesson body carries the full assignment, phases, and rubric. This page adds two things: a self-check to run on your written defense, and a flashcard set that spans the whole track, because the capstone is also the moment to consolidate all eight lessons.
Defense self-check
Section titled “Defense self-check”Run these against your finished defense page. Answer honestly before opening each answer.
1. Read your “where judgment lives” section. Does every item state WHY it is in its pile (model, code, or human), or just that it is?
Show answer
The why is the defense. “The model classifies the request” is a description. “The model classifies the request because misclassification is cheap and reversible here, while publishing is code-gated because one wrong publish is not” is a defense. Every line should survive the question “and what happens if that is wrong?”
2. Does your “what I traded away” section contain at least one trade that genuinely hurts?
Show answer
If every listed cost is painless, the section is a sales pitch wearing a defense’s clothes. Real designs give up real things: latency for a review step, capability for predictability, coverage for reliability. Name the one a critic would raise, before they do.
3. Could a reader of “what breaks first” predict the failure’s appearance from the outside?
Show answer
“The tool might fail” is not a prediction. “If the source document is a scanned image, extraction returns nulls across all fields, the semantic check finds nothing to compare and passes, and the output looks complete but empty” is. The test: could someone monitoring the system recognize the failure from your description alone?
4. Does “what I did not build” include at least one thing that would have been impressive?
Show answer
Declining boring features is easy. The section earns its place when it declines something that would have demoed well: the second agent, the broader scope, the flashier output. That refusal, with its reason, is the most senior line in the document.
5. Final check: put your lesson 1 sketch beside the finished design. What are the three biggest differences?
Show answer
There is no single right answer, but the common pattern is: the sketch trusted the model with rules that the design later moved into structure; the sketch put too much on the desk (carried context that could have been fetched); and the sketch either wanted more agents than the job needed or never asked whether the path was predictable at all. Whatever your three are, they are the track’s teaching, made visible.
Track-final flashcards
Section titled “Track-final flashcards”Q. What is the one-sentence definition of architecture this track is built on?
Architecture is deciding where judgment lives: what the model decides, what the code guarantees, and what waits for a human.
Q. Workflow versus agent: what is the line, and which do you reach for first?
A workflow follows predefined code paths; an agent directs its own process. Reach for the workflow first, and escalate to an agent only when the path cannot be known in advance.
Q. Where do a team's standards for Claude live, so every teammate inherits them?
In the project’s checked-in configuration: the project memory file for universal standards, path-scoped rules for conventions tied to file types, and project-scoped commands and skills for shared workflows.
Q. How does a schema stop a model from fabricating missing data?
By making absence legal: fields that may not exist are nullable, so “not in the document” is a valid answer instead of a gap the model must fill with something plausible.
Q. What guarantees shape, and what does it not guarantee?
Schema-constrained output guarantees syntax, the shape always parses. It does not guarantee semantics: values can still be wrong, sums can disagree, fields can be swapped. Semantic checks stay in code.
Q. What does a model actually read when choosing a tool?
The tool’s name, description, and input schema. Never the source code. The description is the tool.
Q. What should a well-designed tool error tell the agent?
What kind of failure it was (transient, business rule, permission), whether retrying can help, and, separately, whether an empty result was a failure at all or a successful search that found nothing.
Q. What does a subagent know about the conversation that spawned it?
Nothing, unless it is told. Subagents run with isolated context; whatever they need must be passed explicitly in their brief. The brief is their world.
Q. How should failure cross an agent boundary?
As structure: what failed, what was attempted, any partial results, and possible alternatives. Silently swallowing the error and killing the whole run are both anti-patterns.
Q. Name two popular escalation signals this track told you not to trust.
Customer or user sentiment, and the model’s self-reported confidence. Neither tracks real case difficulty. Escalation criteria should be explicit, observable conditions decided in advance.
Q. Why does an independent instance review better than the author instance?
The author instance carries the reasoning that produced the work and rarely questions its own decisions. A fresh instance reads the work without that context, the way a colleague does.
Q. What makes an unattended pipeline run the purest test of architecture?
Nobody is there to catch it. Every judgment call had to be made in advance and written down, so the run exercises the design, not the operator.
Q. What are the four headings of the capstone defense?
Where judgment lives. What I traded away. What breaks first. What I did not build.
Q. What is the most senior sentence in this field, and where does it appear in the capstone?
“This does not need an agent.” It appears in the defense under what I did not build, with the reason attached.