Exception Handling

What Exception Handling means

Exception handling is what a workflow does when a case falls outside what it was built for. The input is malformed. The model’s result is low-confidence. A connected system is down. Something arrives that nobody planned for. The workflow has to do something in that moment, and the useful question is what, and who finds out.

The workflow article gives the test for a good answer. It names an owner, a queue or a notification, and it says whether the action is reversed or held. A vague answer about the model being very accurate is a failed test. This page is about what a real answer contains and why the work of automating a process is mostly the work of handling its exceptions.

Why a Process is Automated against its exceptions

The audit article makes the point most plainly. Every process has a happy path: the form arrives complete, the customer answers on the first call, the approval comes back the same day. That path is real, but it is rarely most of the work. The value sits in the exceptions: what happens when the input is wrong, who gets asked when a rule does not cover the case in front of them, and where the work queues while someone waits for an answer.

A process gets automated against its exceptions, not its ideal path. A tool built only for the happy path breaks on the first case that was not, and then someone has to do the work by hand anyway, on top of running the tool. The comparison of off-the-shelf tools and custom workflows says the same from the buying side. An off-the-shelf tool is designed for the average case, and a process with real exceptions eventually runs into ones the tool was never built to handle.

The failure path, step by step

The workflow article draws the failure path as a sequence, and it is worth reading as one.

1. Input arrives. It is malformed, or it is a case the system was not built for.
2. A check fails. The confidence falls below the set threshold,.
3. The case is routed to an owner. A named person or a queue is notified.
4. A person decides. They approve, correct or reject.
5. The run is recorded. The input, the decision and the reviewer are logged in the audit trail.

Every step has to exist before the workflow goes live. A check with no threshold lets everything through. A route with no owner sends the case nowhere. A decision with no record cannot be reconstructed later. The article lists these as the controls that make a process trustworthy: low-confidence results go to a person, exceptions have an owner and a recovery path, and an audit trail keeps the inputs, the model’s response and the approvals.

Who is told

An exception has to land on a person or a queue that someone owns. The running cost article’s worked example sends every mismatched invoice amount to a named person in finance, while a clean match is only sampled. That is the shape to copy: the unusual case gets a name, and the routine one does not take up the same attention.

The same article lists a question to ask about any connected system: what happens when it changes? The answer should say who is told, who fixes it and whether that work is in the price. A recovery path nobody owns is a plan on paper only, which is why the AI ownership point matters here. The person who is told has to be a named person, and not a team inbox nobody reads.

Reversed or held

The definition on this page ends with a choice: is the action reversed or held? It is worth deciding in advance, because the two are different designs. A held action waits: the invoice is not paid, the message is not sent, and the case sits in a queue until a person decides. A reversed action has already happened and is undone, which is only possible where an undo exists.

The more consequential the action, the more it should be held before it lands and not reversed after. The workflow article says that where a system can send messages, change records or move money, the question is where a human in the loop has to approve, and whether that is a deliberate design decision or a limitation nobody has mentioned.

Low confidence and review by Risk

Routing every uncertain result to a person sounds safe and can quietly erase the saving. The running cost article warns that review labour can erode the return when the time spent checking nearly equals the time the workflow saved. Its lesson is to review by risk and not by habit. A low-risk step, such as tagging an enquiry, may need only a sample check. A step that touches money, a contract or a person’s data needs a human before anything is sent or changed.

That is the line between an exception worth stopping for and one worth logging. It is drawn when the workflow is designed, in workflow design, and the cost article says to treat the person’s time as a running cost from the start.

Starting Narrow and widening with Evidence

A workflow that tries to handle every kind of document and every exception on day one is, in the running cost article’s words, the most expensive shape to run. Its advice is to start with the narrowest process worth automating, let the exceptions that really occur show themselves, and widen once figures from real use are in.

The article also names how to know it is working. The measures should include accuracy, escalation rate and time saved, and not a promise. An escalation rate that climbs is the workflow telling its owner that exceptions are arriving that it was not built for.

Exceptions in customer-facing output

The output checking article adds a case that is easy to miss. AI is agreeable by design, and that can produce generosity the business never authorised: a draft that promises a refund, a deadline, an exception or a guarantee. A sentence such as “we will make sure this is resolved by Friday” is a commitment, and someone has to own it.

So a customer-facing exception includes the exceptions the model invents. A reviewer has to catch a promise the business never made, and the design has to say who that reviewer is and what they check, in what order. The article describes the pattern across customer service as review before the response goes out, correction after it, and escalation to a person when the AI is unsure.

A worked example

This is an illustration, not a real client. A small firm automates supplier invoices. The workflow reads each invoice, pulls out the supplier, the amount and the due date, and checks them against the purchase order. A clean match is logged and sampled. A mismatched amount goes to a named person in finance, every time, and the log records who approved it.

Then a supplier changes the layout of its invoice. The extraction starts returning low-confidence results, and those cases appear in the finance queue. The escalation rate rises, the owner sees it in the weekly look at flagged items, and the workflow is repaired. Nothing was paid wrongly, because the failure path held the action. The firm learned about the layout change from the queue, not from a supplier’s complaint.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating exception handling as error logging. A log records that something failed. Handling decides who is told and what happens to the case. The second is treating a high accuracy figure as an answer. The cost article says an answer that cites the model’s accuracy has described the smallest part of the bill.

The third is treating every exception as equal. Review by risk exists because some exceptions need a human before anything moves and others only need a sample. The fourth is assuming a chatbot has no exceptions. A chatbot stalls on the failure-path test because nothing downstream was ever designed to receive a failed case.

Where it goes wrong

One failure is a path with no owner: the case is routed to a shared inbox, and nobody is accountable for emptying it. Another is routing everything to review, which makes the workflow slower than the manual process it replaced. A third is a demo that only ever shows clean input, so the failure path is never seen until a real invoice breaks it.

The last is starting wide. Trying to handle every exception at launch multiplies the cases to design, test and maintain, and the cost follows. It is better to find the exceptions that really occur and add them one at a time.

Where it appears in an Audit

An audit maps workflows as they actually run, exceptions included, and not as the tidy version written up for the audit. Finding the exceptions is part of that mapping, and so is finding who is told and what happens next. A process whose exceptions go to nobody shows up as a gap with a name on it.

If you want a process’s exceptions mapped before anything is built, a discovery call is the quickest way to find out which ones the workflow must handle first and which can wait.

Sources

• How to tell a real AI workflow from a chatbot in disguise: the failure-path test, the five-step failure sequence, the controls that make a process trustworthy, and the human-approval question for actions that are hard to undo.
• How much does an AI workflow actually cost to run: the invoice example, review by risk, review labour eroding the return, the connected-system question, starting narrow and the escalation-rate measure.
• What an AI audit actually checks: the happy path against exceptions, and mapping workflows as they run.
• How to check AI output before it goes to a customer: unsafe promises, and escalation to a person when the AI is unsure.
• Off-the-shelf AI tools vs a custom AI workflow: a tool designed for the average case meeting exceptions it was not built for.