Exception and Emergency Procedures: What to Do When Things Go Wrong

The buyer's problem

Procedure corpora skew toward the normal path. A model grounded only on those learns what to do when the cup is on the table, not what to do when the cup is cracked, the door is locked or an alarm is sounding. In deployment, the costly failures are often the unexpected ones, and a system that continues past a stop condition is worse than one that halts.

Operating businesses already document abnormal situations in escalation matrices, alarm response cards, spill and incident procedures, and "what to do if" sections of SOPs. These documents encode organizational decisions: who has authority, what counts as safe, and what the robot-equivalent of a worker must not attempt.

Why asking for help is itself a research problem

Robots that ask for help when uncertain are an active topic. KnowNo measures and aligns the uncertainty of LLM planners so the robot asks for help when needed, using conformal prediction to give statistical task-success guarantees with minimal human help; the authors report reducing the help needed by 10-24% against baselines (Ren et al., 2023). The result concerns a particular method and benchmarks, not a general rule.

The relevance for procedure buyers is that a planner needs to know which situations call for help at all. Statistical triggers address uncertainty about the plan; a workplace procedure defines events where help is mandatory regardless of confidence, such as a gas smell, a person in a hazard zone or a failed isolation check. Both are needed, and only the second comes from documents.

What exception procedures contain

• Trigger conditions: observable events or readings that start the exception.
• Immediate action: stop, make safe, isolate, evacuate, or hold position.
• Authority: who may restart, override or declare the event closed.
• Escalation path: roles, order and contact method.
• Containment and cleanup: spill, breakage or contamination handling.
• Recording: what to log, photograph or report.
• Restart conditions: checks before resuming normal operation.

Hazardous-energy control is a clear case of explicit exception logic. OSHA's standard requires employers to develop, document and use specific procedures to control potentially hazardous energy when employees service equipment (OSHA, 29 CFR 1910.147). It illustrates how stop conditions and isolation steps are written down. This is not legal advice, and emergency obligations vary by industry, state and employer.

What the data can support, and what it cannot

The documents cannot show how to physically make safe a leaking container, how fast a person reacts, or what an emergency looks and sounds like. Real incidents are also underrepresented in procedures and are the hardest data to obtain. See deviation reports for after-the-fact records, and job hazard analyses for pre-task hazard reasoning.

Emergency procedures are meant for people. Many assume human judgment, voice communication, physical presence and legal authority. Translating them into robot behavior is a design and safety engineering task. Do not infer that a robot should perform an emergency action because the document tells a worker to.

Illustrative exception record

# Illustrative only - synthetic example, not an available dataset
exception_id: exc_0071
parent_procedure: eq_op_0044 (rev r2)
trigger:
  type: observation
  description: "Water visible on floor around unit"
  observable: visual
immediate_action:
  - "Stop current task"
  - "Do not touch unit controls"
robot_relevant_rule: halt_and_notify       # annotation added in preparation
notify:
  - role: shift_lead
    method: radio
authority_to_resume: facilities_supervisor
restart_checks: ["Floor dry", "Leak source identified"]
record: incident_log_entry
severity: moderate
source_type: site_procedure

The robot_relevant_rule field is an annotation, not part of the original document. Keep the original text and your interpretation in separate fields so reviewers can audit the translation.

Preparing and evaluating the set

Exceptions often sit as one paragraph inside a longer SOP, in an appendix, or on a separate laminated card. Extraction must connect each exception to the step and equipment that can trigger it; see branching procedures and decision points for the structure. Normal-operation counterparts are covered in equipment operating procedures.

For clarity-seeking behavior in cases where an instruction is incomplete rather than dangerous, see ambiguous instructions and clarification. Mark critical entries as described in safety-critical steps in procedures.

Acceptance criteria to set:

1. Trigger observability. Share of triggers that a camera or standard sensor could detect, versus those needing a person.
2. Link integrity. Each exception resolves to a parent procedure, equipment class and role.
3. Authority clarity. Every exception names who can resume.
4. Review. A safety professional reviews a sample for omissions.
5. Separation. Original text and robot-oriented annotations are stored separately.

Rights and sensitivity

Emergency procedures can reveal facility layouts, security arrangements, alarm systems and response times. Some are treated as security-sensitive and are not licensable. Incident records may name individuals or describe injuries; they raise additional privacy and liability questions and typically need stricter handling than routine SOPs. Ask for a separate license decision for incident-derived material.

Limitations

A corpus of exception procedures documents what organizations planned for. It cannot cover novel failures, and it is silent on the edge cases where staff improvise. Procedures differ in tone and detail between businesses, so a small number of suppliers will bias your stop rules toward their sector. And stop-and-escalate behavior needs testing on robots, in controlled conditions, with safety engineering, not only on text.

Questions to ask suppliers

1. Which documents define abnormal conditions, and who owns them?
2. Are exceptions integrated into SOPs or kept in separate emergency plans?
3. Which parts are security-sensitive or restricted by insurers or regulators?
4. Do incident or near-miss records exist that link to these procedures, and can identities be removed?
5. How often are procedures drilled or revised after incidents?
6. Which triggers rely on human senses (smell, sound) rather than readings?
7. Are escalation contacts and systems described by role, so they can be generalized?
8. Can you separate exception procedures from operational ones in a license?

Discuss your requirements

If stop-and-escalate behavior is part of your evaluation, describe the workplaces, procedure types and permitted uses to SourceX. SourceX looks for US businesses that hold suitable documents, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources.

See the humanoid training data guide, the procedural data hub, and the SOPs and playbooks catalog entry.

Discuss your humanoid training-data requirements with SourceX

Sources

• Robots That Ask For Help: Uncertainty Alignment for Large Language Model Planners — KnowNo aligns LLM-planner uncertainty so a robot asks for help when needed, using conformal prediction, and reduces help needed by 10-24% versus baselines.
• 29 CFR 1910.147 The control of hazardous energy (lockout/tagout) — OSHA's lockout/tagout standard requires documented, specific procedures to control hazardous energy when equipment is serviced.