Skip to content

Readiness Checklist

Checklist — instantiates Cognitive Workflow Sequencing

Turns the criteria for advancing to the next phase into an explicit, verifiable list, so no prerequisite is skipped and no step begins before its conditions are met.

Version
v1 · 2026-08-24 · History
Mechanism #
7084
Type
Checklist
Form family
Decision, Gate & Allocation
Solution family
Learning & Scaffolding
Problem family
Coordination, Dependency & Sequencing Failure
Problem subfamily
Prerequisite Order & Stage Readiness
Origin domain
Aviation & Aeronautics
Also from
Engineering & Design, Medicine & Healthcare
Instantiates
Cognitive Workflow Sequencing

A Readiness Checklist externalizes the criteria for advancing past a transition into a static, verifiable list — each item a prerequisite or evidence test that must pass before the next step may begin. Its defining idea is making the transition gate visible and un-skippable: it converts a judgment that would otherwise live in someone's head ("are we ready?") into concrete, evidence-backed items that anyone can check and no one can quietly bypass under pressure. Unlike a live facilitator's read of the room, the list is a fixed artifact — reusable, auditable, and identical across instances. It verifies readiness; it does not itself order the phases, scaffold a learner, or make the decision.

Example

Before a team ships a payments service to production, an unstructured "looks good, ship it" quietly skips steps whenever a deadline looms. The release-readiness checklist makes the deploy gate explicit. All automated tests green. Twenty-four-hour soak on staging passed. Rollback plan written and linked. On-call engineer briefed. Error budget not exhausted. Security scan clean. Dependent-team sign-off recorded. Each item is a yes/no backed by evidence — a build ID, a dashboard link, a name — not an opinion. The deploy button is gated on the whole list: any unchecked item blocks the release. On one Friday push, the rollback item is empty; the release is held until a plan exists, rather than shipped on a hope. The service advances to production only when every readiness condition is objectively met.

How it works

  • Each item is a binary, evidence-backed test. "Soak test passed," not "seems stable."
  • Items derive from prerequisites. Each maps to something a skipped step would violate.
  • The list gates one transition. All items pass, or the step is blocked — the gate is the list.
  • Static and reusable. The same list applies across instances, unlike a facilitator's in-the-moment judgment.
  • Evidence, not attestation of feeling. Items point at artifacts that show the prerequisite is genuinely present.

Tuning parameters

  • Item count and granularity — a few critical checks versus an exhaustive list; longer lists catch more but invite fatigue and rubber-stamping.
  • Gate hardness — an advisory checklist versus a hard block on any unchecked item; hard blocks for high-stakes transitions.
  • Evidence standard per item — a simple attestation versus a linked proof; stronger evidence resists box-ticking but costs effort.
  • Static versus risk-scaled — one list always, versus more items required for higher-risk instances.
  • Sign-off ownership — a single approver versus distributed sign-off across the items' owners.

When it helps, and when it misleads

Its strength is making readiness objective and skip-proof: it catches the forgotten prerequisite exactly when pressure would otherwise cause it to be skipped. The checklist[1] tradition — the WHO Surgical Safety Checklist and its kin — shows why: in complex, high-pressure work, a short list of critical checks reliably catches omissions that expertise alone misses.

Its failure mode is box-ticking theater: items checked without the underlying work done, or a list grown so long after each incident that it is rubber-stamped and effectively ignored. The classic misuse is exactly that additive bloat — every postmortem bolts on another line until the checklist is unusable. The guarding discipline is to keep the list short and focused on the items that actually block readiness, and to make each item demand evidence rather than a nod.

How it implements the components

  • cognitive_prerequisite_map — each item names a prerequisite that must be present, drawn from the map of what the next step depends on.
  • transition_gate — the list defines and enforces what "ready to advance" means; it is the gate, made explicit.
  • evidence_readiness_signal — items demand evidence or attestation that each prerequisite is genuinely met, not merely assumed.

It does not order the phases themselves or run a backtracking loop (Structured Review Sequence), and it does not scaffold or pace a newcomer toward readiness (Onboarding Sequence and Learning Progression).

Editorial Notes

Form Classification

Form family: Decision, Gate & Allocation

Rationale: Readiness Checklist operates by uses binary evidence-backed prerequisites to make the single transition pass-or-block disposition. That concrete deployed or enacted form is Decision, Gate & Allocation under the frozen taxonomy.

Nearest alternative: Rule, Policy & Commitment — Although Rule, Policy & Commitment can support this mechanism, the frozen evidence makes its operative form the act that uses binary evidence-backed prerequisites to make the single transition pass-or-block disposition; the alternative is therefore secondary rather than defining.

Review outcome: Adjudicated after independent review; medium confidence.

Origin Attribution

Primary origin: Aviation & Aeronautics

Origin pattern: Convergent development

Present-day reach: Universal

Rationale: Operational readiness checklists were canonically standardized in aviation before broad transfer.

Related originating lineages:

  • Engineering & Design — Systems engineering materially shaped verification against explicit prerequisites.
  • Medicine & Healthcare — Clinical safety independently developed procedural readiness checklists.

Review resolution: Both blind reviewers agree that aviation_aeronautics is the primary origin. Explicit reconciliation of reported ambiguity, alternate origin disagreement adopts reviewer_a's classification because operational readiness checklists were canonically standardized in aviation before broad transfer. The resulting lineage records alternates=engineering_design, medicine_healthcare, origin_mode=convergent, and domain_reach=universal; these describe formative provenance separately from later applicability.

Attribution caveat: Checklists predate aviation, but aviation is the clearest modern formalizing practice for readiness gates.

Review outcome: Reconciled after independent review; medium confidence.

Notes

Other sequencing mechanisms can consume a readiness checklist at their gates — a Structured Review Sequence may use one to confirm a phase's exit criteria — but the checklist itself only verifies a transition; it neither orders the work nor makes the judgment that follows.

References

[1] Haynes, A. B., Weiser, T. G., Berry, W. R., et al. "A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population". The New England Journal of Medicine 360(5), 491–499 (2009). Shows that a 19-item surgical checklist reduced omissions of critical safety processes and improved outcomes across eight hospitals. registry