Capstone: ship something real
Build one small application that another person can inspect.
In this lesson · 10 of 10
All lessons in this track →Saved in this browser. View your learning.
Start with the idea
Build one small application that another person can inspect.
Choose the simplest pieces the task needs. Show how inputs are checked, results are verified and denied actions are handled. A useful demo does not need every AI feature.
Mock: A controlled stand-in used for testing instead of a live service.
See the example and check your understanding
A made-up teaching example
The record-to-draft demo needs input checks, a mock generator, source checks and a reviewer. It may need neither an agent nor document search. A denied record should produce no draft.
Ask yourself
Should the demo hide denied access to make it look successful?
Show the explanation
No. Show the failure path clearly. Label mocks and keep claims limited to what the offline demo proves.
Start with these checks
- Justify each component.
- Include success and failure cases.
- Give a reviewer repeatable run instructions.
Use the different practice case below and check every requirement in its full instructions.
The video explains the main idea. Use the sources, instructions and checks below to complete the practice.
Captions appear here during playback.
Capstone: ship something real
Build one small application that another person can inspect.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Build one small application that another person can inspect.
What appears on screen
Build one small application that another person can inspect.
0:06 · The idea
Choose the simplest pieces the task needs. Show how inputs are checked, results are verified and denied actions are handled. A useful demo does not need every AI feature.
What appears on screen
Choose the simplest pieces the task needs. Show how inputs are checked, results are verified and denied actions are handled. A useful demo does not need every AI feature.
0:20 · One useful term
Mock. A controlled stand-in used for testing instead of a live service.
What appears on screen
A controlled stand-in used for testing instead of a live service.
0:28 · A worked example
The record-to-draft demo needs input checks, a mock generator, source checks and a reviewer. It may need neither an agent nor document search. A denied record should produce no draft.
What appears on screen
The record-to-draft demo needs input checks, a mock generator, source checks and a reviewer. It may need neither an agent nor document search. A denied record should produce no draft.
0:44 · Your turn to think
Should the demo hide denied access to make it look successful? Pause and decide before continuing.
What appears on screen
Should the demo hide denied access to make it look successful? Pause the video if you need more time.
1:01 · Why this answer works
No. Show the failure path clearly. Label mocks and keep claims limited to what the offline demo proves.
What appears on screen
No. Show the failure path clearly. Label mocks and keep claims limited to what the offline demo proves.
1:11 · Check 1
Justify each component.
What appears on screen
Justify each component.
1:16 · Check 2
Include success and failure cases.
What appears on screen
Include success and failure cases.
1:22 · Check 3
Give a reviewer repeatable run instructions.
What appears on screen
Give a reviewer repeatable run instructions.
1:27 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
Lesson preparation and outcomes
Prerequisites: Earlier Python, validation, eval and telemetry lessons.
By the end, you can: Integrate only justified components and present reproducible evidence.
Worked scenario and practice feedback
A synthetic record-to-draft task needs validation, a generation fixture, source-fact checks and a reviewer. It may need neither retrieval nor an agent. If a record is denied, the demo shows the denial and produces no draft rather than hiding the failure.
Guided and independent practice: Write the spec, build offline, then independently reproduce a normal case, denial and recovery from a clean copy.
Answer criteria: Architecture choices tied to task; mocks labeled; no mandatory public repository, private records or deployment; unsupported operational and employment claims excluded. If the local pack or interpreter is unavailable, trace the synthetic input, expected output and failure guard on paper; label execution unverified. Required practice uses no paid API calls, accounts, purchase, operational data or actual deployment.
Nine lessons of reps. One thing left: build one focused task using justified pieces. The capstone is the project you point at when a hiring manager asks “what have you built?” The brief below is the spec. The drill is the build.
Part 1 What makes a good capstone.
Three filters. If a project passes all three, it’s the right one.
- It solves your own problem. You will spend 20+ hours on this. If the user is you, you’ll know within a week whether it works.
- It justifies its architecture. Use Python, a declared input/output contract, an evaluation set and bounded instrumentation. Select direct lookup, retrieval, structured generation or tool use only when the task needs it; no vector database or agent is mandatory.
- It’s small enough to ship. You should be able to demo a working version in week 4. The remaining weeks polish.
Examples that fit:
- A synthetic service-record assistant. Use invented service entries with explicit evidence IDs to draft supported resume language. Do not ingest real personnel records.
- A federal contract search and explainer. Ingest SAM.gov solicitations weekly. Ask it about specific contracts in plain English. Highlight ones matching saved interests.
- A SkillBridge / VET TEC navigator. Find SkillBridge employers near you, summarize program terms, draft outreach emails. Search by branch, MOS, separation date.
- A peer-NCO veteran-help bot. RAG over VA benefits PDFs, USERRA documentation, and TRICARE rules. Free, answers in plain language, cites the source PDF.
Pick one, or pick something similar to one. Don’t pick ten.
Data boundary: the required capstone uses synthetic records and offline fixtures. No real personnel data, accounts, purchases, paid API calls or deployment are required. Local processing still needs permissions, logging controls and deletion rules; location alone does not remove risk.
Part 2 The spec format.
Before you write code, write a one-page spec. Same shape every capstone uses.
PROJECT NAME
One-line description.
USER
Who this is for. One sentence.
PROBLEM
The specific pain this solves. One paragraph.
WHAT IT DOES
Three to five bullets, in plain English.
WHAT IT DOES NOT DO
Three to five bullets. Scope discipline.
INPUTS
What the user provides. What you ingest.
OUTPUTS
What the user gets. Format, length, examples.
ARCHITECTURE
Diagram or sketch. Boxes and arrows. One page max.
SUCCESS METRIC
Task-quality metric with denominator and slice rules, plus critical safety/access gates that cannot be averaged away.
OPEN QUESTIONS
What you don't know yet. Three to five items.If you can’t fill in the SUCCESS METRIC box, you’re not ready to start. Build it last and the project drifts.
Part 3 Scope discipline: the move that finishes capstones.
The most common failure mode for capstones is scope creep. The fix is brutal honesty about WHAT IT DOES NOT DO.
Three rules that hold the line:
- One user. You build for yourself for the first version. Generalizing to “veterans” comes later. Generalizing to “people” doesn’t come at all.
- One job. If you can describe the job in two sentences, the project will finish. If it takes a paragraph, cut.
- One useful walkthrough. Show a normal synthetic case and one meaningful failure or denied action. Preserve test evidence beyond the presentation; a polished demonstration alone does not establish reliability.
Things that are tempting and that you should NOT add to v1:
- Accounts for the offline synthetic demo; include simulated identity if authorization is part of the task
- A pretty frontend (a working CLI or basic web form is fine)
- Real-time updates
- Multi-tenant anything
- Mobile
A good capstone is small, sharp, and finishable. A bad one is sprawling, demo-able only with caveats, and never quite ready.
Part 4 What you deliver.
Deliver six inspectable artifacts:
- A local repository or private archive with a clear README and synthetic inputs; public publication is optional.
- An offline demo with exact run commands or a recorded walkthrough. Label mocked model output prominently.
- An evaluation set covering normal, missing-evidence, boundary and prohibited-action cases with predeclared criteria.
- Allowlisted metadata logs and a retention/deletion policy; no real prompts or personal records.
- A resource estimate that separates measured local work from invented rates and unverified provider assumptions.
- A decision record connecting task, selected model or mock, deployment boundary, harness/tools, evidence and human owner.
A reviewer should reproduce at least one normal and one failure case. A smooth demonstration alone is not sufficient evidence, and completion does not promise employment or operational authorization.
Part 5 A note on honest scoping.
If the capstone is for a civilian job application, two more rules:
- Be honest about what’s AI and what isn’t. Don’t dress up a CSV filter as an “AI-powered intelligence platform.”
- Be honest about cost. State measured usage separately from estimates and invented rate cards. A mock has no provider bill; report unknown live cost rather than inventing a number.
Veterans bring credibility about discipline. Don’t trade it for hype. The work is more impressive when you don’t oversell it.
Interface/reference limits
Use the workflow reference to connect task, model, deployment, harness/tools, evidence and the responsible human decision. Synthetic demonstrations establish only the stated tested conditions.