Capstone: Design
Pick the automation from your opportunity map, write the full design doc — spec, AI seats, gates, pre-mortem, data check — and get it reviewed before you build.
The capstone ships a real automation for your work, end to end: design → build & test → live operation with a runbook. Not a demo — a workflow that's still running a month after the course ends, with your name on it as owner. Design comes first, on paper, reviewed before any building. (Riley's course-long build followed exactly this arc; now it's your map, your chore, your v1-to-v3.)
Choosing (your Module 1 map already did the work)
- Take your opportunity map's #1 or #2 — unless the course changed your scoring (it usually does: learners discover their true first pick was hiding in the 'assist' column now that gates make assists buildable).
- It must run at least a few times a week — the two-week soak (next lesson) needs real traffic to prove anything.
- It should use at least one AI step and at least one gate if it acts externally — the certificate attests the full skill set, so the capstone should exercise it. A purely deterministic workflow needs written justification for why no judgment step belongs (which is itself a passing answer if it's true).
- Check the data policy before designing: what flows through the AI step, is the platform approved, does any customer data need masking? One paragraph in the design doc, signed off by the standard your workplace uses. Real automations on real data earn real scrutiny — welcome it now, not after.
Check the platform's app directory FIRST, during design — not build week. If your core system isn't listed, bridges exist: email-in/email-out (most systems can send or receive mail), CSV export/import on a schedule, or asking IT whether the system can send webhooks (a webhook = the system pushing a message to a URL when something happens). If none of those work, pick your #2 opportunity instead — a shipped second choice beats a stalled first one.
The design doc (two pages, six sections)
- 1The chore and the math: what it is, weekly minutes, error rate, latency cost — and the payback estimate.
- 2The spec, in the format you've used all course: trigger, filters, steps (deterministic vs. AI marked), paths, outputs. If you can't write the spec, you're not ready to build — the spec is the thinking.
- 3AI seats: each AI step's job (classify/extract/draft/summarize), its contract prompt sketch, and its test-suite plan (12+ cases including one adversarial).
- 4Gates & routing: what gets gated and why, the approval message contents, the timeout policy, the asymmetric-routing table (which categories auto-proceed at which confidence).
- 5The pre-mortem table: per step — likely failure, transient/persistent/dangerous, and where it lands. Problem folder and alert tiers specified.
- 6Success criteria: 3 checkable sentences for the soak ('≥90% of runs complete without human rescue', 'unsure lane under 15%', 'zero double-sends'). Written now, so the verdict later is a measurement, not a mood.
Show the doc to one person — a colleague, your manager, the course community — with three questions: what breaks first? what did I forget to gate? would the payback math survive your skepticism? Every design survives its author; the good ones survive a reader. Reviewers who've taken this course will go straight for your retry-safety and your timeout policy, because those are where designs actually fail.