§17.5 What we still cannot certify

The guarantee you gave up

Chapter 4 is the contrast that makes this concrete. A symbolic planner (§4.1) operated on an explicit world model, and inside that model it could prove things: that the plan achieved the goal, that it respected the preconditions, that a new constraint added to the problem file would be honored. §4.4 named the trade you make leaving that world for a learned one, and this is where the bill comes due. A VLA offers no such proof. There is no world model to check the plan against, no precondition it verifiably respects, and no property you can establish by inspection, because the thing producing the action is an opaque forward pass over a 7B network. §9.1 made the same point from the world-model side: a system that emits actions from an inscrutable function gives you no handle to ask what future it predicted or whether that future was safe.

Formal verification, the tool that certifies safety-critical software in avionics and medical devices, does not scale here, and it is worth being precise about why rather than hand-waving. Verification proves a property holds over all inputs. A VLA’s input is every image the camera might produce crossed with every instruction a person might phrase, an unbounded space, and the function mapping that space to actions is a deep network with hundreds of layers and no analyzable structure. There is no proof that the network never exceeds a force, never leaves a workspace, never closes on a hand, because constructing such a proof would mean bounding the behavior of the whole network over the whole input space, which no current method can do. This is exactly why §17.1 put the guarantees in the non-learned layer: you certify the force limit because it is ten lines of code, and you cannot certify the policy because it is not.

The whole-body models sharpened this, as §14.5 through §14.7 traced. When the balance controller was hand-written C++, an engineer could read it and argue it would not step wrong; certification-by-inspection was at least possible for that layer. Helix-02’s System 0 replaced it with a learned controller, and Gemini Robotics 2 folded balance into the manipulation policy itself, so the one part of the humanoid stack you used to be able to certify by reading is now as opaque as the rest. The trend is toward more capability and less analyzability at the same time, which is the uncomfortable direction for anyone who has to sign off that a robot is safe.

The adversarial surface

§16.4 gave you three failure modes a policy hits on its own. There is a fourth, and it is not accidental: the failures an attacker induces on purpose. §13.5 flagged the mechanism, that a continuous action head is a smooth, differentiable surface, and a smooth surface is one an optimizer can push on. The result is a research literature, growing fast through 2026, that this chapter has to represent honestly because it bears directly on what you can and cannot certify.

The canonical attack is the adversarial patch. TRAP (arXiv:2603.23117) showed that a printed pattern placed in the scene can hijack a VLA’s chain-of-thought reasoning, steering the action the model produces, without touching the model or its inputs digitally, just by putting a crafted object in the camera’s view. The property that makes this more than a lab curiosity is transferability. VLA-Hijack (arXiv:2605.28083) demonstrated patch attacks that transfer black-box across architectures, hijacking OpenVLA, UniVLA, and CronusVLA with a single pattern and no access to the target’s weights, which means an attacker does not need your model to attack it, only one like it. Later work extended the threat to the partially observable case (arXiv:2606.03556), where the patch does not even have to stay in full view to work. For a deployed robot, a patch attack is a physical, reproducible way to make a policy misbehave that the success-rate evaluation of Chapter 15 would never surface, because the benchmark scene contains no adversary.

The fragility is not only adversarial. Lost in Fog (arXiv:2605.21446) showed that ordinary sensor perturbations, fog on a camera in a driving VLA, degrade the model’s reasoning sharply, which means the same brittleness an attacker exploits also shows up under natural distribution shift that no one engineered. That is the more sobering result in some ways, because you can try to keep adversaries out of a workcell, and you cannot keep weather off a camera. The community has started to organize around measuring this: the CVPR 2026 AdvML workshop ran a challenge on adversarial attacks against driving VLAs (arXiv:2607.11560), and ForesightSafety-VLA (arXiv:2606.27079) is an early diagnostic benchmark that tries to score a policy’s safety failures rather than its task successes. The Safety of VLA Models survey (arXiv:2604.23775) is the current map of the whole area, and the reason to cite a survey here rather than pile up primaries is that the field is moving fast enough that any single result is provisional; the survey is where you go to see the shape.

The honest posture

Put the two halves together and the conclusion is uncomfortable but clear. You cannot verify the policy, and the policy has an attack surface, both adversarial and natural, that your task-success evaluation does not touch. So certification in the strong sense, a proof that the robot is safe, is not available, and any vendor claiming it should be met with the question of what exactly was proven and over what input space. What is available is managed risk, and the management has three moves worth naming.

Keep the non-learned layers load-bearing, and never let a learned component be the last line of defense. The force limit, the workspace bound, the compliant controller, the physical emergency stop: these are what you can reason about, so they are what stands between a hijacked or fogged-out policy and a person. A VLM monitor (§17.2) can sit on top, but the thing that actually stops the arm has to be simple enough to certify.

Constrain the operating domain, because you often can certify the environment even when you cannot certify the policy. A caged workcell with no humans inside, a speed limit low enough that the worst-case kinetic energy is survivable, a task where the failure is a dropped part rather than a crushed hand: these are choices that shrink the space of hazards to one you can actually bound. The uncomfortable corollary is that the open-ended home robot, operating near people with no cage and no speed cap, is precisely the deployment we are least able to certify, and the demos that look most impressive are often the ones running in the domain where the residual risk is highest.

Keep measuring, forever, because measurement is the only handle you have when proof is unavailable. The logging, alerting, and rollback of §17.4 are not just operations hygiene; on an uncertifiable system they are the substitute for a safety proof, the running evidence that the behavior has stayed inside the envelope you tested. A foundation-model robot is safe the way a bridge with sensors on it is safe: not because you proved it will never fail, but because you are watching it closely enough to catch the failure before it hurts anyone, and honest enough to admit that is what you are doing.

That admission is where the chapter has to end its argument, and it is the right note to hand to Chapter 18. The residual risks here, the ones no layer certifies away, are not a footnote to an otherwise solved deployment story; they are open problems, and the reasoning-plus-action and cross-embodiment threads §18 takes up are in part the field’s attempt to build models whose behavior is analyzable enough to eventually close some of this gap. §17.6 gathers what you can now do, and it is a real and useful list, provided you hold it next to an honest account of what you still cannot.