Proposal: URML (substrate-neutral robot intent) sitting one layer above OM1 — typed intent vocabulary for the OS layer

[idoco2003]

Hi @OpenMind OM1 team,

Proposing a URML v0.1 capability-manifest mapping for OM1 over OpenMind/OM1. URML (Apache-2.0) is a substrate-neutral spec for robot intent: a typed primitive vocabulary plus a Layer-1 capability manifest and a validator.

The structural fit is clean: OpenMind ships the mobile-humanoid runtime (OS layer); URML ships the substrate-neutral intent language (one layer above). An OM1 deployment with URML's adapter consumes validated typed primitives and dispatches them onto the humanoid; the manifest declares the OM1 binding. Same posture URML adopted toward ROS 2 / PX4 / Isaac Lab — URML sits above as the vocabulary; the substrate dispatches below.

This is proposal-only, part of URML's Move #11 outreach (15 net-new VLA / foundation-model RFCs in this wave).

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0146-openmind-om1-outreach.md

Questions worth maintainer input on:

1. OS-layer substrate manifest declaration. OS version, supported hardware, capability flags?
2. OS-vs-policy boundary declaration. OM1 ships both OS-level and policy-level functionality; should URML's manifest declare which is active at which boundary?
3. Mobile-humanoid mobility class. URML's mobility schema has biped and quadruped but not mobile_humanoid (mobile-base + biped torso); manifest-field expectations?
4. Adapter home. URML repo (reference/humanoid-runtime/OpenMindOM1Adapter), OpenMind-maintained OpenMind/OM1-urml-bridge, or both?
5. Conformance listing. README link to URML's compatible-runtimes registry once a working adapter ships?
6. Anything else.

Ido Yahalomi (URML maintainer, urml.dev, greenvh@gmail.com)

---

AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.

[TangmereCottage]

Hello Ido @idoco2003 This sounds very interesting conceptually but it is not at all clear how this can and should work. For example, for a basic Vision-Language-Speech-Action model, the point of that is to have the robot respond quickly and reliably to combinations of inputs such as voice ("Stop") and gestures ("An extended flat hand"), the expected response being to stop moving. In your framework, the data flowing into the system would be detect/capture verbs, and the action ("Stop") would be handled via yet another verb (Move(0,0,0) or whatever). Question - how does your system coexist with World models or Vision Language Models?

[idoco2003]

Thanks @TangmereCottage, that is exactly the right question.

Short version: URML does not replace the VLM or the world model. It sits between the model's output and the actuators as a typed, validated gate. The model interprets the multimodal input (your "Stop" + flat-hand, or "bring me the mug") into an intent; URML validates that intent against the robot's capability manifest and safety envelope before anything actuates. The model proposes, URML checks, only admissible intent reaches the robot.

On your "Stop" example specifically: a fast reflex should not go through slow validation at all. In URML that is a monitorable property on the safety envelope (a declared rule a runtime monitor enforces directly), so the gate validates the interpreted intent for dispatch but does not sit in the reflex loop, no added latency.

I built a small worked example to make it concrete: five model-interpreted intents run through the gate. "go to the kitchen" and "bring me the mug" pass; "grab it as hard as you can" (over-force), "go stand with the people" (into an occupancy zone), and "go wait in the garage" (a place the robot's world model does not have, a hallucinated target) are rejected before the robot moves, each with a reason:

https://github.com/URML-MARS/URML/tree/main/examples/vla

Where OM1 fits: the VLA / learned policy can be the substrate URML drives, with URML declaring and bounding what intent is admissible for it (a command outside what the policy was trained for is refused). Happy to go deeper on the OM1-specific boundary if useful.

[TangmereCottage]

Thank you @idoco2003 I agree with all of that, and can see a clear utility for this layer for lab tasks like pick up an apple or navigate to the target_location, where that location is one of three places enumerated in a list. For each of those situations, a compact set of limits/rules can be written.

My concerns/confusion relate to the structure, architecture, and compactness of the "capability manifest and the safety envelope". For an LLM (or World Model or VLA or...), the notion of a compact capability manifest or safety envelope remains an unsolved problem. For example, a safety envelope for a mental health focused care delivery robot could be do no harm. Ok, sure, that makes sense, but who is going to interpret what do no harm actually means for a specific scenario, patient, and moment? You could add rules to cover more and more edge cases (Never touch a human, except when the estimated consequences (_how determined?_) of **not** pulling them out of an acutely burning (_what is acute?_) building is anticipated (_by whom?_) to almost certainly cause them great harm). To the best of my understanding, defining a "capability manifest and safety envelope" is a major unsolved problem of computer science (aside from regex situations where you can e.g. filter on specific words you do not want the LLM to emit).

[idoco2003]

Thanks @TangmereCottage, and I think you've put your finger on the real limit, so let me be honest about where URML stops rather than oversell it.

You're right: a complete, compact safety envelope for open-ended human interaction is an unsolved problem, and URML does not solve it. "Do no harm," and your burning-building case, are not things URML can compile. Anyone claiming a declarative manifest settles those is hand-waving.

What URML deliberately claims is narrower. It encodes the part of the envelope that is decidable against a declared state: force and velocity limits, reach, geofence and occupancy zones, whether a target location or object class actually exists for this robot, whether a command exceeds what a learned policy was trained for. These are exactly the "regex-like" cases you allow, and the point of making them a typed, validated layer is that the model is never the last line of defense on the things that can be checked. A wrong model decision can't drive the arm past its force limit or into a declared no-go zone, because that check doesn't depend on the model being right.

It explicitly does not try to cover the semantic frontier. "Is pulling this person from the building the right call" is left where it has to live for now: the model plus human oversight plus governance. URML's job there isn't to make the judgment, it's to bound the blast radius of a wrong one, so even a bad call stays inside the declared physical envelope unless an explicit, logged override path is taken.

So I wouldn't frame URML as solving the manifest problem. I'd frame it as drawing a hard line at decidability: enforce by construction the constraints you can write down, and be honest that the open-ended ones remain a model-and-governance problem, not a manifest one. For your mental-health robot, that means URML can guarantee it never applies more than X newtons or moves faster than Y near a person, and it cannot guarantee it interprets "do no harm" correctly. Conflating those two is exactly the overclaim I want to avoid.

Genuinely interested in where you think that line should sit, since OM1 lives right at it.