- In short
- A routed decision must reach the reviewer with three things: the inputs that drove it, the model's output, and the specific reason it was flagged. Without the flag reason a reviewer cannot distinguish an edge case from routine traffic; without the inputs they cannot verify whether the output is correct. Showing the output alone forces rubber-stamp approval, and the same decision log built for fairness and transparency supplies this reviewer view.
Routing a decision is only half the job
The routing rule gets the right decisions to a person; this knowledge point makes sure the person can actually judge them. The CCAR-P exam treats it as an apply-level skill because a review is only as good as what sits in front of the reviewer, and a reviewer who cannot see why a decision reached them will approve without the judgement the routing was meant to trigger. Getting the routing right and the reviewer view wrong wastes the whole exercise.
The requirement is precise and short. A routed decision must arrive with three things: the inputs that drove it, the model's output, and the specific reason it was flagged. Each of the three answers a different question the reviewer has to answer, and missing any one of them makes accurate review impossible. What you put in front of the reviewer determines whether the review is accurate.
- What the reviewer's screen must show
- The three elements a routed decision must carry to its reviewer: the inputs that drove it, the model's output, and the specific reason it was flagged. The flag reason lets the reviewer tell an edge case from routine traffic; the inputs let them verify correctness; the output is the decision itself. Showing the output alone forces rubber-stamp approval.
The three elements and what each unlocks
The output is the decision itself - the recommendation, the action, the answer the reviewer is being asked to approve or override. On its own it is nearly useless for review, because there is nothing to judge it against.
The inputs that drove the decision are what let a reviewer verify whether the output is actually correct. Without them, the reviewer sees a conclusion with no premises and cannot tell a right answer from a wrong one - they can only defer to the model, which defeats the purpose of routing to a human.
The flag reason is what let the item reach this queue, and without it the reviewer cannot distinguish an edge case that warrants scrutiny from routine traffic that happened to be sampled. The reason tells them what specifically they are being asked to weigh - is this a low-confidence case, a high-cost action, a policy-boundary situation? - so they can focus their judgement rather than guess at why they are looking at it.
Why the output alone forces rubber-stamping
The failure mode this knowledge point guards against is the approve-button interface: a screen that shows the model's output and nothing else. A reviewer handed only an output has nothing to check it against and no idea why it was flagged, so the only thing they can do at any speed is approve. The interface does not enable review; it manufactures the appearance of it. Every decision gets the same reflexive sign-off, and a high-stakes item receives no more scrutiny than a trivial one.
The good news is that the raw material already exists. The same decision log built for fairness and transparency - the record of inputs, retrieved context, output, and routing path - is exactly what supplies the reviewer view. You are not instrumenting the system again; you are choosing which fields of the existing decision log to surface and when. The reviewer screen is a query against instrumentation you already have.
What the CCAR-P exam trips candidates on
The first trap is building a reviewer interface that shows only the model's output with an approve button, forcing rubber-stamp decisions. The scenario presents a clean, simple review UI and asks whether it supports good review; the credited reading is that without the inputs and the flag reason, the reviewer cannot judge anything, so the interface guarantees rubber-stamping rather than review.
The second trap is assuming a reviewer can infer why a case was flagged from the output alone. A scenario omits the flag reason and expects the reviewer to reconstruct it; the credited reading is that the reason must be stated, because a reviewer cannot reliably tell an edge case from routine traffic by looking at the output. The exam rewards surfacing all three elements explicitly rather than hoping the reviewer deduces the missing ones.
Worked example
A team's review queue shows each flagged decision as the model's recommendation plus an Approve and a Reject button. Reviewers approve almost everything quickly, and a later audit finds several wrong decisions were approved. Diagnose the interface and specify what it must show.
The interface manufactures rubber-stamping by design. A reviewer sees only the output - the recommendation - with no inputs to check it against and no flag reason to explain why it is in the queue. With nothing to judge the recommendation against, the fastest defensible action is to approve, so reviewers approve almost everything, and wrong decisions sail through with the rest. The audit finding is the predictable consequence, not a reviewer failing; the screen never gave them the means to review.
The fix is to surface all three required elements. Show the inputs that drove the decision, so the reviewer can verify whether the recommendation is actually correct against the facts of the case. Show the model's output, which is the thing being judged. And show the specific reason the item was flagged - low confidence, high cost, a policy boundary - so the reviewer can tell an edge case that needs scrutiny from routine traffic. With those three in view, an approve or reject becomes a judgement rather than a reflex.
None of this requires new instrumentation. The decision log built for transparency already captures inputs, output, and routing, so the reviewer screen is a matter of surfacing the right fields from it. The exam point is that accurate review is a property of what the reviewer sees, and the output alone is never enough.
Common misreadings to avoid
Misconception
A review interface that shows the model's output with approve and reject buttons is sufficient.
What's actually true
Misconception
A reviewer can work out why a case was flagged just by looking at the output.
What's actually true
How this shows up on the exam
Domain 5 items describe a review queue or interface and ask why review quality is poor or what the screen must show. The reliable method is to check for all three elements - inputs, output, and flag reason - and to identify an output-only interface as one that forces rubber-stamping. Any answer that adds reviewers or tweaks the buttons without fixing what the reviewer sees is treating the wrong problem.
This knowledge point completes the routing chain begun by the stakes-based routing rule and constrained by review placement trade-offs. Its reviewer view is drawn straight from decision logging for explainability, and a missing reviewer view is one of the two independent failures behind consent fatigue and over-routing.
A review queue shows each flagged decision as only the model's recommendation with Approve and Reject buttons. Reviewers approve nearly everything, and an audit finds wrong decisions were approved. What must change?
People also ask
What does a human reviewer need to see to judge a decision?
Why does a reviewer need the flag reason?
What happens if a reviewer only sees the output?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.