Most AI demos begin with a document that is easy to read, a request that is easy to classify, and a result that fits neatly into the next step.
Real work rarely stays that cooperative.
A purchase order arrives without a vendor identifier. The address belongs to a subsidiary, but the contract sits under the parent company. One page uses cases and another uses individual units. The total looks valid until a handwritten note changes the delivery date. None of these details is unusual to the people doing the work. They are simply the cases that never make it into the demo.
Teams often call them edge cases. The term makes them sound peripheral, as if the main product exists in the clean center and everything messy can be handled later. In operational software, the opposite is often true. The standard cases move through quickly. Exceptions are where people spend their time, apply judgment, and decide whether to trust the system again.
An extraction model can perform well and still leave a poor product behind. Suppose it processes 95 ordinary invoices without trouble, then encounters five with missing references or conflicting amounts. If those five disappear into a generic error queue, someone has to reconstruct what happened from scratch. The automation saved time on the easy work and returned the difficult work stripped of context.
That is not a minor interface problem. It is the product revealing what it thinks the job is.
A useful exception path preserves the original material, the model's interpretation, the reason it stopped, and the decision required from the person reviewing it. It should make the disagreement visible rather than bury it in a confidence score. After the person resolves the issue, the process should continue from that point. Asking them to restart the whole case turns escalation into rework.
The design also needs distinctions. Missing data is not the same as contradictory data. A source that cannot be read is different from a value that violates a business rule. A low-confidence prediction may be safe to accept for an internal label but unacceptable for a payment instruction. If every problem lands in one bucket marked “needs review,” the system has moved the classification work to the user.
This is where domain knowledge becomes concrete. People who run the process already know which exceptions are routine, which can wait, and which require an immediate stop. They know what evidence resolves a dispute and who is allowed to make the call. Capturing those patterns produces a better system than another abstract conversation about model intelligence.
It also changes what should be measured. Straight-through processing is useful, but it does not tell us whether the remaining work became manageable. How long does an exception wait? Can the reviewer understand the issue without opening three other systems? How often does a resolved case return to the queue? Does the correction help the next similar case, or does the same confusion repeat?
These questions expose a common trap. A team optimizes for the percentage of cases handled without a person and treats every handoff as a failure. The result is pressure to automate decisions that are genuinely ambiguous. A well-designed escalation is not failed automation. It is the system recognizing the limit of its authority and giving the person what they need to proceed.
There is no universal exception interface. A compliance analyst needs a different review surface from a warehouse operator. One may need citations and policy history; the other may need a photo, a quantity, and a clear next action. The design has to follow the work closely enough that the exception remains part of the flow rather than an exit from it.
The happy path still matters. It shows that the basic machinery works. But it says very little about whether the product can survive contact with ordinary reality.
The exception is where the product proves it understands the work.