The One-Page Runbook, Final Form
10 min read
You have been writing runbooks since Chapter 3, in owner shorthand: notes from you to you, full of steps like "export the list" that assume the reader knows which list, from where. Handover is when the runbook grows into its final form, the version a competent stranger could run cold. It stays one page. Past one page, a runbook stops being consulted and starts being remembered, and remembered procedures drift exactly like remembered prices did.
The final-form template
Eight sections, most of them short lines:
WORKFLOW: Maintenance reminders
LANE: Yellow
WHO: Office manager runs and signs off
TRIGGER: First Monday, 9:40, inside the Monday block
FILES: Brain: /ai-system/brain/brain-current.md
Skill: /ai-system/skills/reminder-writer.md
Customer list: [accounting software] > Reports
> Plan members > filter "tune-up due"
STEPS:
1. Export the due list (see FILES for the exact path).
2. New conversation. Paste Brain, then skill, then list.
3. Review every draft against the CHECKS below.
4. Send. Log the count in the week sheet.
CHECKS (step 3, ~10 min):
- Promo terms and dates match the Brain's Right Now.
- Each email names the customer's actual plan tier.
- One sentence read aloud per email, as that customer.
DONE WHEN: Every due customer has a sent reminder logged.
WHAT GOOD LOOKS LIKE:
- 15-25 emails, under 120 words each, one booking ask.
- A normal month books 6-10 tune-ups from this send.
COMMON FAILURES:
- Export includes cancelled plans: filter by "active."
- Skill drafts a promo after promo end date: the Brain's
Right Now is stale, stop and flag to owner.
- Fewer than 10 due customers: normal in July and January.
ESCALATE TO OWNER IF: any customer on the list has an open
complaint, or the skill outputs ESCALATE, or anything here
does not match what you see.The two sections that do the heavy lifting
Everything above STEPS you have seen before. The final form's real additions are the last three sections, and they carry the handover.
What good looks like is calibration. Without it, a new operator has no way to distinguish a normal run from a broken one, so every run feels vaguely alarming, and vague alarm routes everything to you, recreating the bottleneck. "15 to 25 emails, 6 to 10 bookings" gives them the shape of normal, and with it, the confidence to sign off the normal runs alone.
Common failures is your scar tissue, written down. Every workflow accumulates a private list of the three ways it actually goes wrong, which the owner knows and nobody else does. The section is short precisely because it is real: not every conceivable failure, just the ones that have happened, with the fix attached. Update it whenever a new one earns its place; a runbook whose failure list never grows is a runbook nobody is honestly logging against.
Escalate to owner if closes the loop with Chapter 3's pressure valve, now naming the human conditions as well as the skill's own flag. Its last clause, "anything here does not match what you see," is the most important line on the page: it makes disagreement between the runbook and reality a reportable event instead of something a nervous employee papers over.
Runbooks are maintained at the point of failure
The rule that keeps the pages true: when a run goes wrong, the fix is not complete until the runbook reflects it. Same discipline as the Brain's changelog, applied one document over. The week sheet's notes column is the feeder; if "Chaser tone too stiff" shows up twice, the fix lands in the skill file and the lesson lands in Common Failures.
Try it now
Upgrade one runbook, the one you are handing over first, to final form. Then run the cold-reader test: hand it to someone who has never seen the system, your spouse, a friend, and ask them to talk you through what they would do, step by step, pointing at the page. Every place they hesitate or ask a question is a line that assumed owner knowledge. Fix those lines tonight; rung one of the pairing ladder goes much better when the page can already stand on its own.