Undocumented exceptions are part of the workflow

We keep finding that the work people most want to automate is held together by exceptions nobody has documented.

The process map shows the normal path. Experienced people know when not to follow it.

They recognise that this client needs a different form of explanation, that this supplier’s delay is not yet a risk, that a small discrepancy signals a larger problem, or that an apparently complete request should wait for another conversation. These are not always dramatic edge cases. They are ordinary variations through which professional work stays appropriate.

An illustrative composite: a team wants to automate reminder emails for overdue information. The rule looks simple. Yet staff already suppress reminders when a sensitive negotiation is active, when the recipient recently provided partial evidence, or when another colleague has promised to follow up personally. None of those conditions appears in the nominal workflow. All are part of the real one.

If the visible sequence is automated without the exception structure, the system may become more consistent and less competent at the same time.

The answer is not to enumerate every possible exception in advance. That is impossible in open professional environments. It is to design an explicit place for exceptions:

• signals that the normal path may not fit;
• a person or role that owns the deviation;
• a way to pause rather than force an answer;
• evidence carried into escalation;
• a record of what changed and why;
• review that decides whether the exception should become a new rule.

Research on situated cognition argues that knowledge is inseparable from the activity and culture in which it is used ^{2Brown, Collins and Duguid, “Situated Cognition and the Culture of Learning”}. Bainbridge’s classic account of automation also showed the irony of leaving people responsible for abnormal situations while reducing the practice that helps them handle those situations ^{1Bainbridge, “Ironies of Automation”}.

Exceptions are therefore not noise around the workflow. They reveal its operating boundaries. A system becomes safer when it can recognise the limits of its normal path and return judgement with enough context to the right person.

See context is not hiding in your database.

Sources

1. Bainbridge, “Ironies of Automation”
2. Brown, Collins and Duguid, “Situated Cognition and the Culture of Learning”