The knowledge that only lives in two people, and what happens when they are busy.

Every business has a rule like this: a certain kind of request gets approved differently depending on who happens to be reviewing it, and everyone downstream has quietly learned to route it to the person who says yes. Nobody wrote that rule down. Nobody was asked to. It exists because two or three people have been making that call for years and the organisation has organised itself around their judgement without ever naming it.

Why the business runs on it anyway

Policy documents cover the cases someone thought to write down in advance. Real work is mostly the cases nobody thought to write down, because they only show up once a quarter, or once a year, or only for one particular customer with one particular history. Someone experienced resolves them by judgement, correctly, most of the time, and the business keeps running because that judgement is reliable even though it is invisible. The problem is not that the rule is bad. The problem is that it exists in exactly two heads, and neither of those heads is available on demand.

Why documenting it has always failed

Every business has tried to fix this at some point, usually after someone senior went on leave and everything downstream of their judgement stalled. The fix is always the same: write it down. It almost never works, and not because people are lazy. Writing down a rule you hold in your head is work, it takes real time away from the job you are actually measured on, and it has no immediate payoff for you personally — the document sits in a drive somewhere while you keep answering the same question directly because that is faster for the person asking. The incentive runs backwards: the person with the knowledge pays the cost of capturing it, and everyone else gets the benefit, later, if the document is ever found and if it has not gone stale by then.

How AI changes the economics

What changes is what happens to the rule once it is captured. Filed in a document, a rule is inert — someone still has to find it, read it, and apply it correctly, which is most of why documentation drifts stale within a year. Captured into a system an assistant or an agent actually runs on, the same rule becomes executable immediately. The next time that exact situation comes up, the system applies it without pulling the senior person out of whatever they are doing. That flips the incentive the other way: telling us the rule once now saves that person from being interrupted for it forever, rather than costing them an afternoon for a document nobody reads. It is the first time the economics of capturing tacit knowledge have actually favoured the person who holds it.

How we actually surface it

We do not ask people to write their own rules down, for the reason above — it does not work, and asking again does not fix that. Instead:

• 01
  Shadow the decision, not the description

  Ask someone to explain their rules in the abstract and you get the tidy version, which is usually wrong in the details that matter. Watch them make five real calls in a week and the actual rule shows up in what they do, not what they say they do.
• 02
  Interrogate the exceptions, not the happy path

  The happy path is already in the manual, more or less. The exceptions are where the judgement lives — the case that got approved anyway, the customer who got a different answer than the policy says. That is the knowledge worth capturing, and it is never where people volunteer to start.
• 03
  Review what was overridden, and ask why

  Every system with an approval step has an audit trail of departures from the standard process. Read it looking for the pattern behind the override, not the override itself — that pattern is usually the unwritten rule, stated as a decision rather than as a policy.

The honest part

This is the slowest stage of the work, and the one most likely to stall. It depends entirely on the time and patience of exactly the busy, senior people it is trying to learn from, and there is no way to compress that by throwing more people or more tooling at it — the knowledge only exists where it exists. A project that skips this step and automates only the documented process will do that faithfully and usefully, and it will also faithfully automate the wrong answer for every case that actually required judgement. We would rather say that up front than promise a timeline we cannot keep on the part of the work that depends on someone else's calendar.

It is also never finished. New exceptions turn up as the business changes, and the two people the rule used to live in eventually move on, retire, or simply stop being asked because the system now answers directly. Treat this as a one-off capture project and it will quietly go stale the same way the abandoned policy document did. Treat it as an ongoing habit — new exceptions get reviewed and folded in as they happen — and the knowledge actually stays current, which was the entire point of writing it down in the first place.

This is one of the seven kinds of context we set out on the context page. The engagement built specifically to surface it, alongside the rest of your systems and data, is the AI Review.