Your Capstone (Open-Ended Brief)

This is the moment the whole course has been building toward. You've completed three guided capstones — a production RAG assistant, a multi-tool agent, and a fine-tuned-and-served model — each one scoped, engineered, evaluated, and shipped with the training wheels on. This lesson takes them off. Your capstone is open-ended: you scope and build one project, your way, end to end — and add it to the portfolio you designed in L18.

There is no single right answer here, and that's the point. A real AI-engineering job isn't a worksheet; it's "here's a vague business problem, figure out if AI helps and ship something that works." This capstone is your rehearsal for exactly that. The skill being tested isn't can you follow instructions — you've proven that three times. It's can you take an ambiguous goal, scope it into something shippable, and finish it.

This brief gives you the four things you need to do that well:

• A menu of tracks — five proven project shapes, each extending something you already built, so you start from a position of strength.
• A scoping framework — how to go from a fuzzy idea to a shippable MVP without drowning in scope.
• The impact/effort discipline — how to cut ruthlessly to one core feature.
• A world-class rubric — what "done" looks like, so you know when you've hit the bar.

The one rule that matters most: a well-scoped project you finish beats an ambitious one you don't. A clean, deployed, well-documented RAG assistant over a domain you care about will get you hired faster than a sprawling "AGI platform" that's 40% built and doesn't run. Scope small. Build it well. Ship it.

Guided projects teach you the moves; an open-ended project teaches you the game. Everything hard about real AI engineering lives in the gap between "here's a problem" and "here's a working system" — and that gap is exactly what a self-directed capstone forces you to cross:

• Ambiguity. No one hands you the chunk size, the eval set, or the success metric. You decide them — and defending those decisions is the system-design interview (L16).
• Scoping. With infinite options, the skill is subtraction — choosing the one thing to build and cutting the rest. This is the #1 thing that separates engineers who ship from those who don't.
• Ownership. It's yours. Every decision, every trade-off, every metric is something you can speak to in an interview with total authority — the STAR stories from L15 write themselves.

And it pays off three times over. The capstone becomes (1) the strongest project in your portfolio (L18) — self-directed and end-to-end, exactly what recruiters screen in; (2) your best interview story — a system you designed and can defend layer by layer; and (3) proof to yourself that you can go from zero to shipped without a guide. That last one is the real graduation: the course made you capable; the capstone makes you independent.

You don't have to invent a project from a blank page — start from a proven shape and make it yours by pointing it at a domain or dataset you actually care about. Here are five tracks, each extending something you've already built, so you begin from strength:

How to choose. Pick the track where you have (or can get) interesting data and a real user — even if that user is you. A RAG assistant over the rulebook of a game you play, an agent that triages your GitHub issues, a fine-tune that writes in your team's style — specificity is what makes a project memorable. A generic "chat with PDF" is forgettable; "answers questions about my city's 400-page zoning code with citations" is not. And remember the bar from L18: execution quality beats novelty — a well-built version of a common idea beats a half-built original one. The interactive lets you pick a track and see the exact build plan and features.

Scoping is the skill this lesson is really about. An idea becomes a shippable MVP by running it through a short pipeline — each step a question that sharpens the last:

problem → does it need AI? → one core feature → success metric → cut scope → architecture → eval → ship

1. Problem. State it in one sentence, naming who it's for and what it does. "Help support agents answer billing questions from our 4,000-page policy PDF." Vague problems produce sprawling projects.
2. Does it need AI? Be honest. If a keyword search or a lookup table solves it, use that — reaching for an LLM where you don't need one is a red flag, not a feature.
3. One core feature. The single capability that delivers the most value. Not two. Not five. Every extra feature must be ~10× more valuable than the complexity it adds — and almost none are.
4. Success metric. One number that means "done": faithfulness ≥ 0.9 on a 100-case set, task success ≥ 85%, p95 < 2s, cost < $0.02/query. Define it before you build, or you'll never know when to stop.
5. Cut scope. Use the impact/effort matrix (next section) to keep only what fits a 2–4 week window.
6. Architecture. Reuse the course patterns — your P1 retrieve(), your P2 agent loop, your P3 QLoRA pipeline. You're assembling proven parts, not inventing from scratch.
7. Eval. Decide how you'll measure the metric: a golden set, trajectory eval, or a baseline delta. This is what turns a demo into engineering.
8. Ship. Deploy a live demo and write the README. Un-shipped is un-finished.

