Translating an SLA into an Architecture Requirement (CCAR-P)

From business words to a testable number

A performance SLA usually arrives in business language, "fast enough for the branch floor," "it should feel instant", and in that form it cannot drive an architecture. The Claude Certified Architect - Professional (CCAR-P) exam treats translating an SLA as an apply-level skill because the architect has to convert that phrasing into a concrete numeric latency target and then into the architecture choices that meet it: model tier, context strategy, and whether extended reasoning is on. Until the SLA is a number, no pattern can be tested against it; once it is, it becomes a first-class pattern-selection factor that can even be the binding constraint.

The translation is the architect's to own, because the business states the requirement in terms it understands and cannot express as milliseconds. Turning "feels fast" into "under 800 milliseconds median" is an architectural act, and it is the prerequisite for every latency-related decision that follows.

The numeric translation comes first

A vague SLA is untestable by construction. "Fast enough for the branch floor" has no failure condition an architecture can be checked against, so any pattern can be claimed to meet it and none can be proven to. The first move is therefore to translate it into a measurable number, a median or percentile latency target, that the architecture can be evaluated against. This is not a formality; it is what makes the SLA operational. With a number in hand, you can measure a candidate configuration's latency and say definitively whether it passes, and the SLA can take its place alongside error cost, observability, and predictability as a factor in pattern selection.

Model tier and context strategy meet the number

Once the target is numeric, it drives concrete choices. Model tier is the largest lever: a lighter model is faster and may meet a tight latency target that a heavier one misses. Context strategy matters too, a monolithic context that accumulates across turns adds latency as it grows, while a progressive strategy that loads only what the next step needs keeps calls lean. These choices are made to hit the translated number, and they are exactly the settings the SLA constrains. An SLA that has been translated tells you which configurations are even in contention before you weigh anything else.

Extended reasoning is not free

The setting the exam scrutinises most is extended reasoning. It adds latency and cost to every call on which it is enabled, so it works against a tight latency SLA, not for it. The disciplined rule is to enable it only when an eval set shows a measured accuracy gap that extended reasoning actually closes, and only when the added latency still fits the SLA. Enabling it "just in case it helps" is the failure: you pay latency and cost on every call with no evidence it moves accuracy, and on a tight SLA the added latency may itself breach the target. The justification has to be a measured gap against a requirement, never an assumption that more reasoning cannot hurt.

One refinement worth carrying into a partner conversation is how the control has changed across model generations. On current Claude models the older manual thinking-token budget has given way to adaptive thinking, where you set a reasoning effort level and the model decides how much to think per request, and on the newest models adaptive thinking is the only mode available. The point that survives every generation is that the model reasons internally regardless; what enabling an expanded pass actually buys is a separate, billed block of thinking tokens plus the latency it adds. That is precisely why the decision hinges on a measured accuracy gap rather than a hunch: you are choosing whether to pay for an extra pass, not whether the model thinks at all. The same reasoning explains a common overrun, extended thinking left switched on for a routing classifier that needs no reasoning quietly taxes latency and cost on every request that passes through it.

The SLA becomes a selection factor

Once translated, the latency target is not a separate concern bolted onto the design, it becomes one of the pattern-selection factors, alongside error cost, observability, and predictability, and it can be the binding constraint. A sufficiently tight SLA can rule out an agent pattern that takes too many steps to meet it, or force a lighter model tier regardless of other preferences. Treating the translated SLA as a full factor is what lets it participate in the tightest-constraint decision rather than being an afterthought that surfaces only when the system feels slow in testing.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is accepting a vague SLA, such as "it should feel fast," without converting it to a measurable latency number the architecture can be tested against. The credited answer performs the numeric translation first, because nothing downstream can be evaluated against an untestable phrase.

The second is enabling extended reasoning or a higher model tier just in case it helps meet an SLA, without an eval set proving it is actually needed. The reliable reading requires a measured accuracy gap to justify extended reasoning, and notes that on a tight latency SLA the added latency can itself breach the target, so "it can't hurt" is both unproven and potentially harmful.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present a business-stated SLA and a proposed configuration and ask what is missing or wrong. The reliable reading translates the SLA into a numeric latency target first, chooses model tier and context strategy to meet it, justifies extended reasoning only by a measured accuracy gap that still fits the SLA, and treats the translated SLA as a pattern-selection factor.

SLA translation builds on cost as a hard design constraint, since latency and cost are the paired budgets, and feeds the tightest-constraint decision rule when the SLA binds. The eval-justified extended-reasoning decision connects to gating value claims with evaluation and to end-to-end trade-off analysis.