What you will be able to do
- Trace a requirement from user voice through technical spec to AI instruction, and find which link broke when the product fails
- Write success criteria that are specific, measurable, achievable and relevant
- Cover several quality dimensions in requirements, including latency, cost and edge cases
- Write pass/fail acceptance tests before any code exists, and check them against real users
1.The Description Chain: from user voice to AI instruction
Discovery findings do no good until someone writes them down precisely enough to build from. Anthropic's builder course calls this path the Description Chain. It runs from what the user says, to a product requirement, to a technical spec, to the instruction the AI acts on. The course is explicit that prompt engineering is only one link. Whoever runs discovery acts as translator at every step, and each step involves judgment calls the earlier step did not make.
The product requirement link takes a scoped user need and makes it measurable. The course says every adjective in it should be a decision you can defend. "Fast" needs a number. "Simple" needs a description of what simple means for a real user in their real situation, such as a patient checking from a phone in a parking lot. The spec then names the pieces of the system and how they talk to each other.
The chain also helps with diagnosis. When code works but the product doesn't, the course calls it a description failure, and the fix is to find which link broke upstream.
Checkpoint 1 of 5· Put it in order
Put the links of the Description Chain in order, starting from the user
- 1.Technical spec
- 2.User voice
- 3.AI instruction
- 4.Requirement
Each link translates the one before it. A failure in the final product traces back to whichever link lost or distorted the user's intent.
“The Description Chain connects user voice to requirement to technical spec to AI instruction.”Source: academy.claude.com
Sources1
2.Success criteria that can actually be measured
For an AI solution, the requirement link becomes success criteria. Anthropic's evaluation guide says a successful LLM application starts with clearly defined success criteria, followed by evaluations that measure performance against them. It lists four properties of good criteria:
| Property | What it requires |
|---|---|
| Specific | State clearly what you want to achieve, e.g. accurate sentiment classification rather than good performance |
| Measurable | Quantitative metrics, or well-defined qualitative scales applied consistently |
| Achievable | Targets based on benchmarks, prior experiments, research or expert knowledge, and within current frontier model capabilities |
| Relevant | Aligned with the application's purpose and user needs |
The guide gives a contrast. "The model should classify sentiments well" is a bad criterion. A good version requires an F1 score of at least 0.85 on a held-out test set of 10,000 diverse Twitter posts, a 5% improvement over the current baseline. That one sentence is specific (F1 on sentiment), measurable (0.85), relevant (data like the real inputs) and achievable (a modest step past the baseline).
Relevance depends on the domain. The guide notes that strong citation accuracy might be critical for medical apps and matter less for casual chatbots. So the same metric can be essential in one engagement and unnecessary in another. Discovery decides which applies.
Checkpoint 2 of 5· Check yourself
A sponsor insists the requirement read "the model must never make a mistake on any input." Which property of good success criteria does this most clearly violate?
A target beyond what current frontier models can do is not achievable. Targets should be based on benchmarks, experiments or expert knowledge.
“Your success metrics should not be unrealistic to current frontier model capabilities.”Source: platform.claude.com
Sources2
3.Requirements span more than one dimension
Usually it isn't. The evaluation guide says most use cases need multidimensional evaluation along several success criteria. In discovery, that means asking about every dimension that matters, including ones the stakeholder didn't bring up:
| Dimension | Discovery question |
|---|---|
| Task performance | How well must it perform, including on rare or challenging inputs? |
| Consistency | If a user asks the same question twice, how similar must the answers be? |
| Relevance and coherence | How directly must it address the user, and how logically organized? |
| Tone and style | How appropriate must its language be for the target audience? |
| Privacy | How must it handle personal or sensitive information? |
| Context use | How well must it use and build on information given in its history? |
| Latency | What response time is acceptable for this application? |
| Price | What is the budget for running the model, given cost per call, model size and usage frequency? |
The guide's multidimensional version of the sentiment criterion shows the result. On the same 10,000-post test set, it requires an F1 score of at least 0.85, 99.5% of outputs non-toxic, 90% of errors causing inconvenience rather than egregious error, and 95% of responses under 200ms. The guide adds that in practice you would also define what "inconvenience" and "egregious" mean. A term left undefined in a requirement is still an open question.
Requirements should also reflect the real-world task distribution, including edge cases: irrelevant or nonexistent input, overly long input, poor or harmful user input, and ambiguous cases where even humans would disagree.
Checkpoint 3 of 5· Check yourself
A requirements document for a customer-facing assistant specifies only an accuracy target. Which gap is most important to raise?
One metric leaves out dimensions such as response time, budget, safety and edge-case behaviour, and most applications need them.
“Most use cases need multidimensional evaluation along several success criteria.”Source: platform.claude.com
Sources2
4.Acceptance tests: defining done before code exists
The last output of discovery is a set of acceptance tests, written before any code. The builder course calls them a shared definition of done for both the team and the AI, and it calls tests the most precise form of description.
The course asks for five to seven statements. Each one must be concrete enough that a stranger could say whether the finished product passes or fails. Compare:
- Good: "A patient with a basic smartphone can find the current wait time in under 30 seconds without creating an account." - Bad: "The system is easy to use."
The good version names a user, a device constraint, a time threshold and a friction limit, all of which came out of discovery. When the course revisits the tests, it asks for each to be rewritten as something code could pass or fail, and for at least two edge cases to be added: the clinic is closed, there is no data, the wait time is zero.
Then comes the check that closes the loop. Give the build to someone playing the real user, with no explanation and no help, and watch. If the tests pass but the user is still unhappy, the code is not the problem. The tests captured the wrong intent, and you go back up the Description Chain to find the link that broke.
Checkpoint 4 of 5· Check yourself
Every acceptance test passes, but patients in a usability session are frustrated and give up. What does this most likely indicate?
Passing tests show the build matches its description. An unhappy user shows the description itself, which came from discovery, was wrong.
“A passing test with an unhappy user means you described the wrong intent.”Source: academy.claude.com
Checkpoint 5 of 5· Exam question
A solutions architect is running the first discovery session with a new prospect before recommending any specific Claude model. According to Anthropic's model-selection guidance, which factors should the architect establish as key criteria during this session?(Select 3)
Correct answers: A, B, C — The specific capabilities the model must have to meet the prospect's needs; How quickly the model must respond within the prospect's application; The prospect's available budget for development and production usage
- A. Correct. Capabilities is one of the key criteria Anthropic's guidance lists to establish before choosing a model.
- B. Correct. Speed, meaning how quickly the model must respond, is explicitly named as a key criterion to evaluate first.
- C. Correct. Cost, meaning the budget for development and production usage, is explicitly named as a key criterion to evaluate first.
- D. Incorrect. Headcount in the IT department is not one of the documented model-selection criteria and does not inform capability, speed, or cost decisions.
- E. Incorrect. Marketing channel usage is unrelated to model capability, speed, or cost requirements and is not a discovery criterion for model selection.
- F. Incorrect. A third-party ticketing software version is an integration detail, not one of the capability, speed, or cost criteria used to scope model selection.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1."The system is easy to use" is an acceptable requirement as long as stakeholders agree with it.Why is that wrong?
An acceptance criterion must be concrete enough for an outsider to judge pass or fail. That means naming the user, the conditions and a threshold.
Covered in Acceptance tests: defining done before code exists
2.A single well-defined accuracy metric fully specifies an LLM application.Why is that wrong?
Most applications also need criteria for things like latency, cost, safety, consistency and edge-case handling.
Covered in Requirements span more than one dimension
3.If all acceptance tests pass, the requirements were gathered correctly.Why is that wrong?
Passing tests only show the build matches its description. If real users are unhappy, the discovery step described the wrong intent.
Covered in Acceptance tests: defining done before code exists
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://academy.claude.com/courses/ai-fluency-for-builders/description-building-great-thingsOfficial docs
“The builder is the translator at every step.”
↩︎ The Description Chain: from user voice to AI instruction“Every adjective should be a decision you can defend.”
↩︎ The Description Chain: from user voice to AI instruction“Find which link broke upstream.”
↩︎ The Description Chain: from user voice to AI instruction“Tests are the most precise form of description.”
↩︎ Acceptance tests: defining done before code exists“Add at least two edge cases”
↩︎ Acceptance tests: defining done before code exists“A passing test with an unhappy user means you described the wrong intent.”
↩︎ Exam trap 3“The Description Chain connects user voice to requirement to technical spec to AI instruction.”
↩︎ Checkpoint“A passing test with an unhappy user means you described the wrong intent.”
↩︎ Checkpoint - 2.
“Specific: Clearly define what you want to achieve.”
↩︎ Success criteria that can actually be measured“Strong citation accuracy might be critical for medical apps but less so for casual chatbots.”
↩︎ Success criteria that can actually be measured“What is the acceptable response time for the model?”
↩︎ Requirements span more than one dimension“What is your budget for running the model?”
↩︎ Requirements span more than one dimension“Design evals that mirror your real-world task distribution.”
↩︎ Requirements span more than one dimension“Most use cases need multidimensional evaluation along several success criteria.”
↩︎ Exam trap 2“Your success metrics should not be unrealistic to current frontier model capabilities.”
↩︎ Checkpoint“Most use cases need multidimensional evaluation along several success criteria.”
↩︎ Checkpoint - 3.https://academy.claude.com/courses/ai-fluency-for-builders/delegation-the-builder-s-toolkitOfficial docs
“Write acceptance tests before code. They give you and AI a shared definition of done.”
↩︎ Acceptance tests: defining done before code exists“Each must be concrete enough that a stranger could tell you whether the finished product passes or fails.”
↩︎ Exam trap 1