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

**URL:** <https://discourse.openrobotics.org/t/where-does-an-intent-validation-layer-sit-relative-to-anthropics-model-hardware-standard-and-to-ros-2/57725>\
**Category:** Projects\
**Tags:** ros2, interoperability, safety, llm, physical-ai\
**Created:** [August 28, 2026, 4:41pm UTC](https://discourse.openrobotics.org/t/where-does-an-intent-validation-layer-sit-relative-to-anthropics-model-hardware-standard-and-to-ros-2/57725 "2026-08-28T16:41:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ido\_Yahalomi](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/ido_yahalomi/32/33990_2.png) [@Ido\_Yahalomi](https://discourse.openrobotics.org/u/Ido_Yahalomi)\
**Post date:** [August 28, 2026, 4:41pm UTC](https://discourse.openrobotics.org/t/where-does-an-intent-validation-layer-sit-relative-to-anthropics-model-hardware-standard-and-to-ros-2/57725/1 "2026-08-28T16:41:01Z")

</div>

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](https://www.anthropic.com/news/model-hardware-standard-research-preview)

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](https://github.com/URML-MARS/URML) ). 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](https://github.com/URML-MARS/URML/blob/main/docs/integrations/model-hardware-standard.md) , 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](https://github.com/URML-MARS/URML/tree/main/examples/physical-ai-safety-eval)

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.

---

<div class="post-metadata">

**Author:** ![Sattyam\_Jain](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/sattyam_jain/32/35258_2.png) [@Sattyam\_Jain](https://discourse.openrobotics.org/u/Sattyam_Jain)\
**Post date:** [September 1, 2026, 5:36am UTC](https://discourse.openrobotics.org/t/where-does-an-intent-validation-layer-sit-relative-to-anthropics-model-hardware-standard-and-to-ros-2/57725/2 "2026-09-01T05:36:15Z")

</div>

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.