Notice this is the same discipline as the system-design round (L16) — clarify, scope, architect, eval, ship — applied to your own project. If you can run this pipeline on a fuzzy idea, you can run it in an interview.

The hardest part of scoping isn't adding features — it's cutting them. Modern AI tools make building feel so effortless that scope creep is the number-one reason solo projects never ship. The antidote is a simple 2×2: plot every candidate feature by impact (how much user value) against effort (how long to build).

The rules:

• Build now = high impact, low effort. This quadrant is your MVP. Ship this first.
• After quick wins = high impact but expensive. Real value, but v2 — only after the core works.
• If time permits = nice polish, low stakes. Do it only if you're ahead.
• Cut = low impact, high effort. The trap. Multi-tenant auth on a portfolio demo, a custom training pipeline you don't need — eliminate these ruthlessly.

A useful budget: a well-scoped solo capstone is ~2–4 weeks of focused work. If your plan is longer than that, you're building too much — go back to the matrix and cut. The interactive turns this into a live tool: toggle features into your MVP and watch a scope meter warn you the moment you drift over budget. Ruthless subtraction is the senior move.

"Done" needs a definition, or you'll either ship something half-baked or polish forever. Here's the bar — the same dimensions a hiring manager (and the interactive) uses to judge a portfolio project:

• Problem is specific and real. A named user and a concrete task — and it genuinely needs AI.
• One core feature, one success metric. Scoped tight, with a number that defines done.
• Scope is cut. The MVP fits ~2–4 weeks; the "cut" quadrant is actually cut.
• Architecture reuses a proven pattern. You're standing on Projects 1–3, not reinventing.
• There's an eval. A golden set, a trajectory eval, or a baseline delta — how you know it works.
• Guardrails + error handling. It abstains, retries, and fails gracefully — it doesn't just crash.
• It's deployed. A live demo URL, not a notebook.
• It's documented. A README with the problem, an architecture diagram, the metrics, and the technical decisions (the trade-offs you made and why).

Notice what's not on this list: originality, scale, novelty, cleverness. World-class here means executed well and finished, not never seen before. The single biggest differentiator is the technical-decisions section — it's where you show the judgment (name the trade-off — quality · latency · cost · safety) that every interview is really screening for. Hit this rubric and you don't just have a capstone; you have your strongest interview story.

This studio lets you scope your actual capstone right now — turn the fuzzy idea in your head into a concrete, cut-down plan.

• Pick a track — RAG, agent, fine-tune, document intelligence, or full-stack SaaS — and see the build plan and candidate features for it.
• Type your problem and success metric in the two inputs (with the "does it even need AI?" gut-check).
• Cut scope on the 2×2 — click features to add them to your MVP and watch the scope-budget meter and timeline update. Over-reach and the scope-creep warnings fire.
• Read your build plan as an arrow-connected flow of the course patterns to reuse.
• Drive the world-class rubric to 6/6 — problem specific, metric defined, scope cut, high-impact core, eval planned, ship planned.

Use it for real. Whatever track you pick, land on a plan that reads WORLD-CLASS here — a tight problem, a metric, a cut MVP that fits a few weeks — and you've done the hardest part of the capstone before writing a line of code. The rest is execution.

You are not starting from a blank repo — you're standing on a whole course of working code and patterns. The fastest path to a shipped capstone is aggressive reuse:

