Automation Needs Exceptions
Which is worse: a process that stops when something is odd, or one that keeps going?
The idea
Automation is reliable only when unusual cases have an explicit path.
In the real world
An invoice workflow routes mismatched totals to review.
Going deeper
Automation is a claim that you have enumerated the cases. The happy path is easy to enumerate because you designed it; the exceptions arrive from reality, which was not consulted.
What makes undefined cases dangerous is that they do not announce themselves. A process with no rule for a mismatched invoice does not stop and ask — it applies whatever the code falls through to, silently and at machine speed. A human doing the same job by hand would have paused, because a person notices when something is odd. Removing the human removes the noticing, so the noticing has to be rebuilt explicitly as a rule that routes the unusual case somewhere.
Where it stops applying
Not every exception deserves a coded path. For rare, low-cost cases the right design is often to halt and alert a person, rather than to automate a judgement you cannot specify.
Why it matters
It moves your attention from the happy path, which is easy, to the edge cases, which is where automated systems quietly do damage.
Try this today
List three failure states before automating a process.
Test yourself
An automated invoice workflow meets a total that does not match the purchase order. It has no rule for that case. What does it do, and why is that the dangerous outcome?
Show the answer
With no explicit path it either halts the whole queue or, worse, applies the default and pays the wrong amount without anyone seeing it. Undefined cases do not announce themselves; they resolve silently in whichever direction the code happens to fall.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.