URML (open robot intent language): mapping TensorSpec to a deployment envelope (request for comment)

[idoco2003]

Hi TorchRL community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: an intent becomes a typed primitive, validated against the robot's declared capabilities and a safety envelope, then dispatched. TorchRL's primitive-first design and its TensorSpec types (which describe observation/action specs precisely) are a natural match for URML's typed view of the world.

Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.

URML has a "LearnedPolicy" declaration: a manifest can say "this capability is served by a learned policy trained within these bounds." Two seams: (1) spec to envelope -- a TorchRL policy carries TensorSpec observation/action specs (bounds, shapes, dtypes), which map almost directly onto a URML deployment envelope (obs/action ranges + training-domain bounds); the export is a thin adapter from TensorSpec to the URML declaration. (2) validated deployment -- URML then sits between the trained policy and the robot, checking each proposed action against declared capabilities + the safety envelope before dispatch.

Two real questions: (1) Does mapping a policy's TensorSpec specs onto a declared deployment envelope make sense as an optional export? (2) Is the validated-deployment gate interesting for the robot-deployment side of TorchRL -- and which is the cleaner first seam?

Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0488-torchrl-outreach.md

Thanks for TorchRL; the primitive-first stance is part of why the mapping feels clean.

Ido Yahalomi (URML, greenvh@gmail.com)

AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.