What you'll learn: exactly what the capstone asks you to build, what is in the dataset (with the real counts), which traps the data contains on purpose, and how the eight phases P1 to P8 map onto the course modules and hours.
Scenario
Composite scenario, not a real company. Lumen Industrial Supply is a fictional distributor of industrial equipment. Its sales engineers receive vague requests such as "We need something to monitor vibration on 40 pumps in a humid plant, budget around 30k, must work with our existing OPC UA setup". Today they search a catalog by hand and scan datasheets for the supporting sentence.
The customer wants a first version that turns such a request into structured requirements, finds matching products with the document passage that supports them, and says plainly when the documents cannot answer. All names, prices and numbers in the data are invented and illustrative.
What you build, in one picture
Figure 1. The eight phases, their host modules, hours and what exists when each is done
models and data"] --> P2["P2 - M1 - 0.7 h
API and search"] P2 --> P3["P3 - M2 - 0.5 h
extraction"] P3 --> P4["P4 - M3 - 0.7 h
evidence"] P4 --> P5["P5 - M4 - 0.7 h
workflow"] P5 --> P6["P6 - M5 - 0.4 h
access and errors"] P6 --> P7["P7 - M6 - 0.5 h
tests and eval"] P7 --> P8["P8 - M6 - 0.6 h
UI and demo"]
How to read this: each box is one phase with its host module, planned hours and the result you can run when it is done; the arrows are hard dependencies.
- You build a Python service with a small API: one discovery endpoint, one product search endpoint, one health check and a development-only token endpoint.
- A reference build exists in the course's capstone folder. It is complete and its tests pass, so you can compare your work phase by phase.
- Hours are the plan for a focused learner. Use the overrun factor from your 30/60/90 plan.
Requirements
Ten requirements define done. Each has a check you can run, which is what the rubric later scores.
| # | Requirement | How it is checked |
|---|---|---|
| R1 | Turn free text into structured requirements (category, quantity, budget, protocols, environment), with one bounded repair retry on malformed model output | A test with a deliberately malformed reply |
| R2 | Recommend only products that exist in the catalog the caller may see | Code-side validation of every SKU |
| R3 | Every recommendation cites at least one chunk that exists, as doc_id#chunk, and that really speaks about the product |
Citation check in code and in the evaluation |
| R4 | When the documents cannot support an answer, return the refusal "I cannot answer this from the documents." | Six unanswerable golden questions |
| R5 | When the request is too vague, ask clarifying questions instead of guessing | Four ambiguous golden questions |
| R6 | A public user never receives partner-only products or documents; the filter runs inside the retrieval query | Four access-control questions and a leak count |
| R7 | Superseded documents are not cited; documents that disagree are flagged to the user | One superseded and two conflict questions |
| R8 | The tool workflow is bounded (step limit, time limit, step log), tools are read-only, and the one sensitive action needs approval | Workflow tests |
| R9 | One error shape for every failure, no stack traces, and an idempotency key on the discovery endpoint | API tests |
| R10 | Tests run offline, and an evaluation harness compares strategies and writes its results to files | Test run and eval/results/ |
At the customer: "What will it never do?" A good answer is R2 to R6 in one breath: it will not invent a product, will not answer without evidence, will not guess when the request is vague, and will not show partner-only material to a public user.
The dataset, with real counts
Everything lives under the capstone's data/ folder. These counts were read from the files, not from a plan.
| Part | Count | What is in it |
|---|---|---|
Products (products.json) |
40 | 5 categories (sensors, gateways, controllers, enclosures, software), 8 each; 35 public and 5 partner-only |
Documents (docs/*.md) |
30 | datasheets, FAQs and compatibility notes; 29 public and 1 partner-only; each body is roughly 190 to 240 words |
Golden set (eval/golden_set.json) |
36 | hand-written questions, all asked as a public user |
The golden set breaks down as 12 discovery, 7 factual, 2 conflict, 1 superseded, 4 ambiguous, 6 unanswerable and 4 access-control questions. By expected outcome that is 23 answers, 9 refusals and 4 clarifying questions. Each question carries its expected SKUs, expected documents, a kind and a one-line why.