• Reuse the code. Your P1 retrieve() is a drop-in for any RAG or agent track. Your P2 agent loop, tool decorators, and guardrails transfer directly. Your P3 QLoRA + eval pipeline is a template for any fine-tune. Lift them.
• Reuse managed models via API. For a solo 2–4 week build, don't train from scratch — call Claude/GPT-class APIs for generation and reasoning, and a hosted embedding model for retrieval. Save custom training for the fine-tune track, and even there, QLoRA on a small model, not a from-scratch run.
• Reuse the deploy path. Modal / HF Spaces / Streamlit (L18) get you a live demo in an afternoon.
• Reuse the eval muscle. A golden set + LLM-as-judge (from the eval lessons) is your quality gate on any track.

This is also good engineering judgment, not just speed: senior engineers compose proven components rather than rebuild them, and reach for the simplest thing that hits the metric. Reaching for a custom vector DB, a from-scratch training loop, or a bespoke agent framework when a library and an API would do is the same over-engineering the interview screens out. Assemble, don't invent — then spend your scarce time on the part that's actually yours: the domain, the data, and the polish.

A well-scoped capstone is 2–4 weeks of focused work — but how you spend those weeks decides whether you ship. The golden rule: get a thin, ugly, end-to-end version deployed in week one, then improve. Working-and-ugly beats beautiful-and-unfinished. A sane plan:

• Week 1 — the walking skeleton. Scope on the 2×2, then build the thinnest slice that runs end to end and deploy it. For a RAG track: ingest a small corpus → retrieve → generate → a live URL, even if the answers are mediocre. You now have a spine to improve, not a blank page to fear.
• Week 2 — the core feature + the eval. Build the one feature that delivers the value (hybrid + rerank, the agent loop, the QLoRA run) and stand up your golden set / eval so you can measure every change against the metric. Quality becomes a number you can move.
• Week 3 — harden. Add guardrails and error handling (abstain, retry, graceful failure), fix what the eval exposes, and get the metric to target. This is where a demo becomes a system.
• Week 4 — package & ship. Write the README (problem, architecture diagram, metrics, technical decisions), record a demo GIF, write the build-story post, and pin the repo. Add it to your portfolio (L18).

If you only have two weeks, compress: week 1 = skeleton + core feature deployed, week 2 = eval + harden + package. The non-negotiables in any timeline are deploy early and eval before you polish — everything else flexes. Protect the last few days for documentation; an undocumented project is an invisible one.

Most capstones that fail, fail the same handful of ways. Know them up front:

• Scope creep. The big one. "Just one more feature" until nothing ships. Fix: lock the MVP on the 2×2 and treat everything else as v2.
• AI for its own sake. Bolting an LLM onto a problem a database would solve. Fix: the "does it need AI?" gut-check — if not, that's a stronger answer, not a weaker one.
• No eval. "It seems to work" isn't a metric. Fix: define the success number first, build the golden set early.
• Boiling the ocean with data. Trying to ingest everything. Fix: start with a small, real corpus (50–500 docs) — enough to be useful, small enough to finish.
• Perfectionism / never shipping. Polishing forever behind a private repo. Fix: deploy an ugly working v1 in week one, then improve. A live demo beats a perfect plan.
• The novelty trap. Chasing an original idea and building it badly. Fix: a well-built common project wins — execution over novelty.
• Forgetting the story. Building it but not documenting the decisions. Fix: keep a running "technical decisions" note as you go — it's your README section and your interview answers.

Every one of these traps has the same root: doing too much. The capstone rewards focus — one problem, one metric, one shipped thing, documented well. When in doubt, cut.

There's no grader here but the one that matters most: a hiring manager clicking your link. So the deliverables are the same ones from L18 — a project packaged to survive the 10-second scan. When you're done, you should have:

1. A working, deployed demo — a live URL anyone can click.
2. A public repo with a great README — problem, architecture diagram, setup, metrics (baseline → after), technical decisions, and the demo link at the top.
3. The eval artifact — your golden set / trajectory set and the score your system hits. This is the proof.
4. A one-line project bullet — outcome and a number, not a tool list ("answers questions over 400 pages of zoning code at 0.91 faithfulness; live demo").
5. A short build-story writeup — the problem, the hardest decision, the result, the links. Your STAR story, pre-written.

