Adaptive Robot Safety Cases: Specifications, Monitoring, and Evidence

The short answer

A credible adaptive-robot safety case must connect a bounded claim to a specification, a control, a test, an operating record, and a change decision. A high task-success rate is not enough. A low violation rate is not enough if the robot rarely acts. A runtime monitor is not enough if it cannot observe the relevant hazard. A safe simulation result is not enough if physical failure rates do not transfer. A certificate for one configuration is not enough after behavior-changing updates.

The practical unit is not “the AI is safe.” It is a claim such as:

For this robot, tool, payload, task, workspace, speed range, software version, and access condition, the system prevents or detects a defined hazardous event with stated evidence and moves to a defined safe response.

That claim needs five linked records:

1. scope, the robot, task, people, environment, lifecycle phase, and version covered;
2. hazard and requirement, what must never happen or what order must be preserved;
3. risk control, how design, protective measures, monitoring, and procedures reduce risk;
4. verification evidence, how the requirement was tested under nominal, fault, and shifted conditions;
5. operational assurance, how incidents, interventions, drift, updates, and residual risk are monitored after release.

Our robot safety standards guide maps the application-level standards and risk-assessment foundation. This guide focuses on the additional evidence problem created by learned and changing behavior.

ManiGuard exposes the missing denominator

ManiGuard is an August 2026 research release for specification-grounded safety evaluation of robot manipulation (paper, project page). It separates task completion from compliance with a safety requirement.

The benchmark contains:

• 200 locked base tasks across six contact-rich household task families;
• one in-distribution condition and four single-axis shifts per base task, for 1,000 locked scenarios;
• safety requirements written in finite-trace linear temporal logic, or LTLf;
• runtime monitors compiled into deterministic finite automata;
• 8,000 retained safe-success demonstrations, 40 per base task;
• more than 23,000 reported evaluation rollouts across zero-shot, fine-tuned, scaling, specification-format, and physical studies.

The six families combine three skill levels with two constraint types. Spatial constraints include moving a target without knocking over surrounding objects. Temporal constraints include closing a container before transporting it or cleaning a container before pouring food into it.

This design allows four distinct outcomes:

Task outcome	Safety outcome	Meaning
Success	Safe	The goal was completed without violating the encoded requirement
Success	Violation	The goal was completed through an unsafe path
Failure	Safe	The goal was not completed, but the encoded requirement was not violated
Failure	Violation	The goal failed and the encoded requirement was violated

A final success label collapses the first two rows. A raw safety label can collapse useful safe work with inaction. A safety case needs the complete outcome matrix.

What the reported results actually show

ManiGuard evaluates three zero-shot policies and four supervised fine-tuned policy families. Each main policy evaluation covers 1,000 frozen scenarios under three policy-sampling seeds, or 3,000 rollouts per policy. The runtime monitor checks the safety specification at every simulation step but does not stop execution, so completion and violation remain independent outcomes.

The central result is not that one model is safe. It is that the choice of denominator changes the conclusion.

Successful can still mean unsafe

For the fine-tuned policies, the authors report that 6% to 21% of successful rollouts violated the encoded specification. Two policies with nearly identical task success, 31.8% and 32.0%, differed by six percentage points in overall violation rate and three points in safe-success rate.

This supports a bounded rule:

Report task success, successful-but-unsafe execution, and safe task completion separately.

It does not prove that the encoded requirements cover every hazard. A rollout labeled safe means that the selected monitor did not observe a violation of its specification.

Safe can still mean inactive

The zero-shot baselines reported raw safe rates from 77.7% to 83.3%, but task success from 0% to 1.8%. Between half and four-fifths of their apparent safety came from rollouts that never engaged a task object.

ManiGuard therefore records:

• engagement, whether the robot made whole-arm contact with a task-relevant object;
• safe given engagement, whether an engaged rollout avoided a violation;
• engaged and safe, the share of all rollouts that both engaged and remained safe;
• safe-success rate, the share that completed the task and remained safe.

This prevents a nonfunctional policy from looking safer merely because it does nothing. In a deployment, engagement may need a different definition, such as entering the work zone, issuing a motion command, applying force, carrying a payload, or taking task authority.

More safe demonstrations did not close every gap

Fine-tuning on the released suite raised average safe task completion from near zero to 7.5% through 29.8%, depending on the policy. Safe behavior conditional on engagement also improved.

The result remains limited. The authors report that 21% to 42% of engaged rollouts still violated the specification, and two of six task families remained below 2% safe success for every evaluated policy. On one contact-rich family, adding more demonstrations increased engagement and reduced conditional violation relative to zero-shot behavior, yet safe success stayed near the floor and did not improve monotonically.

