Protocol
Stop the process when the unexpected state invalidates the safety assumptions
A process is not safer because it keeps moving.
When it fits
- A workflow encounters a condition that the procedure did not cover and continuing could amplify harm.
When to avoid it
- Do not stop critical safety or continuity actions when the domain requires immediate stabilization; the pause rule must fit operational priorities.
Why it matters
Define conditions that authorize a pause: unrecognized data state, missing prerequisite, conflicting instructions, broken validation or another safety assumption. Preserve current state, escalate to the appropriate owner and resume only with a new valid plan. Make stopping a normal control, not an admission of failure.
Steps
- Recognize the unexpected condition that invalidates the current procedure.
- Stop further irreversible or scaling actions.
- Preserve evidence and current state.
- Escalate the condition and agree the revised plan.
- Resume only after required assumptions or controls are restored.
An example
A batch import sees a data pattern not covered by the validated mapping; stop the next batches rather than extrapolating the mapping live.
Check your result
Unexpected states can halt further exposure before they become a larger incident.
Keep this limit in mind
- Do not stop critical safety or continuity actions when the domain requires immediate stabilization; the pause rule must fit operational priorities.
Connected ideas
Useful withDesign recovery for the error you cannot prevent
Evidence and sources
Supports
Human-factors engineering includes resilience: detecting and mitigating unexpected events before they worsen rather than assuming every error can be prevented.
Recovery mechanisms complement prevention; they do not justify avoidable unsafe design.
Human Factors Engineering · Resiliency efforts