Capstone: ship a tiny AI app
Ship and explain the grounded café FAQ application
Page 8 advances one concrete grounded café FAQ application: explain the decision, run the code, inspect failure, measure evidence, and keep only what is ready to ship.
Before you start
Why this matters
Without running code, predict the output of this page's example and name the intermediate value that would prove your prediction. Then write one sentence answering: “What could look successful while actually being wrong?” For this stage, focus on capstone that cannot be trusted or demoed. Keep the prediction nearby; comparing it with the real output is the first debugging exercise, not a quiz about syntax.
1Learn the idea
Read
Build focus
The final artifact is a dependency-free Python CLI, README-ready demo commands, release checklist, and rollback to the previous FAQ snapshot. A reviewer should be able to reproduce the demo from one command, see the expected result, run the tests, and find the known limitations. Shipping does not mean claiming the toy solves every version of the problem. It means the intended case is measurable, failures are legible, and the previous working artifact remains recoverable.
The artifact's user-facing goal is specific: combine input validation, five-note retrieval, a cited answer, tests, logs, and a two-minute demo into one finishable application. Its accepted input is a user question plus a reviewed local FAQ collection with stable source IDs. Those statements are intentionally narrower than “build an AI system.” Narrow scope lets us inspect every input and expected result, and it prevents a toy result from being presented as a production claim. This final smoke check summarizes the evidence you will present during the two-minute demo.
Read
Run the example
Save this as lesson.py and run python3 lesson.py. It uses only the language standard library, so the example is reproducible offline.
release={'docs_version':'faq-2026-07-18','gold_pass':3,'gold_total':3,'owner':'cafe-ops','rollback':'faq-2026-07-01'}
assert release['gold_pass']==release['gold_total'] and release['rollback']
print(release)
Expected output: a complete release record with rollback. Exact floating-point formatting may vary slightly, but the asserted behavior must not. Read the output as evidence about this stage, not merely proof that the interpreter started.
Read
Debug the stage
Walk one question through validation, tokenization, score table, selected FAQ ID, cited answer, and safe event record. If the clean-room demo fails, resist adding setup prose until you reproduce the missing assumption. Unsupported questions must reach the abstention branch. Treat a source containing instructions as data and sanitize or reject it during review.
At the mastery and shipping stage, save the smallest failing fixture beside the expected result. Change one cause at a time and rerun the exact command printed above; that makes the repair reviewable and keeps this chapter's progressive artifact reproducible.
Read
Evaluate before continuing
Run golden questions for every FAQ note and unsupported questions for abstention, then review citation support by hand. Time the two-minute demo from a clean checkout and ask another person to follow it without coaching. Record the FAQ version, passing counts, response time, owner, and tested rollback snapshot. Those are the capstone's shipping claims.
For this mastery and shipping page, preserve the fixture and result as evidence for the next page. Label observations separately from conclusions: a passing assertion establishes the behavior it names, while broader usefulness requires the chapter's full evaluation set and stated operating limits.
Continue learning · glossary & guides
- [ ] Can a second person run the demo without coaching?
- [ ] Are expected output, evaluation evidence, and limitations visible?
- [ ] Has the failure and recovery path been rehearsed?
- [ ] Can another person complete the cited FAQ demo in two minutes?