Chapter 21

Bound embodied agents with safety and release evidence

Turn the language-to-skill agent from Weeks 18–20 into a system whose authority, hazards, attacks, recovery, and release claims are inspectable. This chapter keeps probabilistic semantic planning separate from deterministic action admission and embodiment-specific control; builds a fail-closed validator; maps cybersecurity, prompt injection, and physical hazards across distinct trust boundaries; freezes scenarios and acceptance criteria before testing; reports autonomy, intervention, abort, and unsafe outcomes without hiding them in one score; and produces a trace-backed 30-scenario evaluation gate. The exercises use paper, recorded traces, or simulation. They teach practical engineering evidence, not legal advice, a safety certification, or permission to operate a real robot.

Before you start

Complete the Week 18 model-to-action contracts, Week 19 adaptation evaluation, and Week 20 typed-skill, world-state, monitoring, retry, and handoff work; this week audits those boundaries rather than rebuilding them.
Bring a disconnected simulator or a folder of synthetic traces for one language-conditioned robot task, plus the exact action schema, units, coordinate frames, timestamps, limits, success predicate, and failure codes used by that task.
Be able to distinguish a semantic goal, typed skill request, validated controller command, controller feedback, perceived physical state, and terminal task result; none of those records substitutes for another.
Keep powered motion disabled. Real deployment requires application-specific hazard analysis, reviewed safeguards, competent integration, and applicable current standards; a classroom validator, prompt filter, or simulation result is not a safety-rated function.

By the end

Draw an authority boundary in which semantic models may propose goals or bounded skills while independent validators, controllers, watchdogs, protective functions, and humans decide what may execute.
Implement or specify a staged action-admission contract that checks provenance, schema, freshness, grounding, state, workspace, kinematics, collision, velocity, force, timing, and command identity before publication.
Threat-model the model, retrieval inputs, scene text, ROS 2 graph, operator path, credentials, controller gateway, logs, and update supply chain without confusing communication security with semantic or physical safety.
Convert a hazard into predeclared scenarios with initial state, variation, trigger, expected response, quantitative thresholds, evidence, reset procedure, and an explicit statement of what the test does not establish.
Report mutually exclusive terminal outcomes and separate event counters for intervention, guard rejection, unsafe proposal, latency, recovery, and unsafe physical behavior with visible denominators.
Run controlled adversarial scenes that test ambiguity, stale state, misleading environmental text, occlusion, blocked motion, forged requests, and exhausted recovery while preserving independent containment.
Produce a reproducible 30-scenario evaluation package and make a narrow release, revise, or block decision whose scope, residual risks, rollback trigger, and missing real-world evidence are explicit.

The field story

Courier-17 Red-Team Gate

Courier-17 arrives from Week 20 with a typed executor and a complete delivery trace. The Red-Team Gate assumes that every boundary can fail: a planner can propose an unsafe goal, environmental text can contain hostile instructions, an authenticated sender can still request the wrong task, state can become stale, and recovery can exhaust itself. Your mission is to surround the courier with independent admission rules, hazards, scenarios, and evidence. The semantic model may recommend a skill, but deterministic validators, controllers, watchdogs, protective functions, and authorized humans retain separate authority over what can happen.

The gate is built in seven passes. You first draw the authority boundary, then validate workspace, velocity, force, freshness, and command identity. Threat analysis follows data from scene text and retrieval through SROS 2 and the controller gateway without mistaking encryption for physical safety. Human-robot interaction review probes understandable states, handoffs, operator workload, consent, and privacy. Hazards become frozen scenarios and measurable acceptance criteria. Outcomes remain mutually exclusive, while interventions, rejections, latency, recovery, and unsafe proposals retain their own denominators. Adversarial scenes probe ambiguity, injection, occlusion, and blocked motion. The week ends with thirty trace-backed scenarios and a narrow release, revise, or block verdict rather than a universal safety claim.

