Place pre-flight checks at the prep/execution boundary — catch errors after setup but before propagation starts
Position pre-flight checks at the boundary between preparation and execution—after work is ready but before it begins—to catch errors when correction cost is minimal and propagation has not started.
Why This Is a Rule
The prep/execution boundary is the moment of maximum leverage for error detection. Before this point, the work isn't ready to check — you'd be verifying incomplete state. After this point, errors begin propagating through downstream processes and correction costs escalate with each step (When the cost of late error discovery exceeds 5x early discovery, invest more in detection before proceeding to the next phase).
Aviation positions pre-flight checks exactly here: after the aircraft is loaded, fueled, and configured (preparation complete) but before engines start and taxi begins (execution not yet started). At this boundary, finding a fuel discrepancy costs a 10-minute delay. Finding it during flight costs an emergency diversion. The same cost asymmetry exists in any multi-step process: catching a configuration error before deployment costs minutes; catching it in production costs hours.
The positioning requirement is specific: not "somewhere before execution" but at the boundary. Too early (during preparation) means you're checking incomplete state that will change before execution. Too late (during execution) means propagation has already begun. The boundary is the Goldilocks zone where state is final but consequences haven't started.
When This Fires
- When designing verification procedures for any multi-step process
- When determining where in a workflow to place quality gates
- Before any deployment, publication, delivery, or irreversible action
- Complements When the cost of late error discovery exceeds 5x early discovery, invest more in detection before proceeding to the next phase (phase-gate cost ratios) with the specific optimal placement criterion
Common Failure Mode
Checking too early in preparation: "Let me verify the configuration now, before I finish setting everything up." If preparation continues after the check, the verified state may change. The pre-flight check must occur after all preparation is complete — otherwise it's checking a snapshot of an evolving state, not the final state that enters execution.
The Protocol
(1) For any multi-step process, identify the prep/execution boundary: the moment when all preparation is complete and execution is about to begin. (2) Design a pre-flight checklist (Checklists are 5-10 items that catch what competent people skip under load — not comprehensive process documentation) positioned at this boundary. (3) The checklist verifies: is the current state what execution expects? Are all prerequisites met? Are all configurations final? (4) Execution does not begin until the pre-flight check passes. No exceptions for "we're in a hurry" — the cost asymmetry always favors the check. (5) If the check reveals an error → correct it now (preparation-level cost). If you skip the check and the error propagates → correct it later (execution-level cost, typically 5-50x higher).