AnthropicClaude Certified Architect – Professional2026-106.1 Conduct structured discovery and requirement gathering
Find constraints that can stop delivery
Completed by the knowledge check
Learning objective
Elicit nonfunctional constraints — volume, latency, cost, security, compliance, reliability, integration — and assess data readiness and system access.
Core idea
A function can be clear while the proposed service remains undeliverable. The missing condition may be peak load, an unavailable source, a budget that excludes human review, or a permission nobody can grant. Your discovery artifact is a constraints and readiness register: each limit has a measure, owner, supporting observation, and unresolved feasibility question.
Anthropic’s success-criteria guidance includes latency, price, privacy preservation, and task fidelity, and calls for specific, measurable, achievable, relevant targets. NIST AI RMF MAP 1.5 adds documented risk tolerance; MAP 4.1 addresses component and third-party risks. Use those anchors to discover constraints rather than selecting a deployment and hoping approval follows.
How it works
Define the workload before the target
Ask for ordinary and peak arrival rates, concurrent work, input sizes, traffic segments, and seasonal variation. Identify the unit: requests, cases, documents, or completed journeys. A monthly total cannot establish the burst a downstream system must handle. Obtain measurements from system owners and label forecasts separately.
For each latency target, identify the clock’s start and end, the percentile, and the population. Google SRE distinguishes a service level indicator (SLI), a quantitative measurement, from a service level objective (SLO), its target. “Fast” becomes a candidate SLO only after the indicator is defined. Include queueing, source access, review, and final delivery when the user needs an accepted outcome; a fast model response covers only one stage.
Ask whether the business needs an acknowledgement, a useful draft, or a completed action within that time. An acknowledgement target cannot substitute for a resolution target. See 1.6.3 for deriving service targets; discovery must establish which experience the stakeholder actually needs.
Elicit the operating limits together
Use a register to make interactions visible. The following entries are questions for discovery, not universal thresholds:
| Constraint | Question that exposes a measurable limit | Owner to involve |
|---|---|---|
| Volume | What is the peak arrival rate and how long does it last? | Operations and capacity owner |
| Latency | What must reach which user by which percentile deadline? | Product and service operations |
| Cost | What is the ceiling per accepted outcome and per month? | Finance and sponsor |
| Security | Which identity may read or change each resource? | Security and resource owners |
| Compliance | Which obligations, processing locations, and approvals apply? | Compliance and legal |
| Reliability | What completion rate, fallback, and recovery time are acceptable? | Service operations |
| Integration | Which interfaces, quotas, environments, and change windows exist? | System owners |
Explore conflicts explicitly. More review may reduce harmful decisions while increasing queueing and cost. A restricted processing location may reduce the acceptable deployment choices. Record the constraint without promising that a particular provider configuration satisfies it. The compliance determination belongs to the organization’s compliance and legal owners; a requirements meeting cannot establish vendor eligibility.
For cost, ask whether the ceiling includes failed attempts, supporting services, review, and operations. Compare budgets using the same accepted business outcome. See 1.6.2 for full workflow costing. Discovery records the required ceiling and accounting scope rather than importing a model’s token price as the whole business case.
For reliability, elicit what must happen when a dependency is unavailable and how long pending work can wait. A fallback queue is viable only if a team can receive and drain it. Capture the team’s coverage and capacity alongside the target so an outage plan does not rely on nonexistent staff.
Inspect data readiness independently of model readiness
Inventory authoritative sources, ownership, format, coverage, freshness, sensitivity, and permission to use them. Inspect permitted samples for missing fields, contradictory versions, unreadable content, and absent categories. Ask domain experts whether expected answers can actually be established from those sources.
Label each dependency ready, blocked, or unverified using team-defined meanings. “Ready” should point to an observation, such as a successful approved read of representative records. “Unverified” means nobody has demonstrated access or quality; it is not a weaker synonym for ready. Assign remediation work to the data owner with a date and the acceptance condition.
A representative dataset and authorized production access are separate needs. A clean demonstration export can conceal that production records lack stable identifiers or that the application identity cannot read them. Conversely, a reachable source can contain material the team has no approval to process.
Demonstrate system access before assuming it
Have the system owner confirm the permitted operations and provide an approved test environment. Demonstrate reads and, where needed, writes using the intended class of identity. Record interface versions, access approval status, and any production condition that the test does not cover. Credentials alone do not establish permission for every action.
If access is blocked, preserve the dependency and its consequence for scope. A mock interface can support design work, but it cannot close a production-access question. The decision to proceed conditionally must identify who accepts that uncertainty and what happens if the dependency misses its deadline.
Key distinctions and trade-offs
A target versus a commitment: A candidate SLO describes a desired measured service level. Google SRE defines a service level agreement (SLA) through its associated consequences. Negotiating commitments belongs in 6.3; discovery should not silently create a contractual promise.
Data availability versus data readiness: A file exists; readiness also requires sufficient quality, coverage, authority, and permitted use. A model improvement cannot restore missing source facts or grant access rights.
Early access tests consume scarce system-owner time, but an untested integration can invalidate the whole schedule. Prioritize checks whose failure would change scope before polishing targets for optional features.
Architecture / decision scenario
A healthcare network wants administrative appointment assistance within eight weeks. Its candidate target is a completed scheduling outcome within thirty seconds for 95% of eligible requests, at a peak of forty requests per minute and a budget of $0.50 per accepted outcome. These figures are project constraints, not provider capabilities.
A sponsor proposes approving the design because a model-only demo answers in two seconds. Discovery finds that the scheduling interface permits only ten writes per minute, the service identity lacks approved production access, and manual fallback staff handle eight cases per minute. Several clinic schedules also have no authoritative maintained source.
Choose a constrained draft-assistance scope while the scheduling owner tests authorized access and capacity, data owners repair coverage, and compliance and legal determine permitted processing. The operations owner must specify how unfinished work waits or is declined. The two-second demo cannot satisfy the end-to-end deadline at the required load; queues would grow even with unlimited model throughput. The sponsor owns the scope decision, while the individual owners retain authority over their constraints.
Common exam traps
- Using average monthly volume as a capacity requirement.
- Measuring model latency when the user needs a completed workflow.
- Pricing successful inference while excluding review and failed work.
- Treating a sample export or credential as proof of production readiness.
- Assuming compliance or security approval follows from technical access.
What to remember
Discover operating constraints as measurable, owned conditions. Check representative data and authorized interfaces directly, separate demonstrated readiness from assumptions, and make infeasible target combinations a scope decision before design proceeds.
Knowledge check
A claims assistant must write each result to a policy-administration interface that accepts a limited number of writes per minute. The sponsor provides a forecast of 120,000 requests per month. What should discovery obtain before treating any figure as the capacity requirement?
A policyholder requests an address change, and the business needs the change confirmed in the policy system within sixty seconds for 95% of eligible requests. The prototype’s model responds within three seconds at the 95th percentile. How should the latency indicator be defined?
For an appointment assistant, the data owner supplied a clean export of scheduling records, and the team checked its fields and coverage. Nobody has yet attempted to read production records with the application’s service identity. Which readiness status fits the production scheduling source?
When the scheduling interface is unavailable, the design routes requests to a manual fallback queue. Peak arrivals are forty requests per minute; the fallback team handles eight per minute and works business hours only. What must the constraints register record before this fallback counts as viable?