How does a system learn from a resolved exception without generalising it too far?

Why it matters

Exceptions show the process with a precision the usual path rarely offers. They reveal missing information, implicit rules, dependencies, conflicts of authority and the real ways in which work is recovered.

That is why every resolved exception looks like an opportunity for the system to learn. The danger appears when a decision that was valid for one case becomes a general rule without keeping the conditions that made it reasonable.

An exception may be a precedent, but it may also be a one-off concession, a response to incomplete information, a patch, a tolerated error or a signal that the main rule needs to change.

What we know so far

To learn from an exception it is worth keeping at least:

• what triggered it;
• the context and the scope;
• what information was missing or contradictory;
• who intervened and with what authority;
• which alternatives were considered;
• which decision was taken and why;
• which action was executed;
• which result was observed;
• whether the resolution should expire or be reviewed.

It can then be classified as:

• an isolated case that should be remembered but not generalised;
• a precedent that can be consulted;
• a new explicit exception inside a rule;
• a candidate rule pending more evidence;
• a defect in the process or the interface;
• a contradiction that calls for an organisational decision.

Before building in a new rule, it is useful to look for counter-examples, test it against historical cases and run it in recommendation or shadow mode. Recurrence helps, but it does not replace an explanation of why the generalisation is valid.

What remains open

There is no universal threshold of cases beyond which an exception should become a rule. A rare, high-impact situation may deserve an explicit route from the very first case; a very frequent one may go on depending on a nuance that is hard to represent.

It remains open how to distinguish a local practice from a general policy automatically, how to decide which part of a human explanation is causal and which part is retrospective, and how to stop the system from learning the biases of whoever historically had the authority to resolve.

It also remains to be resolved when an accumulation of exceptions should improve the automation, and when it shows that the process, the policy or even the objective needs redesigning.