Why this chapter now: Week 20 proved that the courier can execute. Before that system becomes a capstone component, an authority independent of the feature path must test its attack surface, physical hazards, human interaction, privacy exposure, and failure metrics.
Ignore for now: Do not claim certification, rely on prompt filtering as a safety function, equate SROS 2 authorization with safe task meaning, or energize hardware for adversarial tests.
This unlocks: A bounded embodied-agent release gate whose contracts can inform Week 22 hardware requirements and later capstone acceptance evidence.
Proof you will leave with: An authority diagram naming the independent safety owner, staged validator results, threat and hazard ledgers, privacy and data-retention inventory, human-factors observations, frozen scenario definitions, raw traces, exclusive terminal labels, separate event counters, recovery budgets, adversarial outcomes, residual risks, and a scoped gate decision.

Environment contractrepository-supported Node.js 22.13.0 or newer, synthetic Courier-17 proposals, and recorded or simulated state form the baseline; powered motion, live credentials, and production ROS domains remain excluded.

Compatibility boundary: The starter checks a small application policy only. Real SROS 2, controller, watchdog, force, workspace, protective-function, HRI, or privacy claims require the pinned ROS distribution, robot, site, security artifacts, representative participants, data governance, qualified integration, and independent validation.
Smoke check: Run node week-21-courier-red-team.mjs; confirm the bounded proposal is admitted, the planted injected environmental instruction is rejected, and unsafe execution remains zero.
Contract reviewed: 2026-07-25
Runtime evidence: The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
Drift risk: high

Today in the field story

One problem, then the next

The Red-Team Gate begins by tracing Courier-17 from language request to measured outcome. You mark where semantic planning ends, where typed skills begin, where action admission runs, and where the controller, watchdog, protective functions, and human authority remain independent. A named safety owner outside the feature delivery path controls gate acceptance and unresolved-risk signoff. A plausible plan is never a validated command, and a validated command is not proof of safe physical behavior. No probabilistic component may bypass deterministic checks appropriate to its embodiment.

Why now: Authority must be explicit before individual limits or attacks can be evaluated.
Ignore today: Ignore model cleverness and performance optimization.
Unlocks next: A reviewable trust and control boundary for every later scenario.

Understand

Build the physical picture first

The semantic planner writes a requested destination; independent gates decide whether any motion may begin or continue.

A semantic planner answers a flexible question: what task or skill appears useful given language, perception, and remembered context? A safety-related control boundary answers a narrower physical question: may this exact, typed, time-bounded command execute on this embodiment in the measured state? Keep those questions in different components, with different inputs, owners, failure behavior, and evidence. A fluent plan can be useful while its next action is stale, unreachable, unauthorized, or physically hazardous.

The planner should emit a proposal such as approach(entity_id=box-17, stand_off=0.8 m) rather than motor effort or unrestricted velocity. A deterministic skill gateway resolves the entity, checks the skill contract, and creates a body-specific proposal. Independent command validation then checks identity, freshness, mode, workspace, kinematics, collision, speed, force, and timing before a controller accepts anything. Controller feedback and fresh perception finally decide whether the intended effect occurred; planner confidence never closes that evidence chain.

Use defense in depth because each layer has a different failure mode. Semantic safeguards may reject an obviously dangerous request, but they can misunderstand a novel scene or adversarial input. Application validators can enforce reviewed limits, yet ordinary software and configuration can still fail. Embodiment-specific protective functions, physical guarding, emergency stopping, and human procedures address other hazards. Do not call a classroom Python check, an LLM self-critique, or a successful simulation run safety-rated.

A stopping-distance calculation is one input to a boundary, not a complete safety distance. The idealized expression d_stop = v × t_react + v²/(2a) omits sensing uncertainty, controller and brake variation, floor conditions, payload, obstacle motion, geometry, localization error, and standards-required factors. Use measured worst cases and an explicit margin for this exercise, then label the result a teaching envelope whose real-world adequacy remains unverified.

Words you need

Name each idea precisely

