Consent Fatigue: When Too Much Human Review Stops Being Real Review

The stakes-and-reversibility framework tells an architect where to place a human approval gate. It says nothing, by itself, about a failure mode that shows up specifically when that framework is applied *too liberally* -- when "when in doubt, route it to a human" becomes the default answer for every borderline case, not just the genuinely high-stakes ones. The named failure mode for this over-application is consent fatigue, and it is one of the more counter-intuitive risks in this domain, because it looks, on the surface, like an excess of caution rather than a shortfall of it.

What Consent Fatigue Is

Consent fatigue is what happens when routing too many decisions to human review erodes the quality of that review over time. A Human-in-the-Loop control only provides the safety benefit it's designed for if the human on the other end of it is actually evaluating each item -- reading it, weighing it, deciding. If the volume of items routed to that reviewer climbs high enough, and the context given for each item stays thin enough, the reviewer's actual behavior shifts from evaluation to rubber-stamping: clicking approve because the queue is long, because the last fifty items were all fine, and because there's no real signal in front of them explaining *why* this particular item was flagged in the first place. At that point, the Human-in-the-Loop control still exists on the architecture diagram, but it has stopped doing the job it was designed to do.

Why This Is the Predictable Consequence of Over-Applying HITL, Not a Separate Problem

This connects directly back to the stakes-and-reversibility framework, not as a separate concern but as its natural failure mode when misapplied. The framework says: route genuinely high-stakes, low-confidence, or out-of-policy items to a human, and let lower-stakes, reversible, high-volume actions rely on detective sampling instead. Consent fatigue is what happens when an architect (or an over-cautious default configuration) skips that discrimination step and routes *everything* to human review regardless of stakes -- every borderline case, every slightly-unusual request, every action the system isn't 100% confident about, no matter how low the actual stakes or how reversible the actual action. The review queue balloons, and a reviewer facing a high-volume queue of low-context items behaves exactly as any human would under those conditions: they start approving quickly rather than evaluating carefully.

The Reviewer's Actual Experience

Picture the reviewer's screen: a queue of items, each with an approve/reject button, and little else. No visibility into *why* this particular item was flagged -- was it a low-confidence score? An unusual pattern? A specific policy trigger? Just the item itself and a binary choice. Faced with that screen fifty times in an hour, a reviewer cannot meaningfully evaluate each one; they can only skim and click. This is not a character flaw in the reviewer -- it's what any reasonable human does when handed an unbounded stream of low-context, low-explanation decisions to make quickly. The design failure is upstream of the reviewer, in how the queue was built.

The Fix: Route Selectively, Explain the Flag, Audit the Rate

The fix is not to abandon Human-in-the-Loop review -- it's to apply the same stakes/reversibility/confidence criteria already established for HITL placement, and to design the review experience itself so a genuine evaluation is actually possible:

1. Route selectively, per the stakes/reversibility/confidence criteria already in the framework -- not everything borderline, only what the framework actually calls for (high-stakes, irreversible, low-confidence, or out-of-policy). Lower-stakes volume goes to detective sampling instead, exactly as the stakes-and-reversibility framework already prescribes.
2. Give reviewers the flagging REASON and relevant context, not just raw input/output. A reviewer who sees "flagged: confidence 0.42, below the 0.7 threshold for this action type" or "flagged: requested refund exceeds the $500 auto-approval limit" can actually evaluate the specific concern. A reviewer who sees only the raw request and a button cannot.
3. Periodically audit review-queue approval rates. A queue that has silently drifted to 99%+ approval is a strong, measurable signal that the queue has grown consent-fatigued and the review step is no longer adding real signal -- it has become theater. This audit doesn't require guessing at reviewer state of mind; it's a number an architect can pull from the system's own logs, and a near-universal approval rate on a queue that was supposed to be catching real problems is itself the diagnostic.

Worked Example

Suppose an architect, having correctly learned that high-stakes actions need human approval, over-applies the lesson: every tool call below a 90% confidence score gets routed to a human reviewer, regardless of what the tool does. Within a few weeks, the reviewer is approving 400 items a day, most of which are low-stakes, easily-reversible actions (rephrasing a canned reply, re-ordering a list) that happened to score below the arbitrary confidence cutoff for unrelated reasons. The reviewer, overwhelmed, starts approving almost everything without reading it closely -- and a genuinely risky item that also happens to score below 90% now sails through the same rubber-stamped queue as everything else. The fix isn't to remove the human reviewer; it's to route only the genuinely high-stakes, low-confidence, or policy-relevant subset to that reviewer, with the specific reason for each flag attached, and to let the low-stakes majority go through detective sampling instead.

Common exam traps

• Treating "more human review is always safer" as an unconditional truth. Past a point, more review with less context per item makes the control *less* effective, not more, because it degrades into rubber-stamping.
• Fixing an apparent HITL failure by adding volume (routing even more items to the same undifferentiated queue) rather than fixing the routing criteria and the context given to reviewers.
• Overlooking approval-rate auditing as a diagnostic. A near-100% approval rate on a review queue is not evidence the system is well-behaved -- it's often evidence the review step has stopped functioning as a real check.