Skip to lesson

AnthropicClaude Certified Architect – Professional2026-105.3 Apply human-in-the-loop validation strategies

Let policy outrank calibrated confidence

Completed by the knowledge check

Learning objective

Route review with calibrated confidence, policy triggers, and risk tiers rather than raw self-reported confidence.

Core idea

Calibrating a score establishes how it relates to correctness on a defined population; it does not establish authority to act. This lesson adds the policy precedence and risk-tier ownership needed when that signal controls a production review service.

A routing decision combines different kinds of evidence. A policy trigger can require approval even for an almost certainly correct recommendation. A calibrated signal can identify uncertain work within a permitted tier. A risk tier determines what exposure the organization accepts and who may authorize exceptions. Collapsing these into one score makes the routing rule difficult to defend and easy to weaken accidentally.

NIST AI RMF MAP 5.1 calls for documenting the likelihood and magnitude of impacts. MAP 3.5 addresses documented human oversight. Use a versioned routing-policy table to connect those outcomes: each row names the effect, tier, mandatory triggers, validated score population, review destination, and owner.

How it works

Assign risk independently of model certainty

Define tiers around the business effect and context. An illustrative technology company might classify private troubleshooting drafts as low impact, customer-visible changes as moderate impact, and production deletion as high impact. The names and thresholds belong to the company; neither the Claude API nor the Agent SDK assigns these business tiers automatically.

For each tier, state the accepted exposure and required intervention. Consider tenant scope, downstream dependencies, recoverability, and the cost of an undetected error. A confident answer about the wrong tenant remains outside authorization. A correct deletion command remains consequential even when its syntax is certain.

Assign a risk owner who can approve the tier definition and an operational owner who implements routing. Document what moves a case upward: an external effect, a protected resource, insufficient evidence, or a policy exception. Moving downward requires validated evidence and owner approval, not a generated claim that the task is routine.

Define precedence before tuning thresholds

Apply mandatory restrictions before confidence-based acceptance. The following rule illustrates application control flow, not an Anthropic request format:

if action is prohibited: block; route any appeal separately
else if policy requires approval: hold for the authorized role
else if evidence conflicts or required facts are missing: require review
else if configuration or population lacks validation: require review
else if validated signal misses this tier's threshold: require review
else: execute only within the tier's permitted scope; retain audit eligibility

A prohibited action and a reviewable exception are different outcomes. Do not imply that a sufficiently senior queue can approve something the service is forbidden to do. An unresolved policy question goes to the policy owner; execution remains blocked while that owner settles it.

Retain every applicable reason. If a proposed change affects a protected resource and also fails a confidence threshold, the reviewer needs both facts. Otherwise, fixing one uncertainty can accidentally remove the unrelated authority requirement.

Use confidence only where its meaning was validated

Keep the score source, evaluation population, configuration version, empirical correctness, and accepted coverage with the routing-policy row. The calibration method itself is assumed here. The Professional decision is whether that validation applies to this action and tier.

For example, a signal validated on read-only troubleshooting cannot authorize production writes. Even within one task, a policy change may make formerly correct recommendations unacceptable. Revalidate the routing outcome against the applicable policy, rather than checking only whether the model’s average score stayed stable.

A raw self-reported confidence value is application content. If retained as an input to calibration, label it as such and validate its usefulness empirically. It must not remove a mandatory trigger. Missing, malformed, or out-of-population signals take the review path defined by the policy; do not silently replace them with a passing default.

Anthropic’s evaluation guidance calls for task-specific evaluations that reflect the real task distribution and include edge cases. Apply that guidance to the entire router: test high-confidence prohibited actions, low-confidence harmless drafts, missing validation metadata, and cases with several simultaneous reasons. The desired outcome includes the destination and whether execution occurred, not merely the final text.

Enforce the route at the effect boundary

For a Claude Agent SDK implementation, use a PreToolUse hook to evaluate trusted resource and policy state before a protected tool executes. Return hookSpecificOutput.permissionDecision: "deny" with hookEventName: "PreToolUse" and a meaningful permissionDecisionReason when the action lacks required approval. The permission documentation places hooks before the other permission stages; a callback alone can be skipped by earlier automatic approvals.

The hook enforces an application decision; the model does not supply its own authoritative tier. For a durable human queue, the tool can submit a proposal while the business service withholds the actual effect. See 5.3.1 for approval timing and 5.3.2 for the receiving workflow.

Record the routing-policy version and evaluated facts alongside the decision. That lets an incident reviewer distinguish a missed trigger, an invalid calibration assumption, and an incorrect tier assignment. Each calls for a different repair.

Key distinctions and trade-offs

A threshold controls uncertainty within an eligible path. A policy trigger controls whether that path is permitted. A risk tier controls the consequences the organization is willing to expose. Raising a confidence cutoff cannot repair a missing prohibition or an inappropriate tier.

More mandatory triggers reduce exposure but increase review demand. That cost belongs in the capacity plan, rather than being hidden by relaxing rules during a backlog. If a trigger routinely produces unnecessary review, examine adjudicated outcomes and change the owned policy through evaluation; queue pressure alone is not validation.

Architecture / decision scenario

A technology company automates 2,000 tenant-support changes daily. Its service target is ten minutes for routine repairs. Company policy requires security approval for changes to privileged identities and forbids cross-tenant writes. A proposed router accepts any change whose model-reported score exceeds 0.98, a cutoff chosen without labeled validation.

For the routine-repair tier, calibration on labeled cases selects a 0.995 threshold on that same score; held-out evaluation confirms the company’s quality target at 70% coverage. These are illustrative scenario results. The architect rejects the original design because its raw 0.98 cutoff lacks validation and its single-score rule omits policy precedence: a privileged identity change scored 0.99 requires approval, and a cross-tenant change is prohibited regardless of confidence. An unfamiliar repair type scored 0.995 lacks applicable validation and goes to specialist review.

The platform owner defines tier-specific eligibility, the security owner owns privileged-identity policy, and a PreToolUse hook checks the actual tenant and approval state. Routine eligible repairs use the validated threshold; exceptions carry all routing reasons into the queue. Tests verify both the selected destination and absence of a write when blocked. The ten-minute target motivates better routing and staffing, not permission to ignore a policy trigger.

Common exam traps

  • Averaging policy risk and model confidence into one acceptance score.
  • Using a validated read-only score to authorize consequential writes.
  • Letting a higher score remove an unrelated mandatory review reason.
  • Treating every prohibited action as an approvable exception.
  • Tuning thresholds without testing the router’s actual tool execution.

What to remember

Establish policy precedence, assign risk from the effect, and apply calibrated confidence only to validated, eligible cases. Keep all review reasons and the policy version. Enforce the resulting decision where the action executes, using trusted state rather than model-assigned authority.

Knowledge check

References