Add these to the portfolio you built in L18, pin the repo, and you've turned a few weeks of focused work into your strongest evidence — a self-directed system that demonstrates retrieval or agents or fine-tuning, end to end, shipped. That is precisely the profile that gets AI-engineering callbacks.

Do these for your capstone — this is the actual planning work, not a quiz.

1. In one sentence, state your capstone's problem, naming the user and the task. Then answer honestly: does it need AI?

2. Name your one core feature and the one success metric (a number) that means "done."

3. List 6 candidate features and place each in the impact/effort 2×2. Which 3–4 are your MVP (build-now)?

4. Which course project's code will you reuse as your starting point, and for what?

5. You're two weeks in and tempted to add "user accounts and a billing system." What do you do?

Answers (model shapes — yours will differ).

1. "Help home cooks find recipes they can make from what's in their fridge, from my 2,000-recipe collection." Does it need AI? Yes — matching fuzzy natural-language ingredient lists to recipes is semantic, not a keyword lookup. (If the answer were "no," that's a better finding — pick a different problem.)

2. Core feature: "given a list of ingredients, return the 5 best-matching recipes with what's missing." Metric: "≥80% of results judged 'makeable' on a 50-query test set; <2s p95."

3. MVP (build-now): ingredient→recipe retrieval (hybrid), a rerank, a small eval set, and a deployed demo. After (v2): substitution suggestions, dietary filters. Cut: user accounts, a mobile app, meal planning.

4. Project 1's retrieve() and the RAG pipeline — swap the corpus to recipes and the metric to "makeable," reuse chunking, hybrid search, and the eval harness.

5. Don't. That's the cut quadrant (low portfolio impact, high effort) and pure scope creep. Note it as "v2," and spend the time making the core feature excellent and the demo live. Ship the scoped thing.

• "A capstone should be ambitious and original." → It should be well-scoped and finished. Execution beats novelty; a shipped common project beats an unshipped original one.
• "More features = a better project." → One core feature done well wins. Every extra must be ~10× the complexity it adds — almost none are. Scope creep is why solo projects die.
• "I'll figure out the metric later." → Define the success number first, or you'll never know when it's done. The metric shapes the whole build.
• "Using AI is the goal." → Solving the problem is the goal. If a lookup works, use it — "it doesn't need AI" is a senior answer.
• "Start from scratch to show my skills." → Reuse your course code and managed APIs. Composing proven parts is the senior skill; from-scratch reinvention is the over-engineering interviews screen out.
• "Ship when it's perfect." → Ship an ugly v1 in week one, then improve. Un-shipped is un-finished; a live demo beats a perfect private repo.
• "The build is the deliverable." → The packaged, documented, deployed project is — README, diagram, metrics, technical decisions, demo. An undocumented repo is invisible (L18).

• The capstone is your graduation from guided to independent. Take a fuzzy goal, scope it, and ship it — the exact skill a real AI-engineering job tests.
• Pick a track that extends what you built (RAG / agent / fine-tune / document intelligence / full-stack SaaS) and point it at a domain you care about. Specificity makes it memorable.
• Run the scoping framework: problem → does-it-need-AI → one core feature → success metric → cut scope → architecture → eval → ship. Same discipline as the system-design round (L16).
• Cut ruthlessly with the impact/effort 2×2 — build-now = high-impact/low-effort is your MVP; eliminate the low-impact/high-effort trap. Aim for a 2–4 week scope.
• Reuse everything — your Project 1–3 code and managed APIs. Compose proven parts; don't reinvent. Simplest thing that hits the metric.
• Hit the world-class rubric: specific problem, one metric, cut scope, reused architecture, a real eval, guardrails, deployed, and documented (with the technical-decisions section).
• A finished, well-scoped project beats an ambitious unfinished one — every time. Scope small, build it well, ship it, document it, add it to your portfolio.
• Next — L20 (Course Conclusion & The Road Ahead): you've built four projects, learned the interview, and shipped a capstone — the finale on where you are and where to go next.