All-or-Nothing Checklist¶
Checklist — instantiates Transactional Atomicity
A checklist that refuses completion until every required transaction condition is verified.
All-or-Nothing Checklist is atomicity carried out by a person with a list. It takes a grouped action whose validity depends on several conditions all being true, enumerates those conditions as line items, and withholds the word "done" until every item is verified. The one idea that makes it this mechanism and not a sibling: it treats unverified as uncommitted — a checklist is a verification gate, not an authorization gate and not a piece of software. It does not hold assets, coordinate remote participants, or roll anything back; it simply refuses to certify completion while any required fact is still unconfirmed, so a partially-true situation can never be recorded as a finished one.
Example¶
Near the end of an operation, before the surgeon closes, the team runs the "sign-out" portion of a surgical safety checklist.[n1] The logical transaction here is declaring the operation complete and moving the patient to recovery — and it is only valid if the whole set holds: the sponge and instrument counts reconcile to the numbers taken at the start, every specimen is labeled with the right patient, any equipment problem has been logged, and the plan for recovery is stated aloud. The circulating nurse reads each item; the count comes up one sponge short. That single unverified condition stops the transaction cold. The incision does not get closed, the patient does not leave the room, and the "operation complete" record is not written — the team searches, an X-ray is ordered, the sponge is found, the count reconciles, and only then is the sign-out certified.
The payoff is that a dangerous partial state — a patient closed with a foreign object still inside — never becomes accepted reality, because the checklist made "all counts reconcile" a condition of finishing rather than a hope.
How it works¶
- Enumerate the conditions as items. Each line is a fact that must be true for the grouped action to be valid; the list is the definition of "complete," turning a vague "are we done?" into a finite set of yes/no checks.
- Verify, don't assume. An item is ticked only against direct evidence — a count read aloud, a label seen, a value on a gauge — not against someone's memory that it was probably handled.
- Refuse partial completion. The certifying step is gated on all items; one open item blocks the whole declaration, with no path to "mostly done."
- Make the failing item visible. When an item cannot be ticked, the checklist names exactly which condition is unmet, so the group knows precisely what to resolve before completion is possible.
Tuning parameters¶
- Item granularity — few coarse items or many fine ones. Fine items catch more, but a checklist long enough to feel like paperwork gets rushed or gamed.
- Verification standard — what counts as evidence for a tick: a glance, a read-back, a second person's independent confirmation. Stricter standards catch more errors and cost more time per item.
- Enforcement teeth — whether an unticked item merely nags or hard-blocks the next step (a physical interlock, a required signature). Real atomicity needs the block; a checklist that can be waived silently is just a suggestion.
- Stopping scope — whether one failed item aborts the entire bundle or only pauses at that point pending resolution. Surgery pauses and resolves; some domains abort outright.
- Cadence — one-time at the end, or run at defined phases (before start, before a key step, at close).
When it helps, and when it misleads¶
Its strength is that it makes atomicity cheap and human-legible: no infrastructure, just a list that is actually enforced. When the boundary is clear and the conditions are observable, it reliably prevents the specific failure of declaring done while a required piece is missing.
Its failure mode is the checklist that is present but not honored — items ticked in a rote sweep without real verification, so the gate exists on paper while the conditions go unchecked in fact. The classic misuse is pencil-whipping: signing off the whole list to keep the process moving, which converts a safety gate into a rubber stamp and can be more dangerous than no checklist, because it manufactures false assurance. The discipline that keeps it honest is to verify against evidence rather than memory, keep the list short enough to be run in earnest, and give at least the critical items a hard block that cannot be silently waived.
How it implements the components¶
operation_set— the checklist items are the enumerated set of conditions and actions that must all be present for the bundle to count as complete.consistency_invariant— each list is built to protect a specific invariant (counts reconcile, right patient, safe readiness); the checklist is the invariant expressed as things to confirm.precondition_validation— every tick is a validation that a required condition actually holds before completion is allowed.
It verifies facts; it does not collect the authority sign-offs (participant_acknowledgment) or gate a commit_rule on them — a checklist item can be confirmed by whoever is closest to the fact, not only by an approver. That authority-bundling is Coordinated Approval Workflow. It also holds no assets and defines no rollback_policy or compensation_path.
Related¶
- Instantiates: Transactional Atomicity — the checklist enforces all-or-nothing completion in a human workflow by refusing to certify a partial set.
- Sibling mechanisms: Coordinated Approval Workflow · Atomic Deployment Step · Batch Settlement · Contract Execution Bundle · Database Transaction · Escrow Closing · Reservation-Commit Protocol
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: A checklist that refuses completion until every required transaction condition is verified, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines All-or-Nothing Checklist as 'A checklist that refuses completion until every required transaction condition is verified', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Medicine & Healthcare
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Surgical safety checklists operationalize an enforced sign-out in which every required count, label, equipment issue, and recovery plan must verify before completion is declared.
Related originating lineages:
- Aviation & Aeronautics — Aviation checklists provide the earlier high-reliability model of read-back, independent confirmation, and hard blocking on an unresolved item.
- Computer Science & Software Engineering — Database transaction atomicity supplies the explicit all-or-nothing metaphor and consistency-invariant framing.
- Engineering & Design — Acceptance checklists enforce closure of safety-critical requirements.
Review resolution: The page explicitly instantiates its all-or-nothing verification gate through surgical sign-out, including sponge and instrument counts, specimen labels, and blocking completion. WHO's checklist confirms those exact sign-out items before a patient leaves the operating room, supporting healthcare as primary; aviation checklists, transactional computer science, and engineering verification materially shape the generalized framing.
Attribution caveat: The human checklist lineage is healthcare and aviation; describing its certification behavior as transactional atomicity is a synthesized transfer from computing.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] The WHO Surgical Safety Checklist is a real, widely adopted instrument with sign-in, time-out, and sign-out phases; the sign-out step includes instrument/sponge count reconciliation and specimen labeling. It is the canonical example of a checklist enforcing all-or-nothing completion in a high-stakes human workflow, popularized by Atul Gawande's The Checklist Manifesto. ↩