Chapter 21 · Bound embodied agents with safety and release evidence

Today in the field story

One problem, then the next

A hazard row now becomes a testable Courier-17 scene. You state the initial condition, variation, trigger, expected guard or recovery, quantitative threshold, evidence source, reset, and what the test cannot establish. For example, a stale card pose must cause rejection before dispatch within the measured software path; that result says nothing about every sensor or a real stopping function. Scenarios are frozen before execution so favorable observations cannot rewrite the acceptance rule.

Why now: Hazard language becomes useful only when connected to predeclared evidence.
Ignore today: Do not claim legal compliance or generalize one simulator scenario.
Unlocks next: A risk-linked scenario manifest with honest evidence boundaries.

Understand

Build the physical picture first

A hazard becomes testable only after one scenario fixes the state, trigger, expected response, thresholds, evidence, and reset.

Keep hazard, hazardous situation, initiating cause, failure mode, and harm distinct. Robot collides with a person describes an unwanted event or harm path; stale localization, blocked protective sensor, planner selects a narrow aisle, and brake performance degrades are different contributors. A risk review considers the whole application and life cycle, including setup, recovery, maintenance, cleaning, degraded operation, and foreseeable misuse. A model failure taxonomy is useful but cannot replace physical hazard analysis.

A scenario is an executable slice of that analysis. Specify system and environment versions, initial robot and world state, people or surrogate positions, authorized goal, one controlled variation or fault, timing, expected control response, terminal outcome, quantitative acceptance criteria, required evidence, reset, and repetition count before running it. Freeze those fields so the team cannot improve the setup after seeing a failure and still call it the same case.

A lightweight safety-case structure connects a narrow claim to an argument and evidence. For example: claim, this simulated build rejects navigation when the frozen obstacle clearance is below the exercise boundary; argument, fresh ranging and speed feed a fail-closed validator before command publication; evidence, versioned configuration, calibration assumptions, trace, command count, and repeated boundary cases. This can organize engineering evidence, but it is not legal certification and does not establish an unevaluated real deployment.

Acceptance criteria must include behavior during failure, not only successful completion. Declare whether the correct result is autonomous success, clarification, re-observation, replan, bounded retry, human handoff, or safe abort; set deadlines and forbidden events; and state what evidence proves no later unauthorized command occurred. A safe abort can pass a hazard scenario while failing the business objective. Preserve both judgments instead of relabeling the abort as general success.

Words you need

Name each idea precisely

Hazard: A potential source or condition of harm considered across the complete robot application and its modes of use.
Physical example:
Stored mechanical energy and a moving arm create crushing or impact hazards even when the task planner is behaving as designed.
Hazardous situation: A circumstance in which a person, asset, or environment is exposed to one or more hazards.
Physical example:
A technician enters the cell during recovery while motion can still be commanded.
Acceptance criterion: A predeclared observable threshold or predicate that determines pass, fail, or blocked for one test claim.
Physical example:
No base command after protective-state loss, stop transition within the simulated 150 ms requirement, and complete correlated trace.
Scenario manifest: The frozen identities, versions, initial state, variation, expected behavior, thresholds, evidence, and reset instructions for a repeatable case.
Physical example:
Manifest cross-aisle-04 pins map, robot build, validator rules, starting pose, obstacle position, speed, injected sensor delay, and trace fields.
Claim–argument–evidence: A structured way to state a bounded assurance claim, explain why controls should support it, and link the exact observations that test it.
Physical example:
A claim about rejecting stale commands links to expiry enforcement and traces showing zero controller publications after the deadline.
Forbidden event: An observable occurrence that causes failure regardless of whether the task eventually completes.
Physical example:
Entering a protected zone, publishing an unauthorized velocity, exceeding a force threshold, or continuing after stop-state loss fails the case.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalRisk, stopping distance, and confidence

Safety claims need physical bounds and enough trials, not reassuring language.

d_react = vt: distance travelled during reaction delayUnit: metres (m)
d_brake = v²/(2a): ideal braking distanceUnit: metres (m)
risk: severity combined with likelihoodUnit: ordinal score

At v=1 m/s and reaction t=0.2 s, d_react=1×0.2=0.2 m.
With braking deceleration a=2 m/s², d_brake=1²/(2×2)=0.25 m.
Ideal total is 0.45 m; add measured margin for sensing, actuation, floor, load, and uncertainty.

Programmer analogy

A security threat model maps assets and controls; robot safety adds kinetic energy and independently enforced stops.

At 0.5 m/s with 0.2 s reaction time, what is reaction distance?

0.5×0.2 = 0.1 m.

Pre-braking travel is

d_r=vt=(0.4\ \mathrm{m/s})(0.15\ \mathrm{s})=0.06\ \mathrm{m}.

The provisional separation is

d_{\min}=0.06+0.12+0.05=0.23\ \mathrm{m}.

Turn one cross-aisle hazard into three frozen scenarios

The teaching envelope from Day 141 is 0.60 m. A simulated AMR starts 1.2 m from a crossing at 1.0 m/s. The test harness can place a pedestrian surrogate at clearances 0.75 m, 0.60 m, and 0.52 m and can record proposals, permits, commands, state, and outcome.

