What you need to know
Stakeholders describe what they want in their own language: "seamless", "accurate", "safe with our data". Each phrase hides a requirement the architecture must meet, and different readings lead to different designs. Discovery is the work of finding out which.
Listen, translate, write down
- Listen for the goal in the stakeholder's words, and for the expectations they did not say aloud.
- Translate each statement into a requirement, a constraint, or an open question.
- Write it down: requirements with their source, assumptions marked as assumptions, decisions with their reason.
Skipping the third step is how an unstated assumption survives design, build and testing, and surfaces in production or an audit, when changing course is most expensive.
Four questions that structure a discovery session
| Question | Establishes | Example answers |
|---|---|---|
| What must it do? | Functional scope | Draft the summary; check the policy; route the request |
| What must it not do? | Boundaries | Never send without approval; never touch payment data |
| What must it cost? | Budget and capacity | Run cost per month; acceptable cost per case; staff time |
| What must it prove? | Evidence and audit | Who approved each output; that data stayed in region |
The translation table
| Stakeholder says | Implied constraint | Architectural consequence |
|---|---|---|
| "It has to feel instant" | A latency target, and graceful behaviour when slow | Agree a 95th-percentile target; stream responses; define the fallback |
| "Just read the form and send it to the right team" | Routing is a business rule | Claude extracts; a rules engine routes |
| "Someone will check it anyway" | A human approval step exists | Make the approval gate mandatory and designed, not assumed |
| "We are a bank, so be careful" | Regulatory and audit obligations | Identify the specific obligations; plan controls and evidence |
Requirement or assumption?
A requirement traces to something a stakeholder stated or an obligation that was confirmed. An assumption is something the architect believes but nobody has confirmed: a retention period, a volume, that a system has an API, that users will accept a delay. Assumptions are fine; unlabelled assumptions are not. Record each one with who can confirm it and by when, and treat confirming it as work.
Discovery outputs
A good discovery produces a short set of artifacts the design depends on: the translation table, the requirements list with sources, the assumption register, the success criteria (lesson 4.1), and the constraints that rule options out (regulation, approved vendors, budgets, latency).
In the exam
Discovery questions present stakeholder statements and ask what the requirement is, which item is an assumption, or what to ask next. Use the four questions, translate phrases into measurable constraints, separate what Claude does from rules that belong to systems, and flag anything without a source as an assumption to confirm.
Check your understanding
A design document lists "chat transcripts kept for 90 days", but no stakeholder or policy mentioned retention. How should it be treated?
Show answer
Answer: B. Without a source, it is an assumption. Retention can be a legal obligation, so it must be confirmed before it shapes the design.
An operations manager says, "It just needs to read the form and send it to the right team." What is the best translation?
Show answer
Answer: A. "The right team" is a business rule. Claude handles the reading; deterministic rules handle the routing, which keeps it consistent and auditable.
Which TWO questions belong in a structured discovery session?
Show answer
Answer: B, C. Discovery establishes scope, boundaries, cost and evidence. Model and language choices come later, from those requirements.
Apply it: Run St. Aldric's discovery
In a first discovery meeting about discharge summaries, St. Aldric's stakeholders said:
- CMIO: "Doctors should spend much less time on this, and the summaries have to be right."
- CNO: "Patients shouldn't wait around for paperwork."
- Privacy officer: "Obviously, this is PHI."
- A physician representative: "We'll review whatever it writes, but don't make reviewing harder than writing."
- Health IT director: "It has to work with our EHR, and we can't support another fragile integration."
- Build the translation table for these five statements.
- Answer the four discovery questions from the statements and the case facts.
- List at least four assumptions you would need to confirm, with who confirms each.
Done when: nothing in your requirements lacks a source.
Show model answer
1. Translation table
| Statement | Implied constraint | Consequence |
|---|---|---|
| "Much less time... have to be right" | A time target and an accuracy bar | Measure minutes per signed summary; faithfulness and medication accuracy criteria (lesson 4.2) |
| "Patients shouldn't wait" | Summaries ready by a discharge deadline | Drafts ready before the morning ward round; target fewer than 1 in 14 discharges delayed |
| "Obviously, this is PHI" | HIPAA obligations, BAA, US residency, audit | BAA-covered route; control register (lesson 5.4) |
| "We'll review... don't make it harder" | Mandatory physician sign-off, and a review experience faster than writing | Review screen with sources linked; review time measured |
| "Work with our EHR... not fragile" | Integration through supported FHIR APIs, with low support load | Use EHR APIs; fail safe to the manual process |
2. Four questions. Must do: draft summaries from EHR notes with medications and pending results from systems. Must not: send unsigned summaries; suggest medication changes; let PHI leave covered services or the US. Must cost: a run budget not yet stated, plus physician review time below today's 35 minutes. Must prove: who signed each summary and when, what sources were used, and residency.
3. Assumptions to confirm
| Assumption | Confirmed by |
|---|---|
| Physician review must take under 10 minutes to be worth it | Physician representatives |
| The EHR's FHIR API exposes all note types needed, including consults | Health IT director |
| The existing AWS BAA covers the specific Claude features we plan to use | Privacy officer |
| The coding team's 12% return rate is mostly due to missing information a draft can fix | Coding team lead |
| There is a monthly run budget, and its size | CMIO and finance |