Write the rule once, with the reason next to it
Rules passed on by word of mouth drift. Rules written without a reason get broken at the edges. A simple format that works for staff and AI alike.
3 min read Provecta Group
Here are three rules as they usually exist inside a company:
"Don't give the client a discount without checking."
"Always copy Peter on anything to do with the bank."
"We don't do jobs in that area anymore."
Most firms have rules like these, and most of them get broken sooner or later. Nobody will break them out of carelessness. They will break them at the edges, in the situation the rule did not quite cover, because nobody knows why the rule exists.
Is a 3% early-payment discount a discount? Does a supplier invoice that mentions the bank count as "anything to do with the bank"? Which area, exactly, and is a returning customer in that area an exception?
Rules travel badly
Most company rules are passed on by word of mouth. The owner says it once in a meeting. Someone repeats it to a new hire, slightly differently. Six months later there are three versions in circulation and the original reason is gone.
AI makes this worse and more visible at the same time. If you tell an assistant "don't give discounts without checking", it will follow the words. It will also follow them too literally in one case and not at all in another, because it has no idea what you were worried about. A person with the context fills the gaps with judgement. An AI fills them with probability.
The format
The fix that works for both people and AI is to write each rule once, in one shared place, in three parts:
The rule. One or two sentences, as specific as you can make them.
Why. What happened, or what you are afraid of. The date if there is one.
How to apply it. What to actually check, and what to do at the edges.
Here is how the discount rule might read at a firm that has been burned once:
Rule: No discount above the published rate card goes in a quote or invoice without the sales lead's written OK. Why: Two clients compared notes and found they had been given different discounts on the same package. We had to honour the lower one for both. How to apply: Early-payment terms on the standard terms sheet are fine. Anything else, including "free first month", counts as a discount. If unsure, ask, and note the approval in the quote file.
That is longer than the original sentence. It is also the last time anyone will need to ask what it means, and an AI reading it can handle the "free first month" case correctly without being told about it specifically.
How we use this ourselves
At Provecta, rules that apply across the company are written once at the root of our company memory, which every AI working session reads before it starts, for every project. The rule does not live in one project's notes or one person's head.
Two examples from the last few weeks. On 18 June we set a rule that no individual's name appears in anything public-facing that we build: websites, reports, marketing, email footers. It is written once, with its reason, and it applies to every engagement without being restated in each. On 24 June we made a naming rule company-wide: our memory product is always spelled bRRAIn, in that exact casing. When we swept our documents against it on 8 July, it touched around 600 places across our business documents, and the sweep itself followed a written list of what to change and what to leave alone, so that code and file names were not touched.
Neither rule is clever. Both used to be the kind of thing someone would "just know", until someone else did not.
What writing it down will not do
A written rule does not enforce itself. People skim. AI models, especially in long tasks, can drift from rules they read at the start. For anything where breaking the rule is expensive or irreversible, the written rule needs a check behind it: an approval step, a form field that cannot be skipped, a review before release.
Written rules also go stale. A rule written for a situation that no longer exists will confuse people and AI alike. Put a date on each, and when the reason stops being true, retire the rule instead of leaving it to rot.
This week
Pick the five rules people in your company break most often, or argue about most. Write each in the three-part format. Share them in one place and tell the team that if a rule is not written there, it is not a rule yet.
You will find at least one where you cannot write the "why". That one is worth a conversation.
Measure where unclear process is costing you time at pgco.world/tools/operations-drag.