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

  1. Recognize the unexpected condition that invalidates the current procedure.
  2. Stop further irreversible or scaling actions.
  3. Preserve evidence and current state.
  4. Escalate the condition and agree the revised plan.
  5. 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 with
Design 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

All sources (1)