Build checklists from documented error history, not hypothetical failures — promote errors to checklist items only after they actually occur

Why This Is a Rule

Hypothetical checklists ("What could go wrong?") produce items based on imagination, which systematically overweights dramatic-but-rare failures and underweights mundane-but-common ones. You imagine the catastrophic client data breach but not the routine formatting error that actually occurs weekly. The result is a checklist full of dramatic edge cases that never trigger and missing the boring recurring errors that actually degrade your output quality.

Empirical checklists ("What has gone wrong?") are built from the actual error record — documented instances where specific errors occurred in real deliverables. Each item is grounded in evidence: "This error happened on [date], in [deliverable], with [consequence]." The checklist targets your actual failure patterns, not your imagined ones, producing dramatically better error reduction because it's calibrated to your real weaknesses.

This mirrors the aviation industry's approach to safety checklists: items are added in response to actual incidents, not theoretical risks. The pre-flight checklist evolved from documented accidents where specific checks would have prevented the crash. Each item represents a real failure, making the checklist a compressed history of actual errors rather than speculative risk assessment.

When This Fires

• When building a new checklist for any output type
• When an existing checklist doesn't catch the errors that actually occur
• When a real error occurs and you want to prevent recurrence
• Complements Limit checklists to 5-9 items targeting frequent + consequential errors, ordered catastrophic-first for partial execution under time pressure (checklist design) with the methodology for selecting checklist items

Common Failure Mode

The brainstormed checklist: gathering a team to list "everything that could go wrong." This produces 30 items, mostly hypothetical, weighted toward dramatic failures. The real error pattern (which is mundane and repetitive) is buried under imagined scenarios. The checklist becomes too long (violating Limit checklists to 5-9 items targeting frequent + consequential errors, ordered catastrophic-first for partial execution under time pressure's 5-9 limit) and poorly targeted (missing actual failure patterns).

The Protocol

(1) Start an error log: every time you deliver output that contains an error caught by yourself, a reviewer, or a recipient, document: what the error was, when it occurred, what consequence it had. (2) After accumulating 10+ documented errors, analyze the pattern: which errors repeat? Which have the worst consequences? (3) Build the checklist from the top-ranked empirical errors using Limit checklists to 5-9 items targeting frequent + consequential errors, ordered catastrophic-first for partial execution under time pressure's frequency × consequence filter. (4) When a new error occurs that isn't on the checklist, add it — and remove the lowest-ranked current item if the checklist exceeds 9 items (Limit checklists to 5-9 items targeting frequent + consequential errors, ordered catastrophic-first for partial execution under time pressure). (5) The checklist is a living document calibrated to your actual error pattern, not a static list of hypothetical concerns. Review and update quarterly based on your evolving error log.