Recognising Work That Does Not Belong With Claude (CCAR-P)

Keeping the wrong work out of the model

The three-bucket decomposition assigns work to Claude, existing systems, or humans; this knowledge point is about recognising the pieces that clearly do not belong with Claude. The Claude Certified Architect - Professional (CCAR-P) exam treats this as an understand-level skill because the model's fluency makes it tempting to route everything through it, and some of that work is exactly what a model handles worst. Deterministic calculations, live-state lookups, and anything needing guaranteed repeatability all belong outside the model, in code or behind a tool call, and recognising them early is what stops a team building a probabilistic solution to a deterministic problem.

Three categories recur. A calculation with a single formula-derivable answer belongs in code. Live state owned by another system belongs behind a tool call. Work that must be guaranteed and auditable belongs in deterministic code even if the model could approximate it. Each is a case where the model's probabilistic nature is a liability, not an asset.

Deterministic calculations belong in code

A calculation that has a single answer derivable from a formula, a discount from a tier table, a tax from a rate, an interest figure from a rate and a balance, must produce that answer exactly, every time. Code does this by construction; a model only approximates it and can vary. Routing such a calculation through the model adds cost and latency while removing the very guarantee the task needs. The fact that the business rule happens to be described in natural language somewhere does not change this, the rule is still deterministic, and it belongs in code that implements it, not in a model asked to reason it out.

Live state belongs behind a tool call

Live state, order status, account balance, inventory count, is owned by a system of record and changes independently of anything the model holds. It belongs behind a tool call that fetches the current value at query time, not inside the model's reasoning or an index it retrieves from. Asking the model to reason about live state, or retrieving a cached snapshot of it, produces confident, stale, wrong answers, because the model has no access to the current value unless a tool call hands it over. The correct decomposition puts every live-state piece behind a tool call to the system that owns it.

Guaranteed repeatability belongs in code

The subtlest category is work that a model could plausibly do, and often get right, but that needs a guaranteed, auditable, repeatable result. An eligibility decision, a compliance determination, a financial approval: for these, "right most of the time" is not sufficient, because the occasional wrong answer is unacceptable and the result has to be reproducible for audit. The trap is assuming that because the model produces the right answer most of the time, that is good enough, when the task actually demands the same answer every time with an auditable trail. Such work belongs in deterministic code even though the model could approximate it, precisely because approximation is not the requirement.

There is a second reason this category bites late rather than early: observability. A deterministic check fails in a predictable, loggable way, but the choices a model makes inside a single request are not recorded the way a database query or a rules-engine call is. A rule the business is counting on must therefore be tested with real cases, watched, and owned by a human. Fold that rule into the model and you also lose the test suite and the monitoring that would have caught a break; the classic failure is a threshold rule that quietly misroutes a small fraction of inputs, unnoticed by any alert, until an audit finds it months later. The precision of the rule is not the weak point, the loose, natural-language inputs the model has to read are, and the model follows the letter of the rule while missing its intent.

Recognise it early or pay for it later

The value of spotting these cases is in the timing. Recognising early that a piece is deterministic, live state, or repeatability-critical prevents building an expensive, probabilistic solution to a problem that a small function or a tool call would have solved cheaply and exactly. Discover it late, after the model has been wired into the calculation, and the fix is a rework instead of a decomposition decision. This is why the recognition happens during decomposition, before the pattern is chosen and long before implementation.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is routing a rule-based eligibility calculation through a Claude call because the business logic is described in natural language somewhere. The credited answer recognises the calculation as deterministic regardless of how its rules are written and puts it in code.

The second is assuming that because Claude can produce the right answer most of the time, that is sufficient for a task that actually needs a guaranteed answer every time. The reliable reading identifies the repeatability-and-audit requirement and moves the work into deterministic code, because approximation, however good, does not meet a guarantee requirement.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present a sub-task and ask whether it belongs with Claude. The reliable reading routes deterministic calculations to code, live state behind a tool call, and guaranteed-repeatability work to deterministic code, refusing both the "rules are in prose so use a model" trap and the "right most of the time is good enough" trap.

This recognition sharpens the three-bucket decomposition and draws on identifying the AI-shaped problem and live state vs static knowledge. Discovering such a case late is exactly what triggers iterating the decomposition.