Semantic planner: A probabilistic component that interprets goals and state to propose an ordered task or bounded skill call without owning actuator permission.
Physical example:
A planner proposes inspect shelf B, then bring tote 12; a separate gateway decides whether each navigation and manipulation skill is currently admissible.
Safety envelope: A declared set of state and command conditions inside which an operation may be considered for execution, with behavior defined at and beyond every boundary.
Physical example:
An AMR proposal remains eligible only below a configured speed and outside a protected separation region while localization and stop monitoring remain healthy.
Independent enforcement: A control or protective decision whose operation does not depend on the semantic model agreeing that the situation is hazardous.
Physical example:
A controller rejects a trajectory crossing a protected zone even when the language model labels the route clear.
Permit decision: A fail-closed result that binds one authenticated proposal, one measured state, one ruleset version, and a short validity interval to allow or reject execution.
Physical example:
Permit p-204 allows only command cmd-77 for robot R3 before time 12.400 s; it cannot authorize a later or altered command.
Stopping-distance budget: A measured and conservatively bounded distance allocation for reaction and braking plus declared margins, used as one part of a larger hazard control.
Physical example:
At 1 m/s, a 0.2 s response and 2 m/s² ideal braking need 0.45 m before any uncertainty or application margin is added.

Visual model

See the relationship

Swipe the technical canvas horizontally on a small screen.

Day 141 · Failure case — A command or hazard exceeds the validated safe region. Measured anchor: -20 cm margin.

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.

For speed $v$ , reaction delay $t_r$ , and braking deceleration magnitude $a$ , an idealized stopping distance is

d_{\mathrm{stop}}=vt_r+\frac{v^2}{2a}.

With $v=1\,\mathrm{m/s}$ , $t_r=0.2\,\mathrm{s}$ , and $a=2\,\mathrm{m/s^2}$ , $d_{\mathrm{stop}}=0.45\,\mathrm{m}$ before safety margin.

Separate an approach request from its motion permit

A simulated mobile robot receives approach pallet P7. Its proposed speed is 1.0 m/s, worst measured reaction delay for the exercise is 0.20 s, idealized braking deceleration is 2.0 m/s², declared teaching margin is 0.15 m, and measured obstacle clearance is 0.52 m.

Represent the semantic output as approach(entity=P7, stand_off=0.8 m) with request identity, source, issue time, and no direct wheel command.
Resolve P7 to a fresh tracked entity and let the deterministic navigation skill propose a path and a maximum speed of 1.0 m/s for robot R3.
Compute reaction travel as 1.0 m/s × 0.20 s = 0.20 m and ideal braking travel as 1.0²/(2 × 2.0) = 0.25 m.
Add those terms to obtain 0.45 m, then add the declared 0.15 m teaching margin to form a 0.60 m minimum boundary for this frozen scenario.
Compare the measured 0.52 m clearance with 0.60 m. The permit decision is reject, even though the route is semantically correct and the controller could parse the request.
Record proposal, measurements, ruleset version, calculation, rejection code, zero published motion commands, and the planner's allowed next choices: wait, re-observe, select another route, or hand off.

Result

The useful plan remains visible, but the exact motion is rejected because 0.52 m < 0.60 m; the trace proves containment without claiming that the simplified boundary is sufficient for real deployment.

What this proves

A planner can decide what is desirable while an independent, state-bound gate decides what is physically admissible now.

Physical examples

Where this appears in real life

AMR approaches a blind cross-aisle

A planner chooses the shortest route to a dock, but a person may emerge from a blind aisle while the robot is moving at its requested speed.

Look for:

Route usefulness belongs to semantic planning; measured protective-field state, speed-dependent separation, braking behavior, and stop authority remain outside the planner and can reject or interrupt the route.

Cobot moves a heavy tote

The task description calls a tote liftable, but the current tool, payload estimate, joint pose, and nearby human make the proposed pick inadmissible.

Look for:

The model's object judgment is only an input; payload, force, workspace, protective state, and controller limits independently determine whether the exact motion can proceed.

Hands-on exercise

Make the idea observable

Use a paper robot and ruler or a disconnected 2D simulator. Do not connect the exercise validator to a real controller or reuse its numbers as certified limits.

