AnthropicClaude Certified Architect – Professional2026-106.1 Conduct structured discovery and requirement gathering
Turn findings into a bounded problem
Completed by the knowledge check
Learning objective
Convert discovery into a problem statement with prioritized acceptance criteria, assumptions, constraints, and open decisions.
Core idea
Discovery is useful when another architect can start design from its output without inheriting hidden decisions. Write a problem statement that names the affected people, observed problem, baseline, desired outcome, and scope. Attach prioritized acceptance criteria and keep assumptions, constraints, and unanswered decisions distinguishable.
NIST AI RMF MAP 1.3 and MAP 1.4 address organizational goals and business value; MAP 3.3 addresses documented application scope. Anthropic’s success-criteria guidance adds specific, measurable, achievable, relevant criteria. The discovery packet in this lesson is a proposed project artifact for applying those principles. It is neither a model selection nor proof that the requirements are already met.
How it works
Write the problem before the solution
State who experiences what difficulty in which workflow, what the observed baseline is, and why changing it matters. Then state the desired business outcome and explicit exclusions. A problem statement such as “deploy a multi-agent assistant” specifies an implementation while leaving the problem unexplained.
Keep observations separate from interpretations. “Staff spend twelve minutes preparing a draft” is a baseline if its measurement is documented. “An agent will save ten minutes” is a hypothesis until tested. Name the measurement population and source so stakeholders can challenge an unrepresentative baseline before it becomes the investment case.
Identify what the first delivery actually completes. Draft assistance, accepted recommendations, and autonomous actions are different scopes even if the interface looks similar. A clear exclusion protects the user journey from implied capabilities: if the system does not submit an application, say which human-owned step still completes the process.
Prioritize by consequence and dependency
Create an ordered acceptance list with an owner and a verification method for each item. A practical project convention is to label items required for the first release, valuable if feasible, or deferred. Record the reason: harm prevention, core user value, dependency, or discretionary convenience. The labels alone do not resolve competing stakeholder demands.
Give scope exclusions the same visibility as included functions. A deferred function that others assume is included becomes a late dispute. If the team cannot meet a required criterion, the authorized owner must change scope, timing, or the criterion explicitly; implementation convenience does not silently lower acceptance.
Prioritize prerequisites before features that depend on them. If policy coverage and authorized access are unresolved, accepting automated decisions on every case is premature. Fund a bounded investigation or reduce scope rather than listing all requirements as equally essential. See 1.6.4 for investment prioritization across use cases; here the decision is what makes this delivery acceptable.
Trace criteria to discovery findings
For the acceptance structure that makes each criterion assessable, see 1.1.2. Here, your responsibility is to preserve why the criterion exists and whether discovery supports testing it.
Trace each criterion to an observed case, stakeholder need, or imposed boundary, and identify the owner who accepts that interpretation. If a walkthrough reveals that staff cannot resolve conflicting policy versions, connect the review requirement to those cases and the policy owner’s decision. A criterion with no traceable need may be a design preference presented as required scope; take it back to its proposed owner before approval.
Carry the measurement boundary and dependency readiness from 6.1.3 into the criterion. Preserve the agreed start and end events, denominator, and observation window instead of copying “fast” or “available.” Google SRE distinguishes the measured indicator from its target. If the required source or authorized test access remains unverified, attach that readiness status and its validation task; do not present the criterion as ready for acceptance testing. An end-to-end delivery target still needs an end-to-end measure when implementation teams divide the work into stages.
A criterion traces to an observed case, stakeholder need, or imposed boundary; one with no traceable need goes back to its proposed owner, and one with unverified access is not ready for acceptance testing.
Separate four kinds of statement
Use an assumptions and decisions register alongside the criteria. These categories require different treatment:
| Statement type | Meaning | Required follow-through |
|---|---|---|
| Acceptance criterion | Condition the delivery must satisfy | Named verification and accepting owner |
| Constraint | Boundary the design must respect | Source, owner, and scope of applicability |
| Assumption | Unproven proposition used for planning | Validation task, owner, deadline, and consequence if false |
| Open decision | Choice an authorized person has not made | Options, deciding information, owner, and needed-by date |
An assumption is not an approved fact, and an unanswered choice is not permission to use the architect’s preference. A failed assumption can reopen scope or invalidate feasibility. Record that consequence while the team still has options rather than discovering it during handoff.
Do not label a desired integration capability a constraint if nobody has verified that it exists. Record it as an assumption or investigation instead. Conversely, an imposed no-write policy is a boundary; successful tests do not authorize ignoring it. The artifact should explain both what is known and what authority can change it.
Review a self-contained packet
Walk the sponsor and accepting owners through the problem, scope, priorities, criteria, and unresolved conditions. Trace each required item to a discovered need or imposed boundary. Record who accepted which version and which decisions remain pending. An approval of the overall goal does not settle every unresolved operational detail.
Release design work conditionally only where the conditions are explicit and owned. For example, designers can compare draft interfaces while a data owner confirms source coverage, but cannot declare automatic eligibility decisions feasible on that basis. Keep the requirements packet available to future design reviews so implementation choices remain defensible against the accepted problem.
Key distinctions and trade-offs
A requirement versus a design decision: A customer must receive a supported answer; selecting a retrieval strategy is one possible implementation. Preserve the requirement when comparing designs.
Prioritization versus wish-list labeling: If everything is required, the document provides no basis for reducing scope. Priorities must identify what is postponed when time or feasibility is insufficient.
A compact statement improves alignment, while detailed criteria make acceptance possible. Keep both: a short problem statement backed by the registers and case annotations that support its claims. Do not compress uncertainty out of the executive version.
Architecture / decision scenario
An education provider wants to “automate eighty percent of admissions work” within one term. Discovery finds that thirty percent of cases permit a complete answer from approved policies, while eighty percent permit a draft for staff review. Anthropic calls the percentage of customer inquiries successfully handled without human intervention the deflection rate. Under that definition, discovery supports thirty-percent deflection feasibility, not eighty-percent deflection; draft assistance measures a different outcome. Four coordinators can review the forecast draft workload; they cannot manually reconstruct missing policy decisions for every case.
The sponsor proposes counting any generated draft as an automated resolution. Choose an explicit first-release problem statement about reducing draft preparation time, with review retained and eligibility decisions excluded. The sponsor owns that scope choice; admissions operations accepts workflow behavior and the policy owner accepts source coverage.
The packet prioritizes supported drafts and complete handoffs as required. A candidate criterion requires ninety-five percent of drafts to satisfy the approved rubric on a held-out sample for each supported program. Another requires every case in the missing-policy test subset to remain unresolved for policy review. Those are proposed project targets requiring validation, not performance guarantees.
Record a constraint against automatic submission, an assumption that program owners can maintain policy coverage before pilot, and an open decision about funding additional review during enrollment peaks. Give each unknown an owner and needed-by date. The eighty-percent-resolution alternative promises a different outcome from what discovery supports; explicit priorities and criteria let the sponsor choose a feasible delivery without disguising the change.
Common exam traps
- Restating a sponsor’s percentage without defining the counted outcome.
- Turning a preferred model or agent pattern into the problem statement.
- Approving a requirement with no observable acceptance method.
- Hiding exclusions, assumptions, or unanswered choices in meeting notes.
- Treating agreement on the business goal as approval of every trade-off.
What to remember
Deliver an observed problem, bounded scope, and prioritized criteria that named owners can assess. Preserve constraints as boundaries, assumptions as testable uncertainties, and open decisions as choices that still require authority. A designer should be able to start from the packet without calling you to recover hidden decisions.
Knowledge check
A sponsor asks to “automate 70% of claims inquiries.” Discovery finds that approved sources support a complete answer without staff involvement for 25% of inquiries and a draft for staff review in 70%, including those complete-answer cases. The sponsor proposes counting every generated draft as automated. What should the problem statement say?
The problem statement for a claims assistant lists “the CRM exposes a write API for case notes.” Nobody has checked with the CRM owner or tested such an interface. How should the packet record this statement?
A proposed required criterion states that answers must be produced by a multi-agent orchestration pattern. No observed case, stakeholder need or imposed boundary traces to it. What should happen before the packet is approved?
Midway through design, the team finds it cannot meet a required criterion — every case in the missing-policy test subset stays unresolved for policy review — by the pilot date. Engineering proposes changing it to “most cases” so that the pilot ships on time. What should happen?