Requirements gathering
Choose your own production use case and write the requirements brief: inputs, outputs, stakes, signals, and the failure-cost table.
The triage assistant was the worked example. Your capstone is the real thing: a production prompt system for a use case you own — built with every layer of this course and documented so a stranger could run, evaluate, and maintain it. First: requirements. Unglamorous, decisive.
Choosing the use case
- Recurring and structured: the same kind of input arriving repeatedly — tickets, applications, reports, transcripts, invoices. One-off tasks don't need a system.
- Machine-consumable output: something downstream reads the result (a queue, a sheet, a dashboard, another prompt). If only a human reads prose output, Foundations-level workflows suffice — pick something with a schema.
- Real but bounded stakes: consequential enough that the guardrails matter, not so consequential that a course project shouldn't touch it. Triage, extraction, drafting, and summarization systems are the sweet spot; anything in Foundations' five no-go categories is out.
The requirements brief (deliverable 1)
- 1Inputs: what arrives, in what format, with three REAL redacted samples — including one ugly one. (Requirements written from imagined-clean inputs are fiction.)
- 2Output schema, v0: fields, types, enums, null policy, and one line per field naming its downstream consumer.
- 3The failure-cost table: for each output field, what happens if it's wrong? 'Wrong category → mis-routed, 1h delay' vs. 'wrong amount → money moves'. This table drives every guardrail decision you'll make in the build phase.
- 4Routing signals you'll need: confidence? grounding flag? self-consistency on which field?
- 5Success criteria as numbers: 'category exact-match ≥ 95% on the golden set; zero refund-promise violations; ≤ 5% routed to humans.' If you can't state the numbers, you're not done gathering requirements.
Interview me to complete a requirements brief for a production prompt system. Ask one question at a time — about inputs, output consumers, failure costs, volumes, and edge cases I'm not thinking of. Push back when my answers are vague. After ~10 questions, draft the brief in the structure I give you: [paste the brief structure above].
The model as requirements analyst is one of its best roles — relentless about the questions humans skip. Answer honestly; vague answers here become guardrail gaps once you reach the guardrail phase.
One input type, one output schema, 20-case golden set. The impressive capstone isn't the one with the most features — it's the one where the routing table and the failure-cost table visibly agree.