Not Describe, But Transfer

The default mode of process documentation is description: here is what happens, in what order, performed by whom. Description satisfies the documentation requirement — there is a document, it covers the process, it can be pointed to. But description answers "what happens?" and the person following the process needs to know "what do I do?" The gap between those two questions is the gap between documentation that exists and documentation that works.

1. Description vs. Transfer Description documents what a process is. Transfer documentation enables someone to execute it. Description is passive — it can be read without being used. Transfer documentation is active — it is tested by whether someone can follow it to the correct outcome without asking for help. The test is the difference.
2. The Capability Transfer Test The single most useful test of process documentation: give it to someone who has never performed the process and ask them to execute it. Measure where they get stuck. Every sticking point is a documentation failure. This is not a user experience exercise — it is a quality assurance test. Process documentation that passes this test is finished. Documentation that fails it is a draft.
3. What Transfer Documentation Contains Beyond steps, transfer documentation must include: the decision criteria at every branching point, the error states and how to handle them, the completion criteria for each step, the signals that indicate something has gone wrong, and the escalation path when the process breaks down. Description documentation contains none of these. Transfer documentation requires all of them.
4. The Audience Specification Transfer documentation is written for a specific person with a specific knowledge baseline. "Write for a day-one hire" is different from "write for an experienced practitioner new to this specific process." The baseline determines what is explained and what is assumed. Documentation written for no specific reader will fail for every specific reader.