The brief

Build and ship one complete AI system that solves a real, narrow problem — end to end. Pick a domain you know or care about (support assistant over docs, a research agent, an internal-tool automation, a domain-specific Q&A). The requirement isn't scale or novelty; it's completeness across the lifecycle: a real input produces a real, grounded, evaluated output that a user would act on, running in a deployed environment, with the business case written up.

Good capstone shapes (all doable as a narrow slice):

• A RAG assistant over a real document set, with citations, abstention, and an eval suite.
• A tool-using agent that automates a specific multi-step task with human approval on consequential actions.
• A hybrid (Track 4) — a no-code trigger calling your deployed code service — mirroring real client delivery.

The lifecycle — every track, once

The capstone is the course in sequence. Walk each phase, pulling the specific track:

Phase 1 — Discover & scope (Track 8.1). Write the problem, its cost, success metrics, and a narrow first slice. Even if it's a personal project, do this honestly — it's what a client engagement starts with.

Phase 2 — Build the core (Tracks 1–4).

• A clean Python service (FastAPI), tested, typed (Track 1).
• The LLM integration — prompts, structured outputs, the right model (Track 2).
• If knowledge-based: the RAG pipeline — chunk, embed, vector store, hybrid retrieval, reranking (Track 3).
• If multi-step: the agent — tool calling, the loop, memory, orchestration; and the honest chain-vs-agent call (Track 4).

Phase 3 — Evaluate & harden (Tracks 5–6).

• A golden set + eval suite with real metrics (faithfulness, task success) and a threshold (Track 5).
• Observability — traces, cost, latency (Track 5).
• Guardrails, safety, and data protection — input/output filtering, PII handling, and (if multi-tenant) isolation; injection-aware design (Track 6).

Phase 4 — Deploy (Track 7).

• Containerize it; run it somewhere real (a managed container platform is plenty) (Track 7).
• A minimal CI/CD pipeline with the eval gate (Track 7.2).

Phase 5 — Package & present (Track 8).

• The ROI/business case — value, honest TCO, payback (Track 8.2).
• The stakeholder-ready narrative and a demo on realistic inputs (Track 8.3).
• The case study write-up (below).

The track → capstone checklist

Use this to verify you actually exercised the whole course. Aim to check every row (skip a row only with a reason — e.g. "no multi-tenancy, single user"):

Track	Capstone evidence
1 Python	Tested, typed FastAPI service
2 LLM Foundations	Deliberate model choice; structured outputs; tuned prompts
3 RAG	Chunking + vector store + hybrid retrieval + citations (if knowledge-based)
4 Agentic	Tool calling / agent loop with a justified chain-vs-agent decision
5 Eval/Ops	Golden set + eval suite + threshold; traces + cost/latency
6 Security	Guardrails, PII handling, injection-aware design, tenant isolation (if applicable)
7 Deploy	Containerized + deployed + CI with an eval gate
8 Delivery	Discovery doc, ROI/business case, case study, realistic demo

Scope discipline (the thing that makes it finishable)

The capstone fails the same way real projects do: over-scoping. Apply Track 8.1 ruthlessly — one workflow, one user, one document set, one channel. A RAG assistant over 200 pages of one team's docs, fully evaluated and deployed, is a far stronger capstone than a half-built platform over 5,000. Depth across the lifecycle beats breadth of features. Build the riskiest part (usually retrieval quality or a flaky integration) first so you learn early whether the slice is viable.

The case study (your actual deliverable)

The system is the work; the case study is the asset. It's how a client or employer evaluates you, and for a consultancy it's a reusable sales artifact. Structure it as the story of value delivered, not a tech tour:

1. The problem — what it was and what it cost (Track 8.1 framing).
2. The approach — the solution and why this scope (and what you deliberately deferred).
3. How it works — a brief, honest architecture (RAG/agent/deploy), at a stakeholder's altitude.
4. Results — eval scores tied to a business metric, cost/latency, and the ROI/payback (Track 8.2).
5. Honesty — limitations, what you'd do next, what you learned. (Naming limits builds credibility — Track 8.3.)
6. Demo — a link or recording on realistic inputs, including an abstention and a graceful error.

Lead with the problem and the outcome; the technology is supporting evidence. That framing — value first, tech as proof — is exactly what separates a consultant from a coder, and it's the note the whole curriculum ends on.

Pitfalls

• Over-scoping. The classic capstone killer — narrow to one complete slice; depth over breadth.
• Skipping the unglamorous tracks. No evals, no guardrails, no deploy = a demo, not a system. The checklist rows are the point.
• A notebook, not a system. If it only runs locally in a notebook, you skipped deploy — ship it somewhere real.
• A tech-tour case study. Leading with architecture instead of problem/outcome reads as a coder, not a consultant.
• Demoing on easy inputs. Show it on realistic and hard cases, including an abstention — the demo trap from Track 8.3.

Recap

• The capstone is the entire course applied once: one real, narrow problem taken from discovery → build → evaluate/harden → deploy → package.
• Deliberately exercise every track and verify with the track→capstone checklist — evals, guardrails, and deploy are what make it a system, not a demo.
• Scope ruthlessly: one complete, deployed, evaluated slice beats a broad half-built platform; build the riskiest part first.
• The case study is the real deliverable — lead with problem and outcome, tie eval results to a business metric and ROI, and be honest about limits.
• Value first, technology as proof — the stance that turns everything you learned into delivered value.
• Worked examples map to the exercises: scope your capstone (Ex 1), build the core (Ex 2), deploy with an eval gate (Ex 3), write the case study (Ex 4).