Every automation project I have worked on has had the same first week. Someone produces the process document — a flowchart, a procedure, a page in the quality system — and the room agrees that this, here, is the thing we are going to automate.
Then you sit next to the people who actually do the work, and inside an hour you learn that the document describes most of what happens and none of what is difficult. The rest is handled by three or four experienced people who know things nobody has written down, because nobody has ever asked them to.
The documented process is a description of the easy cases. The value of the team is in everything missing from it.
The procedure describes the cases that were easy to describe
Procedures are written after the fact, usually by someone summarising, often to satisfy an audit point. They capture the main path well, because the main path is the part you can describe in a sentence. Where they reach something hard, they say “escalate to the team leader.” That is not a rule. It is a pointer to a person.
Meanwhile the real exception set grows quietly for years. A regulator asked for something extra in 2021 and it became a habit. One client has a bespoke arrangement agreed over a phone call. A product line behaves differently because a migration was never finished and everybody worked around it. None of this reaches the flowchart. All of it lives in the working memory of the people who have been there longest.
Here is the cheapest diagnostic I know. Ask a team what proportion of items go straight through with nobody making a judgement call, then count it properly over a month of real cases. The counted number is always lower than the guess, and the gap between the two is the part of your process that has never been specified.
Old automation failed loudly here. A model doesn’t.
This is the part I think teams underestimate, particularly teams who have automated something before and expect the same experience.
A rules engine or a scripted workflow hits a case the specification does not cover and it stops. It errors, or it drops the item into a manual queue, and someone comes to look at it. That failure was not a defect — it was the most valuable output of the whole system. The exception queue was a live map of exactly where your written rules ran out.
A language model has no such edge. Give it a case nobody wrote a rule for and it produces something reasonable, in the right register, at the same speed and with the same confidence as the eight hundred cases before it. It does not know the case is an exception, because being an exception is a fact about your organisation’s rules, not a property of the text in front of it. So the signal that used to tell you where your process stopped being specified is gone — and it was the most useful signal in the project.
That changes the order of the work. You no longer find the exceptions by building the thing and watching it break. You find them before you build, or you do not find them at all.
Ask five people and you get five rules
Take a genuinely awkward case from the pile and ask four or five experienced people, separately, how they would handle it. Not as a workshop — a room converges on whoever speaks first.
You will get different answers. That is normal, it is not a sign of a badly run team, and it is usually the first uncomfortable finding of an AI project. The instinctive response is the wrong one: take the most senior person’s answer, write it down and move on, which treats the disagreement as noise in the way of the build.
It isn’t noise. It is the discovery that a process has been running on undocumented individual judgement for years, and that the variance was invisible because no two people ever handled the same case. The AI project did not create that exposure. It is simply the first thing that has ever measured it — the same shape as an assistant that finds the file nobody could find. The tool is not the risk. It is the audit.
There is a practical consequence as well. If you cannot state what the right answer is for a case, you cannot tell whether the machine got it right, so you cannot grade it, so you cannot build the eval set that tells you the system still works. Writing the rules down is not paperwork you get out of the way before the interesting part. It is the thing every later measurement depends on.
Get the rule out of people’s heads, using cases
Start from real cases, never from a process workshop. Ask someone to describe how they do their job and you get the procedure back, because people reconstruct the general rule. Put two hundred recently closed cases in front of them, ask about specific ones, and you get the actual reasoning.
Sort them into two piles first. Did this go through the standard path, or did a person have to decide something? Only that. The second pile is the specification you are missing, and it is always more varied than anyone expected.
Ask “what made you do that?”, not “what does the policy say?” The first question gets you the reason. The second gets you a citation to a document you have already read, which is how you ended up here.
Write it down somewhere it can be argued with. A page in plain language, naming each exception type and what to do about it, circulated to the people who do the work. Disagreement at this point costs an email. The same disagreement found after go-live costs a remediation.
Design so the boundary is a wall
Having found the exceptions, the temptation is to hand them to the model as extra instructions. That gets you a system which handles the hard cases invisibly and inconsistently — worse than one that could not handle them at all.
Route on facts, not on the model’s confidence. Confidence is about the text, not about whether your firm has a rule for this situation. Where an exception type can be detected deterministically — the jurisdiction, the amount, the product code, a client flag — detect it in code and take it out of the automated path before the model ever sees it.
Make the stop a real one. A line in the prompt asking the model to hand awkward cases back is guidance, and guidance is not a control. As I have argued before, the boundary has to live in the tool layer, where the model cannot talk its way past it.
Give the exception queue to people with time. Routing the hard cases to a reviewer who has ninety seconds each converts an unspecified process into a signature on one. The saving you booked came from the straightforward cases. Spend some of it here.
What you keep even if you never ship
The written rule set outlives the project. It survives a model change, a vendor withdrawing a feature, or a decision not to automate at all. It answers the consistency question an auditor asks and nobody could previously answer. It shortens the time a new joiner takes to become useful, because what used to take two years to absorb is now four pages. And the knowledge stops walking out with whoever retires next spring.
Most teams treat all of that as a by-product of the automation. I have come to think it is the other way round. The automation is what you get second. What you get first is finding out what your process actually is — and that has been worth having for every year you did not have it.
If your team is putting AI into a workflow and wants to find the exceptions before the build rather than after it, that is the kind of thing we work through with teams. Talk to us if it’s useful, or see how we run it in-house.