AnthropicClaude Certified Architect – Professional2026-105.3 Apply human-in-the-loop validation strategies
Give each reviewer an actionable decision
Completed by the knowledge check
Learning objective
Design review queues, escalation paths, and evidence packages that let reviewers decide without rereading full transcripts.
Core idea
A structured handoff preserves the findings and unresolved questions. A production review service must also ensure that an authorized person receives that handoff, can claim responsibility, and can decide before the business deadline. This lesson adds the queue lifecycle and escalation ownership around the record.
Design the queue around a decision, rather than around a conversation. “Review this run” leaves scope and authority undefined. “Decide whether this appointment correction can be released, using these two conflicting records” identifies both the work and the evidence. A concise package should make the decisive material accessible while preserving access to the underlying sources when the reviewer needs them.
NIST AI RMF GOVERN 3.2 defines the need for differentiated oversight responsibilities, and MANAGE 4.1 includes post-deployment monitoring, appeal, override, recovery, and change management. A review-service specification and responsibility matrix turn those outcomes into an operating process.
How it works
Define a lifecycle that survives reassignment
Use explicit application statuses such as pending, claimed, needs_information, escalated, resolved, and expired. These names illustrate a queue design; they are not Anthropic enums. Each transition records who caused it and which proposal revision it concerns.
A pending item needs a destination role, due time, risk tier, review reason, and source revision. Claiming assigns an accountable reviewer, but does not grant authority beyond that person’s role. If the reviewer cannot settle the issue, needs_information preserves the missing fact and the owner expected to supply it. Escalation changes the decision owner; it does not silently mark the proposal approved.
Define how abandoned claims return to the queue and how duplicate submissions refer to one decision. An expired claim and an expired proposal have different consequences: another reviewer can take the former, while the latter might require refreshed evidence before anyone decides. The queue implementation owns these distinctions independently of the model’s account of progress.
For an approval-before-action workflow, only a resolved approval on the matching revision can release execution. Other resolutions include rejection, correction, and unresolved closure. Preserve the difference between “the person answered” and “the application performed the approved operation.” See 5.3.1 for the execution checkpoint.
Build the package around the disputed claim
The handoff already identifies the case and supported findings. Add the information needed to navigate and audit a production queue:
| Package element | Decision it enables |
|---|---|
| Requested decision and authority level | Determine whether this reviewer can decide |
| Exact proposal revision and change from a prior decision | Inspect the operation that approval would release |
| Trigger, deadline, and blocking dependencies | Understand why this case arrived and what waits on it |
| Supporting and conflicting source passages | Verify the material claim without searching the transcript |
| Trusted execution state and outstanding unknowns | Distinguish completed work from recommendations |
| Permitted outcomes and escalation destination | Resolve, request information, reject, or transfer responsibility; require a rationale for edits or rejection |
Show both support and contradiction. A summary that selects only evidence favorable to the recommendation makes a fast decision possible by hiding the reason review exists. Keep machine-generated conclusions visually and structurally separate from source records and independently computed checks.
For a cited free-form response on the Claude API, enable citations.enabled: true on supplied document blocks. Citation objects carry cited_text and source locations; PDF citations use one-indexed page ranges. These pointers help the reviewer reach the supplied text. They do not establish that the selected passage supports the recommendation or that the document is authoritative.
Citations and output_config.format cannot share a request; see 2.2.4 for the cited-prose versus structured-output choice.
Scanned PDFs without extractable text are not citable. Mark claims from those scans as lacking native citation support, retain their source records for direct inspection, and route any claim requiring source verification accordingly. Do not present an uncitable claim as verified merely because the summary names a PDF.
Escalate by missing authority, evidence, or time
Define separate escalation reasons. A reviewer may lack authority for the proposed effect, need a domain expert to interpret conflicting records, or be unable to meet the deadline. Make the destination and package reflect that reason: a senior approver cannot repair an unavailable source merely by having greater authority.
For each route, name a primary role, backup role, acknowledgment interval, and final owner. Configure these as application routing rules with the organization; they are not a special Claude queue API. A transfer remains pending until the destination accepts responsibility. Preserve the original submission time so reassignment cannot reset an approaching deadline.
Abandoned claims and escalations send an item back to be claimed before it is resolved.
Measure submission-to-resolution time alongside active review time. Google SRE’s service-level-objective guidance distinguishes user-relevant latency from narrower server measurements and recommends looking at distributions. Apply that principle to the whole review service, including time waiting for clarification. A fast review screen cannot compensate for an unowned overnight queue.
Key distinctions and trade-offs
Concise packages reduce repeated investigation but cost effort to construct and validate. Keep full transcripts available for exceptional investigation, but do not make them the only way to locate the deciding fact. Keep the package short by selecting relevant material, not by deleting contradictions or uncertainty.
Priority determines which eligible reviewer works next. Authority determines who may decide. Deadline escalation changes ownership or communicates delay; it cannot convert pending approval into permission. See 5.3.4 for balancing these demands against staffing.
Architecture / decision scenario
A healthcare appointment service handles 600 correction requests per day. Its own operating policy reserves conflicting patient-identity records for an identity specialist. An eight-hour resolution target includes queueing, and only two specialists work each shift. These are scenario constraints, not claims about a regulation.
The proposed shortcut is to send every transcript to the general support queue and let any available reviewer click approve. The service owner rejects it because general reviewers lack the required authority and transcript searches consume the resolution window.
The architect sends identity conflicts to a specialist queue with the proposed correction, both relevant source passages, record versions, unresolved identity question, and a blocked execution status. A specialist claims the item or requests information from the registration team. After four hours without acknowledgment, the backup specialist receives a deadline escalation; the original clock continues.
The identity service validates the resolved revision before making the correction. The clinical operations owner owns the authority matrix, while the service team owns queue delivery and timing. Neither a general reviewer nor an expired timer can approve by default.
Common exam traps
- Treating queue receipt as an authorized decision.
- Sending a full transcript without identifying the disputed claim.
- Showing supporting passages while omitting conflicting records.
- Resetting turnaround time whenever a case changes queues.
- Escalating to a senior approver when the actual gap is missing evidence.
What to remember
Give every review item a decision scope, qualified owner, durable state, deadline, and escalation route. Present the proposal, its source material, and unresolved questions together. Measure the complete service interval and keep execution separate from submission and human response.
Knowledge check
A claims adjuster has claimed a review item and holds authority for its amount, but cannot decide because two repair estimates list different part numbers. Only the body shop that issued the second estimate can confirm which part was fitted. The resolution deadline is two days away. What should happen to the item?
needs_information , naming the part number and its ownerpending so another adjuster can pick it upneeds_information keeps the item open while preserving the missing fact and the party expected to supply it. A senior approver cannot repair an unconfirmed source by holding greater authority, approving now resolves the claim on a guess, and releasing the claim hands the same unanswerable question to another adjuster.An appointment-correction service promises resolution within eight hours of submission. Items often move from the general queue to the identity-specialist queue, and the dashboard restarts its timer whenever an item changes queue. Leadership asks for the measurement that matches the promise. Which should the team report?
A lending review package uses Claude API citations on supplied documents to point reviewers to the passages behind each claim. One claim material to the decision comes from a scanned PDF that has no extractable text. How should the package present that claim?
source_page field through output_config.formatoutput_config.format , while a model-filled page field would not be a citation anyway.