Chapter 21 · Bound embodied agents with safety and release evidence

Today in the field story

One problem, then the next

Courier-17 submits a well-formed placement request, and the action validator processes it as a staged border inspection. Provenance, schema, entity freshness, scene version, frame, kinematic feasibility, workspace, collision, velocity, force, timing, and command identity each produce an explicit result. A single rejection prevents publication and remains visible in the trace. These software checks reduce application risk but do not replace independently engineered protective functions, stopping systems, or qualified validation on a physical platform.

Why now: Typed skills still need embodiment-specific admission before execution.
Ignore today: Do not treat numeric clipping or a software check as a safety rating.
Unlocks next: Fail-closed command admission with attributable rejection reasons.

Understand

Build the physical picture first

An action validator is a border checkpoint that inspects one complete command contract before any controller receives it.

Validate a proposal as a whole, not as a loose array of plausible numbers. Bind request ID, authenticated source, robot and tool identity, model and processor version, action mode, dimensions, units, coordinate frame, source timestamps, intended start, expiry, and current-state version before checking geometry. Without that provenance, a numerically valid vector may belong to another robot, another coordinate frame, an older scene, or a decoder with different normalization.

Order checks so inexpensive structural failures stop early and every rejection has one observable owner. A practical pipeline can verify authorization and schema, finite values and shape, freshness and sequence, grounding and skill preconditions, inverse decoding, workspace and joint feasibility, per-step speed and acceleration, predicted collision and force constraints, then final expiry immediately before publication. A downstream controller still performs its own checks; passing an application validator does not transfer ownership of all physical risk to that validator.

Rejecting and clipping are different product decisions. Clipping 1.4 m/s to 0.5 m/s prevents that one speed excess, but it silently changes timing and may make a crossing, grasp, or synchronized handoff wrong. Projecting an unreachable pose to the nearest reachable point can change which object is touched. Only transform a proposal when the skill contract explicitly defines the transformation, the changed meaning remains acceptable, and the trace preserves both requested and admitted values; otherwise reject and replan.

Fail closed on missing, stale, contradictory, or unverifiable data. A timeout must not reuse the last permit, and a retry must revalidate against fresh state rather than replaying a previously valid command. Cache only immutable artifacts such as a signed ruleset or geometry version, then include their hashes or versions in the decision. The useful output is not just false; it is a stable rejection code, failed field, measured value, threshold, policy version, timestamp, and confirmation that no later command was published.

Words you need

Name each idea precisely

Action proposal: A typed candidate command that contains enough physical meaning to validate but has not yet received execution authority.
Physical example:
A four-pose gripper-frame trajectory includes metres, radians, timestamps, robot ID, and collision geometry version before the gateway considers it.
Validation pipeline: An ordered sequence of independent checks that converts one complete proposal into a short-lived allow decision or a precise rejection.
Physical example:
A mobile command passes source, schema, freshness, localization, route, speed, separation, and expiry checks before publication.
Freshness budget: The maximum allowed age from the physical observation on which a proposal depends to the last decision before execution.
Physical example:
A grasp generated in 40 ms is rejected because its camera frame was already 300 ms old and the tote was moving.
Fail closed: Behavior in which absence, corruption, timeout, ambiguity, or validation failure prevents command admission instead of falling back to motion.
Physical example:
When localization health disappears, the base receives no new navigation command rather than reusing the last pose estimate.
Explicit clipping contract: A reviewed rule that identifies which field may be bounded, how the changed command is interpreted, and when clipping must instead become rejection.
Physical example:
Teleoperation may scale joystick speed while preserving direction, but a calibrated insertion depth is rejected rather than shortened silently.
Command provenance: The identity, source, versions, state snapshot, transformation history, and decision record that explain exactly how an actuator-facing command was created.
Physical example:
Command c-91 links operator request r-18, model m-4, decoder d-7, map map-12, validator v-3, and state sequence 884.

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.

A bounded velocity command can be written as

v_{\mathrm{cmd}}=\operatorname{clip}(v_{\mathrm{req}},-v_{\max},v_{\max}).

For $v_{\mathrm{req}}=1.4\,\mathrm{m/s}$ and $v_{\max}=0.5\,\mathrm{m/s}$ , $v_{\mathrm{cmd}}=0.5\,\mathrm{m/s}$ . Clipping must be explicitly permitted because it changes the request.

Audit one mixed-validity manipulation proposal

A simulator receives proposal a-142-7 for robot R3: target [0.72, 0.10, 0.20] m in base frame, speed 1.4 m/s, expected contact force 14 N, source-state age 86 ms, expiry 120 ms, workspace x range [0.25, 0.65] m, maximum speed 0.5 m/s, and force limit 20 N.

