AnthropicClaude Certified Architect – Professional2026-101.6 Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)
Derive service targets from user journeys
Completed by the knowledge check
Learning objective
Translate performance SLAs into latency, availability, throughput, and quality targets derived from user journeys.
Core idea
The user experiences a journey, not an isolated Claude request. A response can arrive quickly while retrieval stalls, a downstream write fails, or a reviewer cannot finish the case. Derive service targets from the event the user needs completed, then allocate engineering budgets to the stages that deliver it.
Google’s SRE terminology distinguishes a service level indicator (SLI), the measured quantity; a service level objective (SLO), its target; and a service level agreement (SLA), an agreement that includes consequences for meeting or missing objectives. A latency aspiration without consequences is an SLO, even if a stakeholder calls it an SLA. These distinctions clarify the exam guide’s performance pillar without changing its objective.
How it works
Name the journey and its completion event
Write a service-target record for each important journey. State the eligible user and input, start event, acceptable terminal outcomes, measurement window, demand profile, and owner. Use the accepted-outcome definition in 1.6.1; do not redefine success as an HTTP response because it is easier to measure.
An interactive question, an approved action, and a document-processing job can require different service indicators. An interactive journey might end when a usable answer appears. An action journey might end only after a downstream system confirms the authorized change. A job might end when its validated output is available for collection. Google’s SRE guidance distinguishes serving-system indicators from pipeline throughput and end-to-end delay, and recommends measuring the user-relevant boundary.
Human handoff can be a valid terminal outcome if the agreement explicitly accepts it. Measure that handoff separately from automated resolution. A successful referral does not prove that the automated answering journey met its quality target, and it does not excuse an unbounded wait for a reviewer.
Derive four targets together
The service-target record needs four related measurements:
| Dimension | Define the measurement | Derive the target from |
|---|---|---|
| Latency | Elapsed time from the user start event to the promised completion event, with a percentile and window | How long the user or dependent process can wait |
| Availability | Fraction of eligible attempts for which the promised service is usable | Required operating hours and acceptable failed journeys |
| Throughput | Accepted outcomes per unit time at the stated load and quality | Peak arrivals, backlog, and completion deadline |
| Quality | Fraction of evaluated outcomes satisfying a task-specific rubric, with population and sample defined | The cost and consequence of an incorrect result |
Choose percentiles because an average can hide a slow tail. Distinguish the latency of successful journeys from the fraction of all eligible journeys that succeed within the deadline. Reporting only successful-response p95 can hide the cases that timed out completely. Keep availability failures in their own denominator rather than deleting them from the service report.
Anthropic’s latency guidance names time to first token (TTFT), measured from sending the prompt to generation of the first response token. Messages requests use stream: true to deliver output incrementally. Streaming can improve perceived responsiveness, but first output is not the accepted result. Record first-visible-output time separately from end-to-end completion when the product benefits from progressive display.
Quality needs more than “a response was returned.” Anthropic’s success-criteria guidance recommends task-specific evaluations reflecting the real task distribution, including edge cases. Define the rubric, evaluator, sampling window, and critical-error categories. An operational SLI can come from live request records while semantic quality comes from a reviewed sample. State that difference; sampled accuracy is not a guarantee about every live answer.
Allocate budgets and test capacity
Break the journey deadline into retrieval, inference, tools, validation, delivery, and any queue or review wait. These allocations are engineering hypotheses to test. Do not assume that adding each component’s p95 establishes the journey p95: components can overlap, depend on each other, or slow down together. Measure the whole path under the workload that matters.
Translate business arrivals into model demand. Claude API Messages limits use requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM), per model class. One business journey can invoke several requests, so journey throughput differs from API RPM. Estimate calls and token demand per journey, then load-test realistic distributions, including longer cases and repeated attempts.
The documented API uses token-bucket rate limiting; short bursts can exceed limits even when a minute-average forecast appears safe. A sharp traffic increase can also encounter acceleration limits. Plan gradual ramp-up and account for queue delay in the journey deadline. If a rate-limit 429 includes retry-after, the documented recovery waits that many seconds. The rate-limits page also documents spend-cap 429s without that header; repeated attempts do not restore access until the cap condition clears.
These are Claude API mechanisms, not a capacity promise for every deployment platform. Read the chosen platform’s limits when it owns your inference path. Even sufficient API allowance leaves retrieval, tool services, validation, and review as possible bottlenecks.
Key distinctions and trade-offs
Agreement versus internal target: The business owner accepts the SLA and its consequences. The service owner operates the SLIs and SLOs that support it. A vendor quota does not replace either artifact.
Responsiveness versus completion: Streaming helps a user observe progress; it does not shorten every downstream stage or certify the streamed content.
Admission versus useful throughput: Accepting more requests can increase queue delay and reduce timely completion. Throughput should remain meaningful only at the required quality and service level.
A stricter latency target can require a shorter response, fewer sequential steps, or more capacity. Each change needs the quality check that justified the workflow. A faster path that fails its task rubric does not satisfy the combined target. Pattern trade-offs belong to 1.3.4; this lesson defines what those patterns must deliver.
Architecture / decision scenario
A healthcare administration team uses Claude to draft appointment instructions from approved scheduling information. Clinical advice remains outside the workflow. The internal agreement requires 95% of eligible journeys to deliver a reviewed instruction within twenty seconds during clinic hours, with a defined escalation when the target is missed. All figures are illustrative requirements.
The architect proposes a separate monthly availability SLO of 99.5% for the instruction service, measured only during clinic hours, throughput of thirty accepted instructions per minute at peak demand, and a quality floor of 99% on a stratified weekly audit against the approved scheduling facts. Critical incorrect dates or preparation instructions trigger an incident response that routes affected instructions to staff and blocks further releases until resolved, rather than disappearing in the aggregate score. The evaluation owner defines that rubric with administration staff.
A preliminary twenty-second budget allocates two seconds to retrieval, eight to inference, three to validation and delivery, and seven to queueing and brief staff approval. Realistic rehearsal shows approval queues taking forty seconds at peak. Inference TTFT is excellent, but the journey misses its agreement. The architect limits admission to available reviewer capacity and revises the staffing or workflow before making the promise.
With two model calls per journey, the peak creates at least sixty model requests per minute before retries, plus the measured ITPM and OTPM demand. The platform owner checks those against configured Claude API limits and ramps traffic gradually. Operations reports completion deadlines, usable-service failures, accepted throughput, and audited correctness together. Streaming draft text is a responsiveness feature, not evidence that the reviewed instruction arrived on time.
Common exam traps
- Calling a target an SLA without specifying consequences.
- Measuring inference latency when the user waits for retrieval, tools, or approval.
- Treating first token as a completed, accepted response.
- Hiding timeouts by reporting latency only for successful requests.
- Equating API RPM with completed business journeys per minute.
- Adding component percentiles as proof of an end-to-end percentile.
- Meeting speed and volume targets while dropping quality or peak-load conditions.
What to remember
Start with the user’s completion event and derive four targets together: latency, availability, throughput, and quality. Define every population and window, allocate stage budgets, and verify the complete journey under realistic load. Keep API limits, internal objectives, and business agreements distinct.
Knowledge check
A product owner calls “p95 answer latency under three seconds” the assistant’s SLA. Nothing happens to anyone when the target is missed. In Google’s SRE terms, what is this target?
A clinic’s agreement requires a reviewed appointment instruction to reach the patient within twenty seconds. The assistant streams its draft with stream: true, and the team reports a time to first token of 0.8 seconds as evidence that the agreement is met. What should the latency SLI measure?
A service report shows a p95 latency of 4 seconds for successful journeys. About 6% of eligible journeys timed out and are absent from the latency data. Which indicator should the report use against a “complete within 5 seconds” target?
A journey makes three Claude API calls, and peak demand is forty journeys per minute before retries. The team compares forty with the organization’s requests-per-minute limit and concludes capacity is ample. What should the platform owner check instead?
An architect allocates a twenty-second journey budget across retrieval, inference, validation, and delivery. The components’ measured p95 values sum to 18 seconds, and the team claims the journey p95 is therefore under twenty seconds. What should the architect require before accepting the claim?
References
- Google, Site Reliability Engineering: Service Level Objectives
- Anthropic, Reducing latency
- Anthropic, Streaming messages
- Anthropic, Rate limits
- Anthropic, Define success criteria and build evaluations