Preflight Checklist¶
Precondition checklist — instantiates Transition Readiness Assessment
A fixed, compact list of must-pass conditions run the same way immediately before a repeatable crossing — each item a binary go/no-go against a known failure mode, so nothing routine gets skipped under pressure.
A Preflight Checklist is the most compact instance of the archetype: a short, fixed list of must-pass conditions, run identically every time immediately before a routine crossing. Its distinctive property is that the criteria are pre-decided and binary — each item is a clean yes/no against a known failure mode, with no room for graded judgment or negotiation in the moment. Where a review deliberates and a scorecard weighs, the checklist merely verifies; its whole power is defeating the human tendency to skip a familiar step under time pressure by making any omission conspicuous. It fits transitions that recur often and fail in well-understood ways.
Example¶
An engineer is about to promote a build to production — a frequent, routine crossing with a known catalogue of ways it goes wrong. The preflight checklist, run identically on every deploy, reads: tests green on the release commit; database migration backward-compatible; new feature flag defaulted off; on-call engineer identified and paged in; rollback command tested against this build; error budget not already spent; not inside a change freeze.
On this run everything passes except one item — "migration backward-compatible" — because the migration drops a column the currently-running version still reads. The checklist does not deliberate or weigh; it just refuses to skip the one item that matters, so the deploy is blocked at 4pm at a desk rather than discovered at 4am in an incident. The value was not judgment — it was that a routine, easily-skipped check was forced into the open every single time.
How it works¶
- Fix the list in calm conditions. The items are agreed from known failure modes ahead of time and change only by deliberate revision — never ad hoc under deadline.
- Keep it short and binary. Only must-haves, each a clean pass/fail; anything graded or "it depends" belongs on a scorecard or in a review, not here.
- Run it the same way every time. Same items, same order, so familiarity cannot erode it and a skipped item stands out.
- One fail is a no-go. The checklist does not average or weigh — any single failed item stops the crossing.
Tuning parameters¶
- List length — how many items. Longer covers more failure modes but breeds rote box-ticking and dilutes the critical few; shorter stays sharp but can miss a rare mode. Length-induced automaticity is the classic checklist killer.
- Item bar — what counts as "pass" for each item, from a glance to a verified test. Stricter items catch more but slow the run.
- Read-do vs. do-confirm — whether items are performed by the list or merely confirmed after. Do-confirm is faster; read-do prevents skipping.
- Revision cadence — how a new near-miss gets added and a stale item retired. A living list stays relevant; a frozen one rots.
- Waiver discipline — whether any single failed item hard-blocks or can be waived, and by whom. Hard blocks preserve the list's authority; easy waivers dissolve it.
When it helps, and when it misleads¶
Its strength is that it is the cheapest, fastest instance of the archetype and it defeats the skipped-routine-step failure that causes disasters in familiar operations — repeatable, auditable, and immune to the moment's optimism.
Its failure mode is that it can only ever cover anticipated failure modes: it is blind to the novel one that is not on the list, and "all green" breeds false confidence that safety has been proven when the real risk is off-list. The classic misuse is rote automaticity — running it from muscle memory, eyes ticking boxes without truly verifying, so an item is "checked" but not checked — and bloating it until the signal drowns. The discipline that guards against this is to keep it short and binary, treat it as a floor rather than a proof of safety, revise it from near-misses, and pair it with a deliberative review for whatever is non-routine.[1]
How it implements the components¶
readiness_criteria— the checklist is the codified must-have criteria, frozen into a fixed, pre-agreed list of the conditions required before crossing.threshold_check— running it performs the minimum-conditions check: each item is a binary pass/fail against the line for safe crossing, and any fail sits below the threshold.
It holds no graded evidence, confidence, or gap severity — that aggregation is the Readiness Scorecard; it names no cross-functional owners (the Launch Readiness Review) and checks no day-2 operability (the Operational Readiness Review). Building the route to close a failed item is a Gap Remediation Plan; deciding who may waive one belongs to the Go / No-Go Meeting.
Related¶
- Instantiates: Transition Readiness Assessment — the compact, binary floor for a routine crossing.
- Sibling mechanisms: Readiness Scorecard · Launch Readiness Review · Operational Readiness Review · Go / No-Go Meeting · Phase-Gate Review · Gap Remediation Plan · Preflight-style checks in a Clinical Discharge Readiness Check
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Preflight Checklist operates as a repeatable ordered procedure or handoff sequence that coordinates action because it a fixed, compact list of must-pass conditions run the same way immediately before a repeatable crossing — each item a binary go/no-go against a known failure mode, so nothing routine gets skipped under pressure.
Independent corroboration: The frozen evidence defines Preflight Checklist as 'A fixed, compact list of must-pass conditions run the same way immediately before a repeatable crossing — each item a binary go/no-go against a known failure mode, so nothing routine gets skipped under pressure', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Aviation & Aeronautics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: The fixed preflight checklist was institutionalized in aviation to prevent omission of known go/no-go conditions under pressure.
Related originating lineages:
- Engineering & Design — Safety engineering generalized binary readiness checks across hazardous operations.
- Medicine & Healthcare — Surgical and clinical safety independently adapted pre-action checklists to high-consequence care.
Review resolution: Both blind reviewers agree that aviation aeronautics is the primary origin. Reconciliation resolves alternate origin disagreement, origin mode disagreement. Formative alternate lineages are retained as engineering_design, medicine_healthcare; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The checklist's fixed, binary form is exactly why it is blind to the unanticipated: it can only ask the questions someone already thought to add. It is a floor under routine crossings, not a substitute for judgment on novel ones — and keeping it short is what preserves its single power, that a skipped item is obvious.
References¶
[1] Atul Gawande's The Checklist Manifesto (2009) documents how short, fixed checklists — modeled on aviation preflight checklists — reduce errors in complex but routine work by preventing skipped essential steps. It is the standard reference for why a preflight checklist's value is omission-prevention rather than deliberation. registry ↩