A robot policy runtime safety shield checks a proposed command against explicit state and action constraints before the actuator receives it. The shield can permit the action, replace it with a nearby admissible command or enter a tested fallback when no safe correction is available before the deadline.
The shield solves a different problem from policy uncertainty. An uncertainty module estimates what the model may not know, while a shield enforces an operational constraint under its state estimate and dynamics assumptions. Confidence alone does not define a safe set.
Use this guide with the policy-abstention guide and Physical AI safety-layers guide. A software shield supplements rather than replaces independent protective functions and system-level risk assessment.
Define an executable constraint set
Translate hazards into quantities available at runtime: joint and actuator limits, speed and force bounds, minimum distance, workspace boundaries, stability margin, payload condition, forbidden contact and human-zone rules. Each constraint needs units, frame, update rate and a conservative tolerance.
A hazard list is not executable until the controller can evaluate it from observed state. Mark constraints that depend on unavailable or stale signals and route those conditions to a fallback.
.jpg){kind=link}
Place the shield in the command path
The actual path should be policy output, unit and frame validation, state freshness check, constraint evaluation, permitted or corrected command, actuator interface and intervention log. Test that bypass, malformed input and process failure cannot send unchecked commands.
For people or high-consequence machinery, keep an independent stop or protective path capable of acting when the learned policy or shield process stalls.
| Shield method | Decision basis | Strength | Primary limit |
|---|---|---|---|
| Hard rule | Current threshold | Transparent and fast | Can chatter at boundary |
| Constraint projection | Nearest admissible action | Small correction | May miss future risk |
| Control barrier function | Safe-set condition | Continuous constraint | Model and feasibility |
| Predictive filter | Future trajectory | Accounts for stopping path | Compute and model error |
| Fallback state machine | Recovery sequence | Operational clarity | State-specific design |
Validate state age and uncertainty
A mathematically safe action can be unsafe for the current robot if the state estimate is old, misregistered or overconfident. Pass timestamps, covariance or conservative error bounds and sensor-health flags into the constraint calculation.
Tighten distance, speed or force margins as uncertainty or latency grows. Stop or degrade when freshness limits are exceeded rather than evaluating the last known state as current.
Use hard rules where the boundary is clear
Hard bounds work well for absolute joint, voltage, velocity or workspace limits that can be checked directly. Add hysteresis and rate limits around boundaries to prevent rapid accept-reject oscillation.
Test equality, numerical tolerance, missing values and simultaneous violations. The rejection response must be physically appropriate; replacing every invalid command with zero can drop a payload or destabilize a legged robot.
Project actions only inside a justified set
Constraint projection searches for an admissible command near the policy proposal. Define the distance metric in task-relevant units and preserve priorities, because a small vector-space change may be a large end-effector or contact change.
Log original command, active constraints, corrected command and solver status. If no feasible correction is found, transition to a tested fallback rather than emitting the last iterate.
Apply control barrier functions with model limits
A control barrier function represents a safe set and constrains control so the system remains within it under stated dynamics assumptions. A quadratic program can choose an action close to the policy command while satisfying the barrier condition.
The safe learning with control barrier functions paper and shielding paper describe research approaches in their evaluated settings. Real robots still require feasibility, discretization, actuator saturation, model-error and solver-time validation.
Use predictive filters for stopping distance
Current-state checks can approve an action that leaves no safe future braking trajectory. A predictive filter simulates candidate motion over a horizon and verifies that it can remain constrained or reach a terminal safe set.
The predictive safety-filter paper presents a model-based formulation. Choose horizon and model conservatism from speed, delay and braking physics, then test robustness to model mismatch.
Design fallback as a recoverable sequence
Fallback is not one universal stop command. Depending on contact, payload, balance and terrain, the robot may need controlled braking, hold, retract, place, safe pose, power isolation or human takeover.
Specify entry, completion, timeout and escalation for each state. Repeated violation should not create an infinite retry loop; move to a stable condition that requires an explicit recovery decision.
Keep protection independent of policy learning
Shield interventions can become useful training examples, but learning must not silently weaken the protective boundary. Version constraint logic separately and require the same independent safety review for any threshold or dynamics-model change.
A policy that constantly relies on correction may be mismatched to the task. Train on intervention context only after preserving why the original action was blocked and what outcome followed.
Measure worst-case runtime and timeout behavior
A control loop needs a guaranteed response before its deadline, not only good average latency. Measure sensor acquisition, state estimation, collision queries, solver, command transmission and scheduling at high percentiles under CPU, memory and network stress.
Define fail-safe behavior for timeout, infeasible, numerical error and stale input. Exercise these paths through fault injection and verify that the independent stop remains available.
Evaluate intervention without inflating success
Report constraint violations, minimum margin, intervention rate, correction magnitude, false interventions, missed hazards, fallback completion, task success and cycle time. A prevented unsafe action is protection evidence, not a completed task.
High intervention can mean good hazard capture, overly conservative rules, bad state estimation or a poor policy. Use the robot VLA evaluation guide to separate autonomous policy quality, shield contribution and assisted outcome.
| Verification layer | Measure | Fault injection | Pass evidence |
|---|---|---|---|
| Constraint | Minimum margin | Boundary and model error | No violation |
| Timing | Worst-case latency | Load and network delay | Deadline met or fallback |
| Solver | Status and feasibility | Timeout and NaN | Safe escalation |
| Intervention | Rate and correction | Near-boundary commands | Expected response |
| Recovery | Fallback completion | Payload and contact cases | Stable end state |
Release a shield-policy compatibility contract
Package constraint version, frames, units, state-validity limits, dynamics assumptions, solver settings, deadline, fallback machine, independent-stop interface, policy and robot identifiers, calibration and audit schema. Replay the exact bundle before enabling motion.
Close release review with the following checks.
- Convert hazards into runtime-checkable constraints.
- Reject stale or uncertain state conservatively.
- Test correction, infeasibility and timeout paths.
- Verify a recoverable fallback and independent stop.
- Report interventions separately from task success.
Frequently asked questions
Does a safety shield make a learned policy safe?
No. It constrains specified actions under assumptions; it does not cover unknown hazards or certify the whole system.
Is policy uncertainty the same as a safety shield?
No. Uncertainty estimates model doubt, while a shield enforces explicit operational constraints.
Should every rejected command become zero velocity?
No. The safe fallback depends on payload, contact, balance, terrain and actuator behavior.
Where should the shield run?
In the verified command path close enough to actuators to enforce deadlines, with an independent protective path where required.
Does a high intervention rate prove the shield works well?
Not alone; it may reflect conservative rules, stale state, false positives or a policy poorly matched to the constraints.
Executable-Constraint and Fallback Boundary
A runtime shield is an executable constraint and fallback layer. Its claims are limited by sensing, dynamics assumptions, timing, constraint coverage and independent protective design.