Chapter 17 · Evaluation, safety, and deployment

§17.6 Summary

0:00/10:05
AI-narrated by Orpheus

Chapter 16 got a policy working in the lab. Chapter 17 was about the distance between working and deployable, which is larger than a demo ever lets on and is measured almost entirely in failures rather than successes. The chapter’s spine is a single claim with an uncomfortable corollary. The claim: safety is not a property a learned policy has, it is a layer you build around one, out of code whose worst case you can state. The corollary, which §17.5 refused to soften: those layers reduce risk and none of them certifies the policy safe, so a deployed foundation-model robot is a managed risk watched closely, not a guarantee signed off. Everything between §17.1 and §17.4 is the machinery of managing that risk well; §17.5 is the honesty about what the machinery cannot do.

The ideas worth carrying forward

Safety is a layer, not a property, because you cannot bound the tail of a learned policy by training it. §17.1 is the chapter in one line. A VLA is an imitation learner with no value function and no guarantee about the motion it emits, so “we trained it to be safe” shifts the average and says nothing about the 5% where safety actually lives. Two policies with identical success rates can be a productivity tool and a recall notice, differing only in whether they fail by dropping the object or by closing on a hand. The response is a layer of non-learned checks, force and workspace and velocity limits, collision-checked replanning, compliant impedance control underneath, whose worst-case behavior you can write on a whiteboard precisely because the network’s you cannot. Defense in depth stacks several such layers so a hazard has to pass all of them, and even then it reduces risk rather than proving its absence.

A runtime monitor is a shield of cheap predicates, and it earns its place on the failures your evaluation could not enumerate. §17.2 built the layer. A shield sits between the policy and the actuators, evaluates a list of predicates every cycle, the same predicate drills you first wrote in §3.x, and substitutes a defined safe action when one fails. It catches the silent bugs from §2.4 without diagnosing them, because a wrong unnorm_key produces oversized actions and a velocity ceiling stops them at the first step, and it converts the compounding drift of §6.3 into a logged, loud intervention. The predicates are cheap on purpose so they fit the §14.4 latency budget on the fast clock; a VLM-as-monitor like Code-as-Monitor (Zhou et al., 2025) adds semantic checks the predicates cannot express but reintroduces the opacity of the thing it watches, so it belongs on top of the cheap shield, never in place of it.

Hardware A/B that does not lie to you interleaves, pairs, blinds, and tests the difference rather than two intervals. §17.3 turned §15.5’s single-policy protocol into a comparison. A day-over-day test measures the day; interleaving A and B trial by trial cancels the drift, pairing on shared initial states cancels the initial-condition variance, and blinding the scorer cancels the human bias. The statistic is the difference itself, and with paired trials only the discordant pairs carry information, which a McNemar-style test uses to beat comparing two overlapping marginal intervals, the §15.x trap. Fix the sample size in advance so peeking cannot inflate your false positives, and never drop the safety column, because a B that lifts the mean while moving its failures toward the dangerous end has been shown to be a worse risk, not a better policy.

Production is watching, not shipping, and the expensive failures are the ones that do not crash. §17.4 built the operational stack. Log every run as a full episode in the §15.1 format, including the model version and the metadata §2.4 said travels silently, so an incident is reconstructable and the log doubles as training data. Alert on leading indicators, a rising shield-intervention rate, action-statistics drift, creeping time-to-completion, rather than on crashes that fire too late, with thresholds tiered from a soft notify to a hard stop that beats the damage. Version every policy so rollback is possible, define the rollback triggers before deployment rather than during the incident, and recognize that the runs where the policy is weakest are the most valuable data you own, which is how deployment, evaluation, and data collection collapse into one loop.

Nobody can currently certify a foundation-model robot safe, and the honest posture is managed risk plus relentless measurement. §17.5 was the chapter’s hard truth. A symbolic planner could prove properties inside its world model; a VLA offers no such proof, and formal verification does not scale to a 7B network over the unbounded space of images and instructions. The whole-body models made it worse by folding the one certifiable-by-reading layer, hand-coded balance, into the opaque policy. And the policy has an attack surface the success-rate benchmarks never touch: adversarial patches that hijack VLA reasoning and transfer black-box across architectures (TRAP, VLA-Hijack), fragility to ordinary sensor perturbation like fog, and the beginnings of diagnostic safety benchmarks trying to measure any of it. The three defensible moves are to keep the non-learned layers load-bearing, constrain the operating domain so you certify the environment even when you cannot certify the policy, and keep measuring forever, because measurement is the substitute for a proof you cannot construct.

