Write-up and demo

Graduate promise: explain, ship, evaluate, situate

The capstone write-up is how you communicate engineering judgment — not a README duplicate. A strong post explains the problem, architecture, tradeoffs, eval outcomes, failures, and explicit comparison to industry patterns from company labs. Optional video comes later; written post is the graded artifact that survives link rot.

Package deliverables so a reviewer finds everything in <5 minutes: demo, eval report, architecture, post link.

Written post structure

capstone/POST.md (or published blog URL linked):

1. Hook — user problem in one story
2. What shipped — pick-two pillars in plain language
3. Architecture — diagram + trust boundaries paragraph
4. Eval results — numbers, not adjectives; include one failure
5. Industry comparison — "Unlike demo agents, we …" citing Netflix/Uber/Stripe/Shopify/Airbnb patterns by name
6. What we'd do next — BACKLOG prioritized
7. How to run — link repo section

Target 1,200–2,000 words — technical blog tone, not academic.

Callout — Compare explicitly: "Shopify Sidekick-class eval loops" + what you simplified (10 cases vs. thousands) reads stronger than "production-ready."

Demo package

capstone/demo/ contains:

• script.md — live steps
• recording.md — link to optional video or GIF placeholders
• seed_data/ — fixtures for reproducible demo
• expected_output.txt — snippet of success trace

Live demo checklist:

• API keys loaded
• Canaries green within last 24h
• Fallback recording if network fails

Repo deliverables index

capstone/DELIVERABLES.md:

Artifact	Path
Scope freeze	capstone/scope_freeze.md
Architecture	capstone/architecture.*
Eval plan + report	capstone/eval_plan.md, eval_report.md
Golden set	evals/golden.jsonl
Post	capstone/POST.md
Runbook	RUNBOOK.md
Industry mapping	capstone/industry_mapping.md

Zip or tag release capstone-v1 in git optional but recommended.

Milestone 15 completion rubric self-check

• Pick-two pillars demonstrable in one demo
• Metrics vs. scope freeze reported honestly
• Eval gates documented and runnable
• Industry patterns named with simplifications
• Stranger can run README demo
• POST.md published in repo

Write milestone-15.md reflection: what ShipAI changed in how you ship AI products.

Optional video (later)

If recording:

• 3 minutes max
• Screen + voice; show trace/waterfall briefly
• Link from POST.md — not substitute for written analysis

POST.md distribution

Publish as repo doc, optional Dev.to or personal site mirror — link in README. Canonical URL in DELIVERABLES.md for graders.

Peer review before publish

Swap POST.md with peer for clarity pass — fix jargon, verify metrics match eval_report numbers exactly. Mismatch between post and report destroys credibility.

Portfolio storytelling for hiring

Lead POST with problem and outcome metrics recruiters scan in 30 seconds — architecture depth below fold. Optional POST_recruiter.md one-pager summary if main post is long.

Putting it together in practice

ShipAI treats this lesson as executable curriculum, not reading alone. Before marking complete, trace one real request through your portfolio stack and label where this lesson's concepts apply — even if the first pass is messy. Document what broke in the module README; that gap list becomes your next sprint.

Compare your implementation against the industry callouts cited earlier without copying their scale. Name one deliberate simplification you kept (mock auth, SQLite not Postgres, single-region deploy) and one simplification you refuse to ship without (no eval gate, no trace on mutating tools, no fail-closed guardrail on exfil cases). That contrast is what interviewers and graders look for.

Callout — Teach back: Explain this lesson's core tradeoff to a peer in five minutes without slides. If you cannot, re-read the failure modes section and add an example from your own run logs.

Common questions and misconceptions

"Is this overkill for a side project?" Side projects can skip pieces; capstones and production cannot skip knowing the pieces exist. You may waive cost accounting in v1 but your architecture diagram should still show where it would attach.

"Should I rewrite from scratch?" Extend what you built in prior modules — graders reward evolution, not parallel unused folders. Link file paths in your checklist.

"Which metric matters most?" The metric tied to user harm or revenue: policy violations, failed refunds, silent wrong answers — not vanity leaderboard scores.

Extension paths after the micro-project

After the micro-project passes smoke check, choose one extension aligned with your capstone pillar: tighten eval coverage, add a chaos or red-team case, or wire observability into SSE streams. Extensions belong in BACKLOG unless scope freeze explicitly includes them — avoids capstone death by optional polish.

Engineering problem (staff framing)

Writeup and demo are the interview artifacts. Rehearse failure narration.

Diagram — Demo arc

flowchart LR
  Hook --> Arch --> Live --> Eval --> Limits --> Next

Precise definitions & mental model

Story, metrics, live path, known fails, next steps.

Tradeoffs — when to use what

Live risk vs recorded backup.

Failure modes (interview + on-call)

Click-only demo; hiding metrics; no backup path.

Production & OSS practices

README + 5-min video + eval JSON in repo root.

Micro-project: Post + demo package

Ship:

1. POST.md meeting structure above with industry comparison section.
2. demo/ folder with script and expected output.
3. DELIVERABLES.md index complete.
4. Final eval_report.md matching post numbers.
5. milestone-15.md course reflection.

Acceptance: DELIVERABLES.md links all resolve; post cites ≥2 industry patterns with honest gap analysis.

Checklist

• POST.md published with eval numbers and failures
• Industry comparison explicit (≥2 patterns)
• Demo package with script and seed data
• DELIVERABLES.md complete
• milestone-15.md reflection committed