Exception Review

Exception Review is an operating pattern where humans review only the items that fail automated Quality Gates or get flagged by Triage rules - not the full volume flowing through a pipeline.

The logic is simple. If you've built Quality Gates with clear Exit Criteria, then items that pass all gates don't need a human looking at them. They've already demonstrated they meet your standards. The items that need human judgment are the ones that didn't pass - the exceptions.

This is a direct consequence of the two prerequisites you already know:

1. 1)Quality Gates define what "pass" and "fail" look like, mechanically
2. 2)Triage gives you rules for sorting the failures by priority

Exception Review is what happens when you wire those two things together and remove humans from the happy path.

Exception Review is one of the highest-leverage moves on a P&L because it attacks your biggest Cost Center - Labor - without increasing your defect rate.

Consider the math. If 90% of items in your pipeline are routine and pass all gates cleanly, then reviewing everything means 90% of your review Labor produces zero incremental value. That's not a rounding error - it's the majority of the cost line.

The P&L impact shows up in three places:

• •Labor cost drops. Fewer review hours per unit means lower Cost Per Unit. If your reviewer costs $45/hr and you cut review volume by 90%, you just freed real dollars - either to redeploy or to not hire the next reviewer as volume grows.
• •Throughput increases. When reviewers aren't buried in routine items, the exceptions that actually need judgment get attention faster. This reduces cycle time on the items where Error Cost is highest.
• •Error Cost concentrates where it matters. A reviewer grinding through 400 invoices has attention fatigue by invoice 200. A reviewer looking at 32 flagged invoices brings full judgment to each one. Your defect rate on high-risk items actually improves even though total review volume dropped.

The operator trap is thinking "we review everything, so we're safe." You're not safe - you're slow and expensive, and your reviewers are bored, which makes them worse at catching the real problems.

Exception Review has four mechanical parts:

1. Define the gates that separate routine from exception

Your Quality Gates produce binary outcomes: pass or fail. Items that pass all gates flow through automatically. Items that fail any gate become exceptions.

Example gates for an invoice pipeline:

• •Invoice amount matches PO amount within 2% tolerance
• •Vendor is in your approved vendor list
• •Invoice arrived within 30 days of delivery confirmation
• •No duplicate invoice number in the last 90 days

2. Triage the exceptions

Not all exceptions are equal. A $47 invoice from a known vendor that's 3% over PO is different from a $180,000 invoice from a vendor you've never seen. Use your Triage rules to sort exceptions into priority buckets so the highest Error Cost items get reviewed first.

3. Route exceptions to the right reviewer

Some exceptions need a senior analyst (unusual contract terms, high dollar amounts). Some need a domain specialist (compliance-flagged items, technical specifications). The Triage output determines the routing.

4. Track exception rates and gate effectiveness

This is where the Feedback Loop lives. If your exception rate is too high (say, 40% of items fail a gate), your gates are too tight - you're not actually saving review effort. If it's too low (2%), your gates might be too loose, letting problems through unreviewed.

A healthy exception rate depends on the domain, but 5-15% is a common range. Below that, verify you're not missing real problems. Above that, recalibrate your gates.

Exception Review is the right pattern when three conditions hold:

1. Volume justifies automation. If you process 10 items a month, just review them all - the overhead of building and maintaining gate logic exceeds the Labor savings. Exception Review starts paying off when volume is high enough that reviewing everything creates a Bottleneck or requires dedicated headcount.

2. The routine cases are genuinely routine. If every item is a special case requiring judgment, there's no "exception" to carve out - it's all exceptions. You need a population where most items follow predictable patterns and a minority are genuinely unusual.

3. Your Quality Gates are trustworthy. If your gates have a high false-negative rate (letting bad items through as "passed"), then removing human review from the happy path means those errors reach your customer. You need to validate gate accuracy with periodic Spot-Check auditing before you trust them to auto-approve.

Don't use Exception Review when:

• •Compliance Risk requires human sign-off on every item regardless of gate outcome (some regulated industries mandate this)
• •Your defect rate on "passed" items is still unacceptable - fix the gates first
• •You haven't done the prerequisite work of defining Exit Criteria that a machine can evaluate

Exception Review is what you get when you wire Quality Gates and Triage together and trust the system enough to remove humans from the routine path. Quality Gates give you the mechanical pass/fail decision; Triage gives you the priority ordering for the items that fail. Exception Review is the operating pattern that combines both into a scalable workflow. Downstream, this connects directly to Graduated Autonomy - as your gates prove reliable over time (validated by Spot-Check), you can widen the auto-approve criteria and shrink the exception pool further. It also feeds into Throughput optimization: every item you remove from manual review is capacity freed for higher-value work. The key tension to watch is between Error Cost (what happens when an auto-passed item is actually bad) and Labor cost (what it costs to review everything) - Exception Review is the operator's answer to that tradeoff, and calibrating the exception rate is how you manage it.