Every checklist item must be answerable yes or no

What it is

Every checklist item must yield a yes or no on the spot (binary checklist decidability). “Watch the spacing” and “feels coherent” have no pass condition; two inspectors leave incomparable ticks. A decidable item looks like a test: object, how to look, pass criterion. An item that cannot produce yes or no is not finished being written.

Beside yes/no, three non-passes must stay distinct: not applicable (the item is meaningless for this object), cannot verify (it applies but evidence is missing now), and fail (evidence is in and the criterion is missed). They are not synonyms for “skip”. Collapse them into one cell and the record is gone.

Why it happens

Executing a list is a sequence of decisions. A decision must terminate or the next step has no branch. Vague items hand termination to mood, so two runs on one product produce two sets of ticks, trends cannot be drawn, regressions cannot be run. Decidability hands termination to a criterion: does spacing sit on the named scale, does empty offer a next action, does the error sit beside the field — each sentence can be falsified on this page.

The four outcomes are the record’s structure. Not applicable means the object is outside the item’s domain (a terminal page with no empty). Cannot verify means the domain hit but evidence is absent (staging has no overflow data). Fail means evidence is in and the criterion broke. Logging cannot-verify as pass fabricates coverage; as fail, it forces a change to something unseen; as not applicable, it hides “this should have been checked”. Keep them apart so the next run knows whether to fetch data or delete the item.

Where it stops holding

Exploratory review, whose job is to find problem types not yet named, is not a checklist job; open notes are. Forcing exploration into yes/no drives unnamed problems out of view. Legal text that itself says “reasonable” or “adequate” is not yet decidable — write an observable proxy and mark that the proxy is not the clause. When the team has not agreed the pass criterion, the item stays a draft; putting it into execution lets everyone fill yes/no with a private rule, decidable on the surface, incomparable in fact.

Applying it

• Write each item as “where, what to look at, what counts as yes”. An item missing the third clause does not enter the live list.
• Record four cells: yes, no (fail), not applicable, cannot verify. Ban “sort of” and “partial pass”.
• Cannot-verify must name the missing evidence (account, data, device) and the item must be re-run when the evidence arrives; an old “skip” must not stand in.
• How to check: sample one executed page. “Overall fine”, or cannot-verify ticked as pass, fails the item. Have two people run the same item back-to-back; on disagreement, change the criterion, not the person. A record structure missing the cannot-verify cell is incomplete.

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.5 Order items by how cheap they are to find · R2.03.6 Grow the list from defect reviews, not from taste
• Adjacent: R1.18 Adoption and compliance metrics · R2.05 Edge-case delivery completeness
• Search terms: decidability · yes-no checklist · not applicable · cannot verify