Exception

A case the automation stops and hands to a person.

Two kinds, and the difference matters.

The ones written into the rules are caught by design. An amount over the limit, a supplier not on the approved list, a form with a field missing. The system was told to stop for these, so it stops. Retrying changes nothing, because nothing is broken.

The ones caused by a failure have nothing to do with the work itself. The other system was down, the connection dropped, the file was locked. The same invoice would have gone through fine an hour earlier, which is why a well-built process retries before it escalates.

How many stops is a number worth having. Nobody measures it before an automation goes in, because until then a person absorbs every odd case without anyone counting. Afterwards it shows on a dashboard, and a high one says the documented process and the real one parted company some time ago. That is a finding about the operation, not a fault in the software.

An exception is not an error. The case that goes through wrongly never stopped: nothing marked it as unusual, so it was processed as normal and came out wrong. An exception announces itself and lands in someone’s queue. An error comes out looking like ordinary output and gets found later, or not at all.

AI shifts both counts, in opposite directions. A rule stops at input it cannot read, so a supplier writing the same thing a different way lands on someone’s desk. A model reads it and carries on, and fewer cases stop. A rule with no instruction also has nothing to do, so it halts. A model always has an answer, including for cases it has never met before, and that answer leaves as ordinary output.

Two things get settled before the build. Which cases get pushed out, and who catches them.

Left open, they pile up in a queue nobody owns, and trust in the automation goes with them.