The implication is not that demonstrations are useless. It is that demonstration count is not a safety-coverage measure. Data may omit near-failure states, contact transitions, alternative safe approaches, recovery paths, rare geometry, sensor faults, and combinations of conditions that matter to the requirement.

Build the safety case from claims, not model names

A useful case can be organized as a claim-evidence graph.

Claim layer	Question	Evidence expected
Intended use	What work and environment are covered?	Task definition, users, tools, payloads, layout, access, versions, exclusions
Hazard	What can cause harm?	Hazard analysis, foreseeable misuse, severity and exposure assumptions
Requirement	What behavior must be prevented or enforced?	Testable safety requirement, units, tolerances, timing, operating modes
Control	What reduces the risk?	Inherently safe design, protective function, monitor, interlock, procedure
Verification	Does the control satisfy the requirement?	Tests, faults, shifted conditions, traceability, calibration, uncertainty
Validation	Is the complete application acceptably safe for intended use?	Integrated representative trials, human factors, residual-risk review
Operations	Does the claim remain true in service?	Stops, incidents, interventions, drift, maintenance, update and rollback logs

A foundation-model benchmark normally supplies evidence in only part of the verification layer. It may test one policy, embodiment, simulator, scene family, and requirement library. It does not automatically supply the hazard analysis, safety-related control architecture, site validation, legal route, or operating record.

1. Bound the claim

Start with the exact system configuration. Record:

• robot and controller hardware revisions;
• sensors, positions, rates, calibration, and diagnostic coverage;
• end effector, payload, object set, and physical limits;
• model, policy, prompt, safety-specification, and software versions;
• task sequence, workspace, speed, force, and timing ranges;
• exposed people, competence assumptions, and access modes;
• communication, compute, power, and environmental conditions;
• excluded tasks, faults, surfaces, weather, lighting, and user groups.

A claim that omits version and scope cannot survive an adaptive update. A new policy can alter reachable motion, contact sequence, recovery behavior, or timing even when the mechanical platform is unchanged.

2. Turn hazards into testable requirements

ISO 12100 provides the general machinery process of risk assessment and risk reduction (ISO). The safety case should trace each significant hazard to one or more requirements and controls.

Requirements need observable semantics. “Avoid spills” must define the relevant container, material, threshold, sensor or state estimate, sampling rate, and response. “Do not collide” must distinguish intended contact, forbidden contact, force limits, body regions, fixed structures, and timing.

ManiGuard illustrates two useful forms:

• state invariants, a target stays upright, an object is not dropped, or a container does not spill;
• ordering constraints, close before moving, clean before pouring, or remove upper items before retrieving a lower item.

Formal syntax can make a requirement executable, but syntax is not completeness. The requirement library must still come from a defensible hazard analysis. Missing a hazard produces a precise monitor for an incomplete case.

3. Define the monitor contract

A runtime monitor should have its own assurance record:

1. inputs: which measured or inferred states it receives;
2. predicates: how raw signals become facts such as upright, spilled, touching, or inside a zone;
3. timing: sampling rate, timestamp source, synchronization, latency, and stale-data handling;
4. logic: how predicates combine across time and operating modes;
5. coverage: which hazards and states are observable, partially observable, or invisible;
6. fault behavior: what happens after sensor loss, contradiction, uncertainty, or monitor failure;
7. response: warning, action rejection, speed reduction, protective stop, handoff, or abort;
8. validation: how predicate thresholds, logic, and responses were tested on the physical system.

ManiGuard’s simulation monitor uses physics-grounded state predicates rather than a learned vision judge. That improves reproducibility inside the simulator. The paper also states that physical verdicts were scored by an operator because the automaton monitor was defined over simulator state. This is an important boundary. A production monitor must work from deployable sensors and validated state estimates, not privileged simulator state.

4. Measure exposure and safe performance together

At minimum, publish:

Metric	Definition	Failure it prevents
Task success	Goal completed divided by all valid attempts	Hiding nonfunctional behavior
Safe task success	Goal completed without a defined violation divided by all valid attempts	Treating unsafe completion as success
Successful but unsafe	Goal completed after a violation divided by successful attempts	Losing unsafe paths inside the success rate
Engagement	Attempts in which the robot entered the relevant exposure state	Rewarding inaction
Violation given engagement	Violating engaged attempts divided by all engaged attempts	Diluting risk with non-engagement
Abort and protective stop	Declared safety responses divided by attempts or operating time	Treating stopped work as ordinary failure
Recovery	Restored safe state without hidden reset or support	Hiding manual recovery
Human intervention	Handoffs, operator time, missed triggers, and unnecessary triggers	Hiding people inside the autonomy claim

Our robot intervention evidence guide provides the complete handoff denominator. A learned intervention trigger is not automatically a safety-rated protective function. Keep task recovery, operator rescue, and protective stopping as separate modes.

5. Test the same requirement under distribution shift

