Build checklists from documented error history…

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 +… (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 +…'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 +…'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 +…). (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.