In one sentence
An exception is a case the normal path does not handle.
The simple model
Most workflows have a happy path: the sequence of steps that works when everything is in order. An exception is anything that breaks that assumption. Missing information, a record that disagrees, an unusual customer, a system that is down, a request that needs approval.
Exceptions are not deviations from the "real" process. They are part of it. A workflow that only handles the happy path is only half designed.
Why you care
Exceptions usually decide whether AI is a good fit. If a workflow is 95 percent happy path with a few clear exceptions, it may automate well. If half the cases are exceptions handled by judgment, automation is much harder.
They also carry the most risk. A wrong action on a normal case is often minor. A wrong action on an exception, handled without care, is where real problems happen.
Three ways to handle an exception
When you find an exception, it usually gets one of three responses:
- Turn it into a rule, if it is stable and common enough.
- Route it to a person every time, if it needs judgment.
- Collect it in a visible queue with an owner, if it needs attention but not immediate action.
Deciding which comes later, in design. First, make sure every exception is visible.
A small example
An invoice workflow expects a matching purchase order. The exception is an invoice with no purchase order. Left undesigned, these pile up in someone's inbox. Designed well, they go to a named owner with a clear next step, and nothing is silently lost.
What this does not solve
Naming exceptions does not resolve them. Each still needs a decision about how it is handled and who owns it. But an exception you can see is far safer than one hidden inside a happy-path assumption.