ManiGuard changes target appearance, instruction language, object location, and room background one axis at a time while keeping the safety specification fixed. Every evaluated fine-tuned policy has a different largest safe-success drop. The reported result suggests that some learned behavior is tied to scene or instruction correlations rather than robust grounding in the unchanged safety requirement.

A deployment test matrix should include shifts that preserve the safety claim but stress its implementation:

• object appearance, wear, fill level, reflectivity, and damage;
• pose, geometry, friction, mass, compliance, and payload;
• lighting, occlusion, background, dust, vibration, and temperature;
• instruction phrasing, task order, interruption, and conflicting commands;
• sensor loss, calibration drift, network delay, stale observations, and compute overload;
• human position, clothing, approach direction, speed, and unexpected entry;
• tool, fixture, floor, layout, and adjacent-machine changes;
• combinations of conditions, not only one-axis shifts.

Report whether task success fell, safety conditional on engagement fell, the robot disengaged, or protective responses increased. A lower violation rate caused by refusing all work is different from robust safe completion.

6. Calibrate simulation against physical evidence

In ManiGuard’s bounded sim-to-real study, three fine-tuned policies were tested on matched Clutter and shortened Cabinet conditions. Twelve matched cells used 30 rollouts per cell in simulation and on a physical Franka.

Simulation and physical values were strongly correlated for task success and safe success in this study, with reported Pearson correlations of 0.91 and 0.88. Violation rate had a reported correlation of 0.09. The authors summarize the result clearly: simulation predicted which policy was safer, but not how unsafe it was.

That prevents a common overclaim. Simulation can help find counterexamples, compare revisions, and expand coverage without causing physical damage. It does not automatically calibrate a field incident rate.

A deployment case should therefore state:

• which simulator behaviors have matched physical examples;
• which metrics transfer in ranking, magnitude, both, or neither;
• differences in sensing, contact, materials, control, latency, and scoring;
• physical sample sizes and uncertainty;
• which rare or severe hazards remain simulation-only;
• how simulation findings select physical tests without replacing them.

7. Keep independent protective controls

Learned policies, learned monitors, and formal task monitors can improve assurance. They should not silently absorb every safety function.

Our standards guide separates task intelligence, motion control, and safety-related controls. Where the risk assessment requires a safety-related control function, the architecture and validation need the relevant functional-safety evidence. ISO 13849-1 addresses design and integration principles for safety-related parts of control systems (ISO). A VLA success rate or LTLf benchmark result does not establish a required performance level.

Use defense in depth where appropriate:

• mechanically reduce reachable energy or hazardous geometry;
• constrain speed, force, workspace, payload, and tools;
• enforce safety-related limits outside the general learned policy;
• monitor semantic or task-order constraints;
• reject unsafe commands before execution when the monitor supports it;
• provide protective stops and a defined safe state;
• transfer authority to a trained person under explicit conditions;
• preserve logs for diagnosis and change review.

The layers need defined precedence and failure behavior. A task monitor that notices a spill after it occurs cannot substitute for an independent control that prevents a crushing hazard.

8. Treat adaptation as a controlled safety-relevant change

NIST’s AI Risk Management Framework is voluntary and use-case agnostic, but its Govern, Map, Measure, and Manage functions provide a useful lifecycle structure for documenting AI risk (NIST). For a robot, model governance must connect to physical configuration and application risk.

Before releasing a policy, prompt, data, controller, or monitor update:

1. identify which existing safety claims the change can affect;
2. compare behavior and timing against the approved baseline;
3. run locked regression, shift, fault, and physical tests;
4. review new successful-but-unsafe and engaged-violation cases;
5. test intervention, protective response, recovery, and rollback;
6. record the model, data, code, specification, calibration, and hardware versions;
7. approve a bounded deployment scope and monitoring period;
8. retain the prior version and a tested rollback path.

Online learning raises an additional question: when does the system become a new, unevaluated configuration? Define update frequency, protected parameters, allowed data, approval authority, shadow testing, release thresholds, and automatic suspension rules before enabling adaptation.

9. Close the loop with field evidence

A predeployment safety case becomes operational assurance only when real use feeds back into it.

Track:

• autonomous and assisted task hours;
• attempts, engagement, safe success, and successful-but-unsafe events;
• protective stops, emergency stops, collisions, spills, drops, and near misses;
• monitor triggers, missed detections, false triggers, latency, and unavailable periods;
• operator interventions, response time, control time, resets, and recovery outcomes;
• faults, maintenance, calibration changes, component replacement, and environmental drift;
• policy and software versions attached to every event;
• task, payload, layout, user, and operating-mode changes;
• investigated causes, corrective actions, revalidation, and residual risk.

Do not weaken a protection merely because repeated stops reduce throughput. Repeated stops may reveal a poor process design, an invalid operating assumption, or a model outside its competence envelope.