Verify the authenticated source, robot ID, tool ID, request ID, state sequence, schema version, mode, dimensions, metre units, base frame, and finite values before interpreting geometry.
Compare age 86 ms with expiry 120 ms; freshness currently passes with 34 ms remaining, but the validator must repeat expiry immediately before publication.
Compare x target 0.72 m with maximum 0.65 m; record workspace_x_high with excess 0.07 m and mark the proposal rejected.
Also compare requested speed 1.4 m/s with 0.5 m/s; record speed_high instead of hiding the second defect behind the first diagnostic.
Confirm predicted force 14 N is below the exercise limit 20 N, while stating that this does not rescue the failed workspace and speed conditions or prove actual contact safety.
Do not clip the pose or speed because this insertion skill has no clipping contract; emit one rejection containing all failed fields and verify that controller command count remains zero.

Result

The proposal is rejected with two attributable failures despite fresh state and an in-range predicted force; no altered command is silently substituted.

What this proves

A validator preserves task meaning by rejecting complete, traceable proposals when any required condition is missing or outside its declared contract.

Physical examples

Where this appears in real life

Arm target beyond the cell boundary

A language-conditioned policy proposes a plausible tool pose whose x coordinate lies seven centimetres beyond the reviewed simulated workspace.

Look for:

A valid tensor and confident instruction do not matter; the validator reports the exact axis, value, limit, frame, and proposal ID, then publishes no trajectory.

Late docking command

A dock approach was valid when planned, but network delay delivers it after another robot has reserved the shared approach lane.

Look for:

Freshness, reservation generation, intended start, and expiry are checked again at admission; replaying the once-valid permit is forbidden.

Hands-on exercise

Make the idea observable

Create a local JSON validator or spreadsheet for synthetic commands. Its output must remain disconnected from physical hardware and clearly marked as application-level training code.

Define a proposal schema containing request, robot, tool, mode, component names, units, frame, source time, start time, expiry, state generation, model, decoder, and ruleset versions.
Implement or tabulate ordered checks for authorization, schema, finite values, freshness, grounding, workspace, joints, step size, speed, acceleration, force, collision, and final expiry.
Create six fixtures: valid, wrong robot, stale state, NaN, workspace excess, and valid numbers decoded with the wrong processor version.
Return stable machine-readable codes plus field, observed value, limit or expectation, decision time, and zero-or-one publish result for each fixture.
Add an explicitly clippable teleoperation speed case and a non-clippable insertion-depth case; prove the first retains requested and admitted values while the second rejects.
Re-run the once-valid fixture after its state generation and expiry change; require revalidation and save the before-and-after trace as evidence against permit replay.

Observe

Most dangerous examples are not absurd values; they are valid-looking values with the wrong identity, version, frame, time, or task meaning.

Done when

All six fault fixtures reject with distinct evidence, the one declared clipping case records both values, stale permits cannot replay, and no exercise output is wired to an actuator.

Build today

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

Evidence to save

DONE when “Action validation, workspace, force, and velocity limits” runs from one documented command and the nominal plus boundary outputs are attached.

Common mistakes

Catch the wrong mental model

Wrong

Checking only whether every action value falls between minus one and one.

Better

Validate decoded physical meaning, identity, version, units, frame, time, state, geometry, dynamics, collision, and task-specific conditions; normalized range alone proves almost nothing.

Wrong

Silently clipping every excessive value.

Better

Clip only fields whose reviewed contract preserves acceptable meaning, and retain requested plus admitted values; reject transformations that could change the task or contact.

Wrong

Reusing a previously granted permit after delay or retry.

Better

Bind permission to one proposal and state generation with a short expiry, then revalidate against fresh state before every new publication attempt.

Job connection

How this becomes employable evidence

Build the action-admission gateway between a learned policy and ROS 2 controllers, preserving model and decoder provenance while producing stable diagnostics for stale, malformed, infeasible, colliding, and out-of-contract proposals.

Relevant target roles

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

Chapter 21 interview drill

Interview questions: Action validation, workspace, force, and velocity limits

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

Design a validator for language-conditioned arm actions. Explain check ordering, fail-closed behavior, clipping policy, permit expiry, replay prevention, diagnostic evidence, and why passing this gateway still is not a complete safety case.

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 is a finite, correctly shaped action array still only a proposal?

Model interview answer

Its robot, processor, units, frame, time, state, geometry, limits, collision status, and authority may still be wrong or missing.

Q2When is clipping preferable to rejection?

Model interview answer

Only when the skill contract explicitly allows that field to be bounded, the transformed action preserves acceptable task meaning, and both requested and admitted values are logged.

Q3Which two fields fail in the worked proposal?

Model interview answer

The x target exceeds the workspace maximum by 0.07 m, and requested speed 1.4 m/s exceeds the 0.5 m/s limit.