State the narrow claim: build agent-21.3 rejects or stops approach commands that would violate the frozen 0.60 m exercise boundary in this simulator.
Separate hazard contributors: moving base, blind crossing, reaction delay, braking assumption, localization and ranging freshness, planner route choice, and potential entry of the surrogate.
Create nominal S144-N at 0.75 m, boundary S144-B at exactly 0.60 m, and failure S144-F at 0.52 m while keeping versions, start, speed, map, and seed fixed.
Declare expected outcomes before execution: nominal may continue, boundary must follow the explicitly chosen inclusive rule, and failure must reject or stop with no command beyond the forbidden point.
Require synchronized range, speed, protective state, semantic proposal, permit decision, published command count, controller feedback, final pose, and reset confirmation for every run.
Run each case three times, preserve every failure, and write the limitation: synthetic geometry and braking do not establish real sensor coverage, floor friction, brake performance, human behavior, or compliance.

Result

The hazard is represented by three reproducible cases with a declared inclusive boundary, nine retained traces, and a scoped claim that can fail without rewriting the scenario.

What this proves

Freeze the claim and test conditions first; otherwise a convincing demo can move its own goalposts and conceal boundary failures.

Physical examples

Where this appears in real life

Cross-aisle pedestrian surrogate

A cardboard silhouette or simulated pedestrian enters a marked blind crossing while an AMR approaches at a fixed starting speed.

Look for:

The manifest fixes entry time, speed, sensing assumptions, boundary, expected stop or rejection, forbidden region, trace fields, and reset before any trial begins.

Recovery beside a jammed gripper

A simulated pick times out and requests human assistance while the arm remains near the tote and stored motion commands are queued.

Look for:

The scenario covers cancellation, queue drain, safe state, operator indication, authority transfer, and prevention of automatic resume—not merely the original grasp failure.

Hands-on exercise

Make the idea observable

Use paper markers or simulation only. Choose one hazard relevant to your existing capstone and avoid electrical, force, sharp-tool, or powered-motion experiments.

Write the hazard, exposed party or asset, operating modes, initiating events, existing controls, residual concern, and competent owner without assigning a numerical risk class you cannot justify.
Create nominal, boundary, foreseeable-fault, and recovery scenarios with unique IDs and one controlled change per case.
Pin software, model, processor, validator, configuration, map or scene, seed, initial state, goal, timing, thresholds, forbidden events, and reset steps.
For every acceptance rule, name the exact trace field or independent observation that proves it; mark any rule whose evidence source does not exist as blocked.
Have another person or a second pass read only the manifest and predict the expected terminal outcome, then fix ambiguity before executing.
Run the frozen cases, retain unexpected results, and add a limitations section separating simulation evidence, application-level checks, and unverified real-world safeguards.

Observe

Missing reset, unclear boundary equality, unobservable forbidden events, and unfrozen configuration often make a scenario impossible to reproduce even when the first run looks successful.

Done when

Each case has one ID, one controlled variation, predeclared expected behavior, measurable criteria, complete evidence fields, repeatable reset, and an explicit non-certification boundary.

Build today

Create a scenario runner that measures task success, intervention, recovery, latency, and unsafe attempts.

Evidence to save

DONE when the integrated “Hazard analysis, safety cases, scenario design, and acceptance criteria” path is observable, cancelable, and leaves the prior baseline reproducible.

Common mistakes

Catch the wrong mental model

Wrong

Using model produced an unsafe action as the complete hazard analysis.

Better

Trace people, energy, environment, hardware, software, modes, initiating causes, safeguards, recovery, and foreseeable misuse across the full application, then place model behavior within that analysis.

Wrong

Choosing acceptance thresholds after inspecting the results.

Better

Freeze thresholds, equality behavior, terminal categories, forbidden events, and evidence sources before the first run; revise future versions openly rather than relabeling past traces.

Wrong

Calling a simulation scenario a safety certification.

Better

State the exact simulated claim it tests, preserve limitations, and defer real application approval to competent review, measured safeguards, site conditions, and current applicable requirements.

Job connection

How this becomes employable evidence

Translate a language-conditioned robot feature's failure modes into nominal, boundary, degraded, adversarial, and recovery scenarios whose manifests, acceptance thresholds, forbidden events, and evidence survive design and release review.

Relevant target roles

Robotics Deployment, Integration & Validation Engineer
Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR
Robot Learning Deployment / Physical AI Integration Engineer

Chapter 21 interview drill

Interview questions: Hazard analysis, safety cases, scenario design, and acceptance criteria

Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.

Primary interview scenario

Given an AMR crossing hazard, distinguish hazard from model failure, write one claim–argument–evidence chain, freeze a boundary scenario, and explain why passing it does not certify the full robot application.

Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.

Technical follow-up questions

Q1What fields make a scenario reproducible instead of anecdotal?

Model interview answer

Pinned versions, initial state, environment, goal, controlled variation, timing, expected behavior, thresholds, forbidden events, evidence, repetitions, and reset procedure.

Q2Can a safe abort pass a safety-oriented scenario while failing the task?

Model interview answer

Yes. The containment expectation may pass, while business completion fails; both outcomes must remain visible.

Q3Why is the Day 141 stopping boundary insufficient for a real safety claim?

Model interview answer

It uses simplified synthetic assumptions and omits measured hardware variation, sensing coverage, environment, people, application hazards, and applicable safety requirements.