Capstone proposal

Proposal quality predicts capstone survival

Most capstones fail from scope creep and missing eval gates, not from weak coding. A graded proposal forces narrow success metrics, explicit non-goals, architecture with trust boundaries, and industry pattern citations proving you know what production looks like — before the final build module marathon.

Treat this document as the contract between you and the course rubric.

Proposal required sections

capstone/proposal.md template:

1. Problem & user — one paragraph, real or realistic persona
2. Pick-two pillars — from curriculum list (mini-LLM/SLM, agent, agentic workflow, industry pattern); justify pair
3. Success metrics — 2–3 measurable (task success rate, eval pass %, p95 latency, cost/request)
4. Non-goals — at least 5 explicit exclusions
5. Architecture diagram — trust boundaries, data classes, external vendors
6. Eval plan — golden set size buckets, canaries, red-team subset
7. Industry patterns — ≥2 cited from industry labs with "we adopt X as Y"
8. Build vs buy — summary from design review
9. Privacy/UX — pointers to sketches from sibling lessons
10. Timeline & risks — weekly milestones, top 3 risks + mitigations

Callout — Non-goals are scope weapons: "Will not support multi-language in v1" prevents capstone death by translation.

Citing industry patterns authentically

Good citation:

"We adopt Stripe-style validate→sandbox→verify for code edits (industry/stripe), scoped to SQL migration scripts only — not full repo autonomy."

Weak citation:

"We use Netflix and Uber best practices."

Name artifact, constraint, and deliberate simplification.

Grading rubric alignment (self-check)

Criterion	Evidence in proposal
Narrow scope	non-goals + metrics
Production-shaped	harness, evals, cost/trace mention
Industry literacy	2+ pattern mappings
Feasible in time	timeline with buffer week
Testability	eval gates before demo features

Score yourself; identify gaps before capstone build starts.

Close Milestone 13

milestone-13.md bundles:

• proposal.md (this lesson)
• design_review.md
• capstone_ux.md + privacy_sketch.md + flywheel_policy.md links
• Sign-off checklist: ready for architecture lesson in capstone module

Review process

If peer or instructor review available: one round before build. Otherwise 24-hour cooldown — re-read proposal next day, cut one feature.

Risk register depth

Top three risks each need: probability (L/M/H), impact (L/M/H), mitigation owner, contingency if mitigation fails. Example: "frontier API outage → demo fails → record fallback video by date X."

Alternatives considered section

Proposal stronger with rejected alternatives: "Considered pure RAG chatbot; rejected because capstone requires agentic workflow pillar and harness demo."

Advisor review checklist

If no human advisor, use rubric self-score plus 24h peer swap if available — fresh eyes catch scope creep ("you promised multimodal AND SLM AND gateway").

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)

Capstone succeeds or fails on scope control and eval plan before coding.

Diagram — Proposal gates

flowchart TD
  Idea --> Scope --> Evals --> Risks --> Go

Precise definitions & mental model

Problem statement, users, non-goals, milestones, risks.

Tradeoffs — when to use what

Ambitious demo vs finishable vertical slice.

Failure modes (interview + on-call)

No evals; dependency on unavailable APIs; kitchen-sink scope.

Production & OSS practices

Treat proposal like a design doc RFC.

Micro-project: Graded proposal

Deliver complete capstone/proposal.md meeting all sections, plus:

1. Architecture diagram image or ASCII in repo.
2. Eval plan table with ≥15 planned golden cases by bucket.
3. Industry pattern subsection ≥2 citations.
4. milestone-13.md index linking synthesis artifacts.
5. Self-grade against rubric with gaps flagged.

Acceptance: stranger understands what you will demo and how success is measured.

Checklist

• proposal.md all sections complete
• ≥2 industry patterns cited with adoption notes
• Non-goals and metrics explicit
• Eval plan with buckets and canary intent
• milestone-13.md indexes synthesis module artifacts