What you should be able to do now

Four things, matching the chapter’s objectives.

You should be able to wrap a VLA in a runtime safety layer. Given a policy and a robot, you can specify the force limits, workspace bounds, velocity ceilings, and collision-checked replanning that make a shield, implement it as cheap predicates that run inside the control loop, and define the safe fallback action the shield substitutes on a violation. You know why the layer must not be learned and why compliance belongs underneath it.

You should be able to set up an A/B evaluation that does not lie to you. You can interleave and pair trials, blind the scorer, test the difference with a paired statistic instead of two marginal intervals, pre-register the sample size to defeat peeking, and carry a safety column so a tail regression cannot hide behind a better mean. You know when to move the comparison into shadow mode or a canary slice.

You should be able to decide what to log, alert on, and roll back. You can design a production log that records the whole episode plus the model version and the silent-bug metadata, choose leading indicators to alert on with tiered thresholds, and write rollback triggers in advance that beat the damage. You understand why the logs close the failure-mining loop back into fine-tuning.

You should be able to articulate the residual risks honestly. You can explain why a learned policy cannot be formally verified, name the adversarial and natural-perturbation attack surfaces that task-success evaluation misses, and state plainly what managed risk buys and what it does not, which is the difference between an honest deployment and an oversold one.

Where the chapter has set up the rest of the book

Chapter 17 hands one clean thread to Chapter 18. The residual risks §17.5 named are not closed problems with known answers; they are open problems, and several of §18’s threads are the field’s attempts to reduce them. Reasoning-plus-action (§18.4) is in part a bet that a model which exposes its intermediate reasoning is more analyzable, and therefore closer to something you could eventually monitor or certify, than one that emits actions from a single opaque pass. Cross-embodiment generalization (§18.1) carries a safety cost the chapter only gestured at: a policy transferred to a body it was not validated on inherits none of that body’s safety testing, so the very portability §14 celebrated is a certification liability §18 has to weigh.

The chapter also closes a loop the whole book has been drawing. The compounding-error problem named in §1.1, developed in §6.3, and deferred through Part 4 finally gets its deployment-time answer here: you cannot train it away, so you monitor for the drift and stop safely when it appears. The silent failures from §2.4 get their production answer in §17.4’s logging. The evaluation discipline from Chapter 15 becomes a safety instrument in §17.3. Chapter 17 is where the book’s threads about what these models cannot do stop being cautions and become engineering.

What the chapter has not covered

Two gaps worth naming. The chapter treated safety mainly as physical safety, force, collision, workspace, and said little about the higher-level question of a policy that does the wrong task competently and safely, following a misinterpreted instruction to completion without ever tripping a force limit. That is an alignment problem more than a control problem, and the runtime-authorization line (§17.2) is only starting to formalize it. The chapter also stayed on single-robot deployment; it did not develop the safety of multi-robot systems like §14.6’s leaderless coordination, where the hazard is emergent from the interaction rather than present in any one policy, and where the monitoring and rollback story is genuinely unsettled.

Chapter 17’s contribution to the book’s argument is to convert the recurring caution, that these models are more capable than they are analyzable, into a working deployment discipline and an honest boundary. You can build the layers, run the comparisons, watch the logs, and reduce the risk to something a serious operator can carry. You cannot prove the risk is gone, and the chapter’s refusal to pretend otherwise is the most important thing it teaches. §17.x makes the layer concrete: you will wrap a force-and-workspace safety shield around a fine-tuned OpenVLA and induce three failures on purpose to watch it catch each one, followed by the chapter’s full reading list.

This section has been read times.

References

  1. Survey (2026). Safety of Vision-Language-Action Models, A Survey. arXiv:2604.23775.
  2. Zhou, Q. et al. (2025). Code-as-Monitor, Constraint-Aware Visual Programming for Reactive and Proactive Robotic Failure Detection. CVPR 2025.
  3. Atreya, P., Pertsch, K. et al. (2025). RoboArena, Distributed Real-World Evaluation of Generalist Robot Policies.
  4. Alshiekh, M. et al. (2018). Safe Reinforcement Learning via Shielding. AAAI.