URML (open robot intent language): ROSPlan plans, URML validates + dispatches — request for comment

[idoco2003]

Hi ROSPlan community,

URML (urml.dev) is a small, Apache-2.0 language for describing robot intent: it validates a request against a capability manifest and a safety envelope, then dispatches. Where URML's Layer-3 is authored control flow, a PDDL planner synthesizes it -- and the two compose. I'm writing to ask how a validated-intent layer should sit next to ROSPlan.

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

Two complementary pieces: (1) ROSPlan plans, URML validates + dispatches -- ROSPlan synthesizes an action sequence from a goal, and each action lowers to a URML primitive that is capability- and envelope-checked before dispatch, so a synthesized plan cannot ask for what the robot cannot honestly do. (2) URML primitives as PDDL actions -- a URML primitive's typed signature + capability precondition maps onto a PDDL durative-action with parameters and preconditions, so the planner reasons over the same capability surface URML validates against. The acid test holds: ROSPlan decides what sequence; URML checks each step is typed, capable, and in-envelope before it runs. (This is distinct from a separate engagement with the PlanSys2 PDDL lineage.)

Two real questions: (1) Is "ROSPlan plans -> URML validates + dispatches each action" a sensible division, and where would the plan-to-primitive lowering live (the plan-dispatch layer)? (2) Could a URML primitive's capability/envelope precondition be expressed as a PDDL action precondition, so planning and validation share a surface?

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

Thanks for ROSPlan; a long-running open PDDL task-planning framework is the right place to think about where planning ends and validated dispatch begins.

Ido Yahalomi (URML, greenvh@gmail.com)

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

[gerardcanal]

Dear @idoco2003,
This definitely sounds interesting, so I'm happy to look into URML. I don't fully get what the capability part is. In principle, I see a PDDL domain as encoding what the robot/system can do, so the capabilities should be there. But I imagine this could be used as a different dispatcher from the ones available now, is this checking the action for validity (i.e., that conditions still hold?). What happens when the validation fails? Definitely feeding back to the planner would be nice, as otherwise we'd get the same plan.

Maybe @m312z can add something too.

[idoco2003]

Thanks @gerardcanal, these are exactly the right questions, and the third one is the interesting part.

On the capability / PDDL relationship: you are right that a PDDL domain already encodes what the robot can do symbolically, and URML does not duplicate that. URML's capability manifest plus a safety envelope is a different layer: the physical robot's declared limits (reach, force, velocity) and the deployment-time safety contract (people-occupancy zones, geofence, grip-force cap). A plan can be perfectly valid in the domain and still inadmissible on the real robot, because the domain never modeled those things. So URML is not a second domain; it is the admissibility check the plan passes through before it actuates.

On whether it is a dispatcher checking validity: yes. URML validates each grounded action against the manifest and envelope before dispatch and halts on the first inadmissible one. It does not plan.

On what happens when validation fails, which is your point about not getting the same plan: URML's rejection is structured (the rejected action, which validation pass failed, the specific error codes, and the violated constraint). That is exactly what you would feed back to the planner so it forbids that action and re-plans, instead of handing back the same plan.

I put a small worked example together to make this concrete rather than hand-wave:
https://github.com/URML-MARS/URML/tree/main/examples/planning
A symbolically valid plan routes through a people-occupancy zone the domain did not model; URML halts at that action with the structured feedback; the re-plan via a safe waypoint then validates and dispatches in full. It is hermetic (validator only), so it runs without a robot.

I would genuinely value yours and @m312z's read on the feedback shape: is "rejected action + failing constraint" what ROSPlan would want to consume for a replan, or would you rather it came back as PDDL (a new predicate, or a temporary action removal)? That is the part I would rather design against your reality than guess at.