Disclosure up front: URML is invented and maintained by one person (Ido Yahalomi), and its prose, including this issue, is AI-assisted under my direction and review (VIBE.md: https://github.com/URML-MARS/URML/blob/main/VIBE.md). This is a genuine request for comment, not an automated broadcast, and "out of scope" is a perfectly good answer.
What URML is
URML is a small, open (Apache-2.0), vendor-neutral language for describing robot intent. A robot declares a capability manifest (grippers, reach, payload, sensors) and a safety envelope, and URML statically checks that an action is admissible on that specific robot before it reaches the hardware. It sits above the policy, not inside it. It cross-cites and does not vendor or depend on your code; its LLM bridge is provider-agnostic. Repo: https://github.com/URML-MARS/URML
Why UniVLA
UniVLA plans in a unified, embodiment-agnostic latent action space, then is post-trained and decoded to a specific embodiment for deployment (real-world arm, LIBERO, CALVIN). That decode-from-agnostic-to-concrete step is exactly where a per-embodiment admissibility check fits: when the action is decoded onto a particular robot, URML checks the concrete action fits that robot's declared force, reach, and mobility, inside its safety envelope, before dispatch. An embodiment-agnostic policy still needs the concrete action to be admissible on the embodiment that runs it, and a declared per-embodiment capability + envelope is the natural place that check lives.
What I am asking
- At the decode-to-embodiment step, would a declared per-embodiment capability + safety envelope be a useful admissibility check on the concrete action?
- Would a small worked example mapping a decoded UniVLA action onto a URML manifest (validated, no execution) be worth having, in your examples or ours?
Nothing here asks the project to adopt, host, or maintain anything. Thanks for reading.
Disclosure up front: URML is invented and maintained by one person (Ido Yahalomi), and its prose, including this issue, is AI-assisted under my direction and review (VIBE.md: https://github.com/URML-MARS/URML/blob/main/VIBE.md). This is a genuine request for comment, not an automated broadcast, and "out of scope" is a perfectly good answer.
What URML is
URML is a small, open (Apache-2.0), vendor-neutral language for describing robot intent. A robot declares a capability manifest (grippers, reach, payload, sensors) and a safety envelope, and URML statically checks that an action is admissible on that specific robot before it reaches the hardware. It sits above the policy, not inside it. It cross-cites and does not vendor or depend on your code; its LLM bridge is provider-agnostic. Repo: https://github.com/URML-MARS/URML
Why UniVLA
UniVLA plans in a unified, embodiment-agnostic latent action space, then is post-trained and decoded to a specific embodiment for deployment (real-world arm, LIBERO, CALVIN). That decode-from-agnostic-to-concrete step is exactly where a per-embodiment admissibility check fits: when the action is decoded onto a particular robot, URML checks the concrete action fits that robot's declared force, reach, and mobility, inside its safety envelope, before dispatch. An embodiment-agnostic policy still needs the concrete action to be admissible on the embodiment that runs it, and a declared per-embodiment capability + envelope is the natural place that check lives.
What I am asking
Nothing here asks the project to adopt, host, or maintain anything. Thanks for reading.