Deployment
Unhappy paths: why everything rides on exception handling
A process goes right one way and wrong several hundred ways. Build only for the happy path and you've built a demo, not a system.
There’s a sentence we say at the start of every deployment:
Something goes right one way. It goes wrong several hundred ways. Build only for the right way and your system stops the first time it touches reality.
That isn’t pessimism. It’s a description of most of the work.
What the happy path is
The happy path is what the process document contains. The invoice arrives, we extract the fields, match it to the purchase order, key it in, someone approves it, we pay.
Building that is quick. An experienced engineer produces a working demo in a week. Which is why demos look so good.
What the unhappy path is
The same process, when:
- the invoice arrives as an image, rotated, badly lit,
- there are two attachments and one is a copy of the delivery note,
- the supplier’s name has a typo and isn’t in the master,
- the order was a partial delivery, so the amount doesn’t match,
- the invoice is in foreign currency and the rate must be from the delivery date,
- the supplier already sent it once, with a different subject line,
- the approver is on holiday with no delegate configured,
- the ERP is in a maintenance window,
- the model times out at step seven.
Those nine account for a large share of real traffic. Each needs different handling.
The four categories
When we design for exceptions, they go into four buckets.
1. The system resolves it. Rotated image? Rotate it back. Misspelled supplier name? Fuzzy match against the master, and if one hit is above 95%, move on. These are one-off pieces of work that then disappear.
2. The system recognises it and routes to a human. Amount mismatch from a partial delivery? The system notices, computes the difference, attaches the purchase order, and sends it for a decision. Not as an error message: as a prepared decision.
3. The system doesn’t recognise it, but measurement catches it. There’s no rule for these in advance. Which is why shadow mode runs, and why measurement is per category: when accuracy drops in one segment, something new has appeared.
4. Infrastructure failure. The ERP doesn’t answer, the model times out. These aren’t business exceptions, they’re technical: retry with exponential backoff, then give up at some point — but never give up silently.
The rule that matters most: nothing may vanish
When an item doesn’t go through, three things must happen:
- It lands in the exception queue, not in the void.
- It carries a reason a human can read: “supplier not found in the master
(Kovács és Tsa Kft.)”, not
ERR_VENDOR_404. - It has an owner and a deadline.
The silent failure is the most expensive failure type. A system that quietly drops 3% of cases will surface at a close three months later — and from then on nobody will trust it.
The exception queue as a metric
Queue length is the best single indicator of system health. Worth watching daily:
- Shrinking: the system is learning, or the inbound material got cleaner.
- Growing: something broke, or reality changed — a new supplier, a new format, a new rule. Both need action.
- One category dominating: that’s your next piece of work.
Handled this way the list isn’t a dumping ground, it’s a work queue. That’s the difference between a production system and a demo.
Why this is the best-returning work
Build only the happy path and your system carries 60–70% of cases, the rest stays manual, plus you’ve added a review burden. Net savings will barely be positive.
Design the exceptions too and the system goes above 90%, and what remains arrives at a person structured and prepared. That’s the difference between a project that pays for itself and one that doesn’t.
Capturing exceptions is part of discovery. Related: human in the loop.
Questions on this topic
How do we know which exceptions exist?
From the exception log during discovery. Two weeks of observation on a mid-complexity process yields 40-120 deviations — that becomes half the specification.
Doesn't this make the build far more expensive?
Building the happy path is about 20% of the work. The other 80% is exception handling, whether you plan for it or hit it in production. Planned in advance, it's cheaper.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.