Physical Constraint Design For Impossibility¶
Make the wrong action physically impossible, materially rejected, or harder than the correct action.
The Diagnostic Story¶
Symptom: The same wrong action keeps recurring despite training, signage, checklists, and reminders. The incorrect action is physically possible — often easier, faster, or visually similar to the correct one — so it happens under load, interruption, or fatigue. Defects are found downstream, after cost or harm has already accumulated, because the prevention strategy relies on human vigilance rather than on the structure of the system. Near-misses cluster around the same ports, steps, labels, or controls.
Pivot: Stop asking memory, training, and inspection to compensate for a permissive action space. Instead, identify the physical or procedural degrees of freedom that currently allow the wrong action, and change shape, fit, sequence, interlock, default state, or access route so the undesirable action is blocked or rejected before judgment must intervene.
Resolution: The wrong action is no longer available in the action space under ordinary conditions, so error prevention no longer depends on sustained vigilance. Downstream exception paths stop being overloaded with the same preventable defect class. The system's safety is embedded in its structure rather than delegated to the people operating it.
Reach for this when you hear…¶
[manufacturing] “We've retrained the line three times for the same wrong-orientation assembly — just change the connector shape so it physically cannot go in backwards.”
[hospital pharmacy] “The look-alike vials keep getting mixed up; labels and warnings haven't fixed it in two years — the storage design needs to make co-selection impossible.”
[software deployment] “If running the migration in the wrong environment is possible from the same terminal session, someone will eventually do it — make production credentials unavailable in the dev shell.”
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (1)
- Error Proofing (Poka-Yoke): Error prevention.
Also references 20 related abstractions
- Access Control: Restrict system access.
- Cognitive Load And Attentional Capacity
- Constraint: Limits possibilities to guide outcomes.
- Controllability: Ability to steer system.
- Data Integrity: Accuracy and consistency preserved.
- Decision: Committing to one alternative from a set under uncertainty and trade-off, collapsing open deliberation into a chosen path and foreclosing the others.
- Design for Implementation: Real-world feasibility.
- Fail-Safe: Default to safe state on failure.
- Feedback: Outputs influence inputs.
- Human-Centered Accommodation: Adapt to human limits.