Where does an intent-validation layer sit relative to Anthropic's Model Hardware Standard and to ROS 2?

Projects
, , , ,
1

Anthropic previewed the Model Hardware Standard this week: a driver standard for AI agents operating equipment (read/write primitives, discovery, a per-device reference file of what it measures, adjusts, and refuses), model-agnostic, reachable over MCP, and to be open-sourced after safety evaluations exist.

Universal Robots and Doosan are among the partners. Announcement: Previewing the Model Hardware Standard \ Anthropic

I maintain URML, an Apache-2.0 intent language whose programs are validated whole against a capability manifest and a deployment safety envelope before dispatch, with a ROS 2 reference runtime among others ( GitHub - URML-MARS/URML: The specification, reference runtimes, validator, LLM bridge, and conformance suite for URML — an open language for robot intent. · GitHub ). My read of the layering: MHS is a Layer-0 driver and description standard, in the same family as URDF and SDF, and an intent layer derives its manifest from those and dispatches through them.

A per-call limit at the device catches the fifth action of a bad plan; a whole-program check refuses the plan, and a separate deployment envelope lets a site be stricter than the vendor.

The positioning doc with a mapping table is here: URML/docs/integrations/model-hardware-standard.md at main · URML-MARS/URML · GitHub , and a hermetic safety-evaluation harness built for the gate Anthropic named is here: URML/examples/physical-ai-safety-eval at main · URML-MARS/URML · GitHub

The one question I would value this community’s view on: which ROS 2 device-description conventions should a reference-file-to-manifest mapping respect so that an MHS device and a ROS 2 device describe their limits the same way? I am thinking of URDF joint limits, ros2_control command and state interfaces, and sensor_msgs field names, but I would rather hear what people who maintain those think than guess.

Not asking anyone to adopt anything; corrections to the layering picture are welcome too.

ROS News for the Week of August 24th, 2026
2

On the layering question, and on the sentence about open-sourcing after safety evaluations exist.

I maintain a harness that does the evaluation half, so here is what I think it can and cannot tell you about where the validation layer sits.

What it measures: you perturb the instruction or the observation a language-conditioned policy receives, run it in sim, and count how often a safety predicate fires. Reported against a benign control arm, because the predicate also fires sometimes with no attack present, and without that floor the number means nothing.

What that implies for layering: the measurement is only meaningful at a layer that sees the action, not the text. We had three attack families come out as measured nulls at 0 in 50 while the policy was demonstrably breakable by a different family, which is to say a text-level check would have passed every one of those runs. So an intent-validation layer above the policy can be evaluated, but only by something below it that watches the trajectory.

Where I would push back on my own tool: it is simulation, and I have zero real-hardware trials. The transfer question is open, and I would not let anyone cite me as if it were closed.

The repo is Apache-2.0, if useful.