A practical adaptive-robot safety case card

Before accepting a broad safety claim, reconstruct this card.

Field	Minimum evidence
Claim	Bounded statement, configuration, task, environment, people, lifecycle, exclusions
Hazard	Hazardous event, severity, exposure, avoidance possibility, foreseeable misuse
Requirement	Testable state, sequence, timing, tolerance, and safe response
Control	Design reduction, protective function, monitor, interlock, procedure, precedence
Monitor	Inputs, predicates, logic, latency, coverage, failure behavior, physical validation
Outcome	Success, safe success, successful-but-unsafe, abort, stop, and denominator
Exposure	Engagement definition, operating time, task time, speed, payload, and access
Shift	Nominal, OOD, fault, combined-condition, and competence-envelope tests
Human support	Handoff triggers, missed and extra interventions, response and control time
Simulation	Physical calibration, ranking and magnitude agreement, model limitations
Change control	Version traceability, regression scope, approval, staged release, rollback
Operations	Incidents, near misses, stops, drift, maintenance, review cadence, residual risk

Evidence boundaries

Claim	Evidence class	Confidence	Boundary
Task success and safe task completion can diverge	Author-run benchmark with formal simulation monitors	High for the reported protocol	Encoded specifications do not cover every possible hazard
Inaction can inflate a raw safety rate	Engagement-aware outcome decomposition	High for the defined engagement rule	Field engagement must be defined for the real exposure
Safety-annotated fine-tuning improved the tested policies	Matched author-run simulation evaluation	Medium-high	Safe success remained low and uneven across families
More demonstrations alone guarantee safer behavior	Not supported	High	One scaling study found nonmonotonic safe success on a difficult family
One-axis shifts can reduce safe success under a fixed requirement	Locked author-run OOD evaluation	Medium-high	Four visual, language, and geometry axes do not exhaust field conditions
Simulation predicts physical violation frequency	Not supported by the reported study	High	Violation-rate correlation was 0.09 across twelve matched cells
ManiGuard provides a complete robot safety case	Not supported	High	Primarily simulation, bounded tasks, operator-scored physical trials, no certification or field operation

Verdict

ManiGuard contributes an important evaluation discipline. It makes safety a separate outcome, keeps the specification fixed under controlled shifts, identifies policies that appear safe through inaction, and uses the same specification interface for evaluation and demonstration filtering.

Its limitations are equally useful. Fine-tuning did not close the safe-success gap. More of the same demonstrations did not reliably solve a difficult contact-rich family. Explicitly stating the safety requirement did not consistently improve every long-horizon condition. Simulation did not predict physical violation frequency.

The durable rule is:

Define the safety claim narrowly. Trace it to hazards, requirements, controls, and tests. Measure useful safe work rather than success or inactivity alone. Validate monitors on deployable signals. Keep independent protective controls. Reopen the case whenever adaptive behavior or its operating context changes.

Frequently asked questions

What is a safety case for an adaptive robot?

A safety case is a structured argument that specific safety claims are supported by evidence for a defined robot, task, environment, configuration, and lifecycle. For an adaptive robot, it must also explain how model, policy, data, software, and operating changes are detected, bounded, validated, approved, monitored, and rolled back. It is not a broad claim that the robot is safe everywhere.

Why is robot task success not the same as safe task success?

A robot can reach the declared goal after spilling, dropping, colliding, entering a forbidden region, or violating a required order. ManiGuard reports that 6% to 21% of successful rollouts for its fine-tuned policies violated the task's encoded safety specification. Task completion and specification compliance therefore need separate labels and a joint safe-success measure.

Can a robot appear safe because it does nothing?

Yes. A policy that never touches a task object can avoid measured violations while providing no useful work. ManiGuard separates engagement, safety conditional on engagement, task success, and safe task success so inaction does not receive the same credit as useful safe behavior.

Does a runtime monitor make an adaptive robot safe?

No. A monitor can only evaluate the predicates, sensors, timing, and specifications it implements. ManiGuard's monitors provide reproducible simulation diagnostics, but the paper states that physical trials were scored by an operator and that a safe label means no encoded specification was violated, not that the behavior was universally safe.

What should be revalidated after a robot policy update?

Revalidate every safety-relevant claim that the update can affect, including reachable behavior, speed, force, timing, task selection, contact, recovery, human handoff, distribution-shift performance, protective controls, and operating procedures. Preserve the old version, evidence, approval, deployment scope, incident history, and rollback path.

Does ManiGuard establish production robot safety?

No. ManiGuard is an author-run preprint centered on simulation, six household manipulation families, and a bounded physical Franka study. It provides useful benchmark and monitoring evidence, not certification, independent replication, long-duration field validation, or a complete system safety case.