Structured Discovery and Requirement Gathering

What You Need to Know

Discovery is the opening work of an engagement (a piece of work that an architect does for a client). Its purpose is to find the problem behind a request. The request is what a stakeholder asks for. The requirement is the problem underneath the request. A baseline is the measured cost of that problem. The consequence of error is what a wrong output costs.

The Request Is Not the Requirement

This lesson uses one made-up example throughout: an airline. Its customer service director asks for an assistant that drafts replies to passenger compensation claims, "like the one our competitor has". Stakeholders often bring a solution with them: a named artefact, a named tool, sometimes a named competitor. That solution is evidence about the problem. It is never a substitute for the problem.

The architect's first act is to establish what is broken, for whom, at what measured cost, and what would count as fixed. At the airline, the answer might be draft replies with the wrong compensation amount and the hours that the claims team spends to correct them.

Two early moves fail. Building produces a demo on clean sample data, and every later discussion starts from a design that nobody justified. Pricing gives a price for work that nobody has scoped. It turns the architect's uncertainty into a contract that binds somebody else.

What Discovery Has to Produce

Judge discovery by its six outputs, not by how many people were consulted.

• The business problem with a measured baseline: hours, error rates, backlog, revenue at risk. Every later claim of benefit is a difference from the baseline. The baseline cannot be reconstructed once the system has changed the process. At the airline, that means the claims team's hours on corrections, measured before anything changes.
• The real workflow, workarounds included, not the process diagram somebody drew years ago.
• The output the system must produce, which decides the type of task and excludes half the possible architectures.
• The consequence when that output is wrong, and success criteria that have a threshold and an owner.
• The data: what exists, its quality, who owns it, and whether it may lawfully be used here. Domain 5 covers those obligations. If you raise those obligations now, they are cheap to handle. The airline's data is passenger booking records, so the question of lawful basis (the legal ground for using the data) comes first.
• The constraints and the accountable decision-maker: budget, latency, the systems it must connect to and regulatory exposure. They also include the constraints that nobody volunteers, such as the two people who will operate the system. At the airline, they are the claims team leader and one claims handler. A requirement with no named owner cannot be traded off later, because nobody can accept the consequence.

Consequence of Error Sets the Bar

The answer to what happens when the output is wrong sets the price of the rest of the engagement. A wrong suggestion that a human reviews before acting sets one bar. A wrong figure that flows unchecked into a payment or a regulatory filing sets another bar. At the airline, the two cases are a draft reply that a claims handler checks and a wrong payment that goes straight to a passenger.

That answer sets the accuracy threshold worth committing to and decides whether a human checkpoint is a fixed part of the design. It also fixes how much verification the pipeline includes, which determines the latency and cost envelope (the range of response time and cost that the system can achieve). Discovery that captured a feature list and never asked that question produced only a scope.

Success Criteria You Can Pass or Fail

Anthropic's guidance on success criteria is the discovery standard here. It is also the link between this objective and Domain 4. Criteria should be specific, measurable, achievable and relevant. Targets come from benchmarks, prior experiments or expert knowledge rather than optimism. Most use cases need several criteria at the same time, not one main number.

The guidance compares a failing criterion with a passing one, and that comparison shows the form that a discovery record must reach. "The model should classify sentiments well" fails. The passing version names a held-out set (test data that is kept apart during development) of stated size, a minimum level of quality and a safety rate. It separates inconvenient errors from serious errors, and it sets a limit on response time. Criteria that only state a direction of improvement cannot end a project: nobody can show that they are met. The airline's "claim replies should get better" fails the same way.

Feasibility Triage and the Honest No

Three questions decide whether the engagement proceeds in its current form.

1. Is there a task with a clear correct answer and a verifiable output, or an aesthetic judgement with no ground truth (a known correct answer to compare with)?
2. Does the data exist, is it good enough, and may it be used here?
3. Is the cost of being wrong tolerable at an achievable accuracy?

A no to any of these questions is a finding, not a failure. Booking records that the airline may not lawfully use would be one such finding. Anthropic's guidance on agents gives the same direction. It says to find the simplest solution possible, and to add complexity only when it demonstrably improves outcomes.

In the exam

This domain looks like soft skills, so strong engineers skip it and lose nine questions that any experienced practitioner could answer. Every right answer is a professional behaviour under pressure. The exam does make an honest refusal a right answer. The wrong options come from four failure postures (kinds of wrong behaviour) that recur across all five objectives.

• Capitulation agrees to the impossible.
• Evasion complies silently, or builds the system your own way without saying so.
• Obstruction takes the issue above the accountable owner.
• Theatre offers more meetings, more metrics, more documents.

At the airline, an early price is capitulation and a staff survey is theatre.

The postures are this site's framing, not Anthropic's, and they make the domain predictable.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Define success criteria and build evaluations — Anthropic
• Building Effective AI Agents — Anthropic
• Claude Certified Architect Professional Exam Guide (v1.0) — Domain 6 — Anthropic