Grow the list from defect reviews, not from taste

What it is

New checklist items should come from defect reviews: a class of failure that already escaped to staging or production proves the current list has a hole in that cell. Impression — “I feel we should check radius too” — encodes taste, never retires, and inflates the list into a collection no one can finish.

Exception: a class that has not happened yet, but whose harm analysis says one incident would be unacceptable (unrecoverable data, a widened privacy scope), may be written before the first accident. That is not impression; it is a pricing of cost. Taste has no such pricing.

Why it happens

A checklist is a filter. Its holes should match sizes already shown to leak. A review turns one escape into a class (“empty has no next step”, “disabled still clicks”), then into a decidable item. The next instance of the class is caught at inspection. Impression items have no escape as evidence; hole size comes from the proposer’s aesthetic that day, and when the proposer changes, the holes change, and the list stops being stable.

Items must also leave. An item that consecutive reviews never hit, and that no harm analysis supports, should exit the live list, or discovery cost is dragged up by dead rows. Add and delete on the same evidence rule: keep if there is an escape or a harm analysis; do not enter on impression alone. Prospective high-harm items must write “what happens if it occurs” — unrecoverable, scope widened, user cannot be told. An item that cannot write that sentence falls back to impression and may not enter under the banner of caution.

Where it stops holding

A brand-new product has no escape history, so the list will be empty. Emptiness allows two seeds only: prospective items from harm analysis, and classes rewritten from public incidents in similar products (mark the source as an external incident, not in-house taste). Brand-detail preferences that have never failed a task (a particular shadow) stay off the list and on a polish memo. A “review” that is actually “what else do we feel is missing” re-legalizes impression; the meeting must start from recorded defects, or there is no amendment agenda.

Applying it

• A new item must cite a defect identifier or a harm analysis that names an unacceptable consequence. Proposals without a citation stay out of the live list.
• Review meetings discuss only recorded escapes: which class, why current items missed it, what the yes/no criterion of the new item is.
• Once a quarter, move items with consecutive zero hits and no harm analysis out of the live list into cold storage, not deletion, so history remains searchable.
• How to check: sample ten newest items. Each must point at a defect id or a harm-analysis sentence. Unpointed items come out. Then read prospective items: those that cannot say “what happens if it occurs” are treated as impression. If total live count only grows for two consecutive quarters, the deletion rule is not running.

Related

• Same group: R2.03.1 Checklists must cover states and edge cases · R2.03.2 Automation can only police the numeric layer · R2.03.3 Semantic consistency requires human judgment · R2.03.4 Every checklist item must be answerable yes or no · R2.03.5 Order items by how cheap they are to find
• Adjacent: R2.11 Identifying and repaying design debt · R1.18 Adoption and compliance metrics
• Search terms: defect-driven · checklist evolution · postmortem · harm analysis