The Exceptions Are the System

Ask anybody to describe how an order moves through your business and you get a clean answer. Enquiry, quote, acceptance, schedule, deliver, invoice. Six steps, everybody agrees, and it fits on a whiteboard.

Then ask what actually happened to the order that came in last Tuesday. You will get a longer answer, and it will contain the word usually at least twice.

The clean process is a summary, not a description

Real work is the clean path plus a large collection of exceptions. The client who always pays late but is worth keeping. The supplier whose lead times you quietly pad. The job type that needs a second sign off because of what happened in 2023. The four customers on different pricing for reasons nobody wrote down. The month when everything is re-sequenced around a shutdown.

These are not edge cases. In most operations they account for a large share of the work, and knowing which path applies is the actual skill in the job. Count them for a week before assuming otherwise.

It lives in one or two of your people. Everybody knows who. When they are away things take longer and more mistakes happen, and when they eventually leave it is not knowledge that walks out, it is the operating system.

Why this breaks software projects

Because specification captures the clean path. The person writing requirements asks how the process works, gets the six step answer and builds that. It is not negligence. It is what the question produces.

Then the system goes live and meets reality. It cannot represent the late paying client who is worth keeping, so somebody puts a note in a field meant for something else. It demands a date the supplier has not confirmed, so somebody enters one that is invented. Within six months the system holds a formal record of a process nobody follows, and the real process has moved into a spreadsheet beside it.

This is the most common way a build fails. Not technically. It works exactly as specified, and what was specified was a summary.

Why the exceptions were never written down

Partly because they are awkward. An exception is usually a compromise, and writing it down turns it into policy. The pricing one client gets because of a favour in 2019 is not a sentence anybody wants in a document other clients might eventually see, so it stays in a head, where it is safe and unmanageable.

Mostly because it was never worth the effort. Documenting forty exceptions properly takes weeks of somebody's time, the document is out of date within a quarter and nobody reads it. So the knowledge stays where it has always been.

And because exceptions are invisible from the inside. The person applying them does not experience them as exceptions. They experience them as doing the job properly, which is also why asking somebody to list the exceptions produces a short and misleading list. The question has to be answered from records rather than from recall.

What AI changed about this

The documentation problem became tractable. The exceptions are already recorded, scattered through years of emails, job notes, invoices and messages. Reading all of that used to be impossible. A system can now work through it and surface the patterns: these nine clients are consistently invoiced on different terms, this job type is reliably quoted above the standard rate, orders from this supplier are always scheduled with an extra week. You get a draft of the real process, assembled from evidence rather than from memory.

That changes what can go into a specification. Instead of six steps, you commission against the six steps plus the thirty exceptions that actually occur, with the frequency of each. Some get built. Some get deliberately left manual. Both are decisions, which beats a discovery in month seven.

There is a second effect worth naming. Stanford HAI reported in its AI Index 2024 that AI raises both the productivity of workers and the quality of what they produce, with the largest gains going to people who were previously less skilled at the task. For an operation bottlenecked on one experienced person, that is the whole point. The value is not making your best person faster. It is that the other four can now handle a job that currently has to wait for them.

What AI will not do for you

It will not tell you which exceptions to keep. Plenty of them are historical accidents that survive because nobody questioned them. Surfacing all forty is useful precisely because some should be deleted rather than encoded.

It will not be accountable for a judgement. Where an exception carries real risk, credit, safety or a legal commitment, the decision stays with a person. What changes is that the person is handed the case instead of having to find it.

And it will not replace the experienced person. It makes what they know inspectable, which is a different and more useful thing than making them redundant.

What to build instead

Before writing a specification, collect the exceptions. A month of job records and email is usually enough to find most of them.

Rank them by how often they occur and what they cost when they go wrong, then decide for each one whether it is encoded, flagged for a person, or deliberately left alone. Write down the ones you chose not to build. That list is what protects the project when somebody asks in month nine why the system cannot do something.

Design so the exception can be recorded. If the only way to handle an unusual case is to work around the system, you have rebuilt the problem inside the fix.

And check after six months whether anybody is still keeping a spreadsheet beside it. That spreadsheet is the specification you missed.

We start by reading what your business already recorded, so the specification describes the work as it happens rather than the version that fits on a whiteboard. See Custom Software.

Sources

Stanford Institute for Human-Centered Artificial Intelligence, AI Index Report 2024, 15 April 2024. hai.stanford.edu