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 RoboBrain 2.5
RoboBrain 2.5 predicts complete 3D manipulation traces as ordered keypoint sequences under physical constraints, alongside affordance prediction and trajectory forecasting. Because the output is a concrete geometric trace rather than text, a validate-before-actuate gate has a surface: the robot declares a reachable workspace, payload, and a safety envelope, and URML checks the predicted keypoint trace is admissible on that specific robot before execution. The model already reasons under metric, depth-aware constraints; a declared capability + envelope is that same idea made explicit and per-robot, so the same predicted trace can be checked against whatever arm actually executes it.
What I am asking
- Would checking a predicted keypoint trace against a declared reachable workspace + safety envelope be a useful guard, given RoboBrain already predicts under physical constraints?
- Would a small worked example mapping a RoboBrain trace 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 RoboBrain 2.5
RoboBrain 2.5 predicts complete 3D manipulation traces as ordered keypoint sequences under physical constraints, alongside affordance prediction and trajectory forecasting. Because the output is a concrete geometric trace rather than text, a validate-before-actuate gate has a surface: the robot declares a reachable workspace, payload, and a safety envelope, and URML checks the predicted keypoint trace is admissible on that specific robot before execution. The model already reasons under metric, depth-aware constraints; a declared capability + envelope is that same idea made explicit and per-robot, so the same predicted trace can be checked against whatever arm actually executes it.
What I am asking
Nothing here asks the project to adopt, host, or maintain anything. Thanks for reading.