A description is what someone remembers. A record is what happened. Document from the record, then let the description correct it — never the other way round.

Ask a capable person to describe a process they run daily and you will get a clean, ordered account of the happy path. This is not evasion; it is how memory works. The exceptions are handled so automatically that they do not surface as steps, the waiting is invisible because nobody experiences waiting as work, and the order gets tidied into the sequence that makes sense in hindsight rather than the one that actually occurs.

The result is a document that is wrong on the day it is finished — not because anyone was careless, but because the method guaranteed it. Everything below is designed around that one problem. If you want the underlying argument for why the four independent accounts of a business disagree, that is the four sources of truth; this page is the practical procedure.

01 · Pick the boundaries before the steps

Name two things before you write a single step: the trigger that starts the process, and the condition that ends it. "Onboarding" is not a process — it is a topic. "From offer accepted to first productive day completed" is a process.

Get this wrong and everything downstream is contested. Most arguments about process documentation that look like disagreements about a step are actually disagreements about where the process begins and ends, held by two people who never noticed they disagreed.

02 · Pull the last five real instances

Before interviewing anyone, go to whatever system records the work — the scheduler, the ticket queue, the shared inbox, the ledger — and find five completed runs. Include at least one that went badly. If you can only find three, that is itself a finding: the process is rarer than people think, or it is not recorded anywhere, and the second is the more serious discovery.

Read across all five and write the first draft from what they show. The draft will be ugly and full of gaps. That is correct — a draft is not a document, it is bait.

03 · Write each step as an owner, a trigger, and a done condition

Three fields, every step, no exceptions:

Owner — a role, never a name. Names go stale; roles survive turnover.
Trigger — what makes this step start. Usually the previous step's done condition; when it isn't, you have found a handoff worth examining.
Done condition — how anyone can tell it is finished, observably, without asking the owner.

The done condition is the field people skip and the one that carries the weight. A step without one is exactly where work silently stalls: nobody is blocked, nobody is late, because nobody can say what "late" would even mean. Write "the record shows an approval decision" rather than "reviewed."

04 · Write the exceptions as first-class steps

Exceptions are not edge cases; in most operations they are a third of the volume. Documents that push them into a closing paragraph titled "Exceptions" are documents that stop being useful precisely when someone actually needs them — nobody consults a runbook on a normal day.

Each exception gets a named condition and a route: if the credit check has not cleared by day three, the operations lead decides whether to proceed or hold. Condition, owner, outcomes. If you cannot name the condition, you have found undocumented judgment, which is worth knowing about before you try to automate anything — determinism is one of the four properties that decides whether a process is a viable candidate at all.

05 · Have the person who does the work correct it

Now bring in the operator — not to describe the process, but to correct your wrong draft. This inversion is the whole method. Asking "how does this work?" gets you a summary. Handing over a document that is visibly wrong in three places gets you: no, that only happens if it's a rush order, and you've missed the bit where we check the second system, and that step hasn't existed since we changed vendors.

People recognise what is missing far more reliably than they recall it. A wrong draft is a better instrument than a blank page, and it takes their time in minutes rather than hours.

06 · Run the handover test

The only test that means anything: give the document to someone who has never run the process, ask them to run it, and stay in the room without answering questions.

Every question they need to ask is a defect, and it comes with its own address — you know exactly which step failed. Write the question down, let them ask it, fix the step afterwards. Two or three questions on a substantial process is a good document. Ten means you documented a description after all.

The bar A competent person who has never done this work should be able to complete it correctly using only the document. Not "understand it." Complete it. That is the difference between documentation that gets followed and documentation that gets filed.

What to do with it afterwards

A document is only true on the day it is finished unless something keeps it honest. The structural reasons procedures decay — and the sampling test for how far yours already have — are in why your SOPs are out of date before anyone reads them. The short version: name an owner per document rather than per folder, trigger review on a change event rather than a calendar date, and make sure something actually notices the change.

A process documented this way is also the only kind that is safe to automate. You cannot govern what you have not described, and an agent handed a happy-path document will handle the happy path and improvise the rest — which is the failure mode governing AI agents exists to prevent.

Where this came from

This is the documentation step of the five-step loop, run for over two years inside four multi-state operating companies with field crews and seasonal hiring before it was offered to anyone. The handover test is on the list because it is the only step that ever changed our mind about a document we were pleased with.

← All writing