Draw two lanes: semantic goal and skill proposal above, measured state and command enforcement below; name the owner and output schema of every box.
Create three proposal cards: valid approach, request beyond the workspace, and valid route with insufficient clearance; give each a unique ID and expiry.
Choose exercise-only speed, reaction, braking, and margin values, record their source as synthetic, and calculate a boundary for every card.
Process the cards through grounding, state freshness, action validation, permit, controller acknowledgment, feedback, and terminal predicate in that order.
Remove planner output, corrupt one measurement, and delay one permit past expiry; require the lower lane to reject or stop without asking the planner to judge itself.
Save a single-page diagram and three traces that show both allowed planning alternatives and the independent reason no rejected command reached execution.

Observe

The most important arrows run from measurements and protective state to enforcement, not from model confidence to permission; missing or stale evidence converts to rejection.

Done when

Every actuator-facing path crosses the named enforcement boundary, all three injected defects fail closed, and the artifact labels its calculations simulation-only and not safety certification.

Build today

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

Evidence to save

DONE when the learning log explains “Separate semantic planning from safety-critical control” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Using the same foundation model to propose an action and certify that the action is safe.

Better

Treat model safety reasoning as one fallible semantic filter; enforce reviewed physical conditions in separate deterministic and embodiment-specific layers with independent evidence.

Wrong

Calling a velocity clamp or collision check a complete safety system.

Better

Name the narrow property each check enforces and retain application hazard analysis, protective functions, physical safeguards, procedures, and competent review outside that claim.

Wrong

Treating an accepted controller goal as proof that the task completed safely.

Better

Preserve controller feedback, fresh robot and object state, forbidden-event checks, and the predeclared terminal predicate after acceptance.

Job connection

How this becomes employable evidence

Review a language-to-navigation feature by separating goal reasoning, typed skill generation, application validation, controller execution, independent protective functions, and measured completion, then demonstrate that corrupt model output cannot bypass the lower boundary.

Relevant target roles

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

Chapter 21 interview drill

Interview questions: Separate semantic planning from safety-critical control

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

Whiteboard an embodied agent that approaches a pallet near people. Show exactly where semantic reasoning ends, how one command receives a short-lived permit, which failures remain outside the model, and what evidence proves rejection or physical completion.

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

Q1Why may the semantic planner remain correct when the next motion is rejected?

Model interview answer

The goal or skill can still be useful, but current identity, freshness, workspace, collision, speed, force, timing, or protective state can make this exact execution inadmissible.

Q2What is the exercise boundary for 1.0 m/s, 0.20 s reaction, 2.0 m/s² braking, and 0.15 m margin?

Model interview answer

Reaction travel is 0.20 m, ideal braking travel is 0.25 m, and the declared teaching boundary is 0.60 m after margin.

Q3What does the stopping-distance example not establish?

Model interview answer

It does not establish a real safety distance, certified performance, or deployment permission because uncertainty, hardware, environment, application hazards, and applicable standards remain unverified.

Chapter references

Google DeepMind — Responsibly advancing AI and roboticsPrimary embodied-AI safety source for layered semantic, physical, and operational safeguards; lower-level safety mechanisms; vulnerability assessment; adversarial evaluation; and the explicit warning that research behavior is not a guaranteed safety-rated system.
NIST AI 600-1 — Generative AI ProfileOfficial voluntary risk-management guidance for documented test and evaluation, pre-deployment measurement, incident response, fallback ownership, lifecycle monitoring, and evidence that remains scoped to the evaluated system and context.
NIST AI 100-2 E2025 — Adversarial Machine LearningOfficial adversarial-ML taxonomy for attacker goals, capabilities, prompt injection and agent hijacking risks, lifecycle attack surfaces, defense in depth, and the limitations of proposed mitigations rather than claims of a perfect prompt filter.
ROS 2 Design — DDS-Security integrationPrimary ROS 2 design reference for SROS 2 authentication, access control, cryptography, enclave artifacts, strict versus permissive startup, and the important boundary that transport authorization does not validate task meaning or physical safety.
OSHA Technical Manual — Industrial robot systems and applicationsOfficial practical context for whole-application hazard analysis, safeguards, integration and site acceptance, periodic verification, stopping performance, and non-routine hazards; use as orientation only, not as a substitute for current applicable standards or competent safety review.