We misread a client brief twice. Write the exceptions down
Good defaults cause expensive mistakes when nobody writes down where they stop applying. What our own misread brief taught us about rules with exceptions.
4 min read Provecta Group
Last week a client sent us a short brief. It named a product in shorthand, the way people do when they assume you know what they mean. We read it as one thing. Then, after a correction, as a second thing. Both readings were wrong. The client meant a third thing, and it ran in the opposite trade direction from the one we had assumed.
By the time that was clear, three rounds of research and two proposal drafts had gone toward the wrong product, and one of those drafts had reached the client. Nobody was careless. Every step was done properly, on a first assumption that nobody stopped to check.
The default did what it was told
Here is the uncomfortable part. Our work followed our own rules.
Since August our written default has been to act rather than ask. If an answer can be found in the files, find it. If it cannot, make a sensible assumption, say what you assumed, and keep going. That default exists for good reasons. Stopping to ask about everything is slow, and most assumptions are fine. It is in the company memory that every person and every AI session working for us reads before starting.
So when the brief was ambiguous, the work did what the default said. It assumed, stated the assumption, and moved on. Then it did it again. The default was never wrong in general. It was wrong for this kind of case, and nothing said so.
The rule we added
We wrote the exception into the company memory the same week:
When a client brief names something in shorthand, confirm two things before starting research: which entity is meant, and which way the trade runs. Ask one short question. This is the case where a wrong guess is expensive, so it overrides the default to act without asking.
The last sentence carries most of the weight. Without it, the new rule and the old default sit side by side and contradict each other, and whoever reads them, person or AI, has to guess which wins. With it, the conflict is settled in writing.
Why exceptions get lost
Most firms write down their defaults, if they write anything. "Reply to enquiries within a day." "Use the standard contract." "Don't bother the owner with small decisions." The exceptions live in the heads of the people who learned them the hard way.
- Reply within a day, except to a complaint, which goes to the manager first.
- Use the standard contract, except for government clients, whose terms override ours.
- Don't bother the owner, except when a client asks for a discount, however small.
Experienced staff know these. New staff learn them by getting one wrong. AI tools never learn them at all, because nobody types the exception into the prompt until after the mistake, and then only into one chat.
For an AI agent, a default without its exceptions is especially risky. A person might feel uneasy about a strange brief and ask anyway. An agent following "act, don't ask" will act, every time, as confidently on the fiftieth ambiguous brief as on the first.
How to write an exception that works
From our own memory, the exceptions that hold up have four parts:
- The trigger. The specific situation, described so someone can recognise it. "A brief that names something in shorthand", not "when things are unclear".
- What to do instead. One concrete action. "Ask one short question."
- Why. The incident or cost behind it, with a date. This is what lets someone apply it sensibly to a case that is close but not identical.
- What it overrides. The default it beats, named.
If an exception is missing the fourth part, expect it to be ignored whenever the default feels more natural.
What writing it down will not do
It only catches the traps we have already fallen into. The next ambiguous brief may be ambiguous in a way this rule does not describe. Written exceptions build up over time, one mistake at a time, and the first instance of each new kind of mistake will still happen.
It also depends on the exception being read at the right moment. For people, that means it lives where they look when starting the work. For AI, it means the memory is loaded at the start of every task, not pasted into one conversation once.
Ask your most experienced person
Take your firm's three most common instructions to staff. For each, ask the most experienced person you have: when should this not be followed? Write the answers down using the four parts above, and put them next to the instruction itself.
Book 20 minutes at pgco.world/book if you would like help pulling your firm's unwritten exceptions out of people's heads.