Hi FlexBE 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. URML has a Layer-3 composition (sequence/parallel/branch/retry over typed, validated primitives). FlexBE's operator-in-the-loop model is a natural complement to URML's validate-before-actuate: a validated typed intent is exactly what an operator wants to see and approve before a state actuates.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
Two seams: (1) URML lowers to a FlexBE state machine -- control flow maps to states + outcomes, URML primitives dispatched from state execution, with the typed args + capability + envelope check verified before the behavior starts. (2) A FlexBE state wraps one URML primitive so the engine gets validate-before-actuate per state, and the validation verdict is something the operator UI could surface. The operator gate and the static gate reinforce each other.
Two real questions: (1) Which seam is more natural -- URML lowering to a FlexBE state machine, or a FlexBE state that dispatches a validated URML primitive? (2) Could the validation verdict (accepted / refused + reason) surface in the FlexBE operator UI before a state runs?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0474-flexbe-outreach.md
Thanks for FlexBE; an operator-in-the-loop FSM is a great place to pair human supervision with a static validate-before-actuate gate.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.
Hi FlexBE 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. URML has a Layer-3 composition (sequence/parallel/branch/retry over typed, validated primitives). FlexBE's operator-in-the-loop model is a natural complement to URML's validate-before-actuate: a validated typed intent is exactly what an operator wants to see and approve before a state actuates.
Nothing here asks the project to adopt, host, or maintain anything. This is a request for comment.
Two seams: (1) URML lowers to a FlexBE state machine -- control flow maps to states + outcomes, URML primitives dispatched from state execution, with the typed args + capability + envelope check verified before the behavior starts. (2) A FlexBE state wraps one URML primitive so the engine gets validate-before-actuate per state, and the validation verdict is something the operator UI could surface. The operator gate and the static gate reinforce each other.
Two real questions: (1) Which seam is more natural -- URML lowering to a FlexBE state machine, or a FlexBE state that dispatches a validated URML primitive? (2) Could the validation verdict (accepted / refused + reason) surface in the FlexBE operator UI before a state runs?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0474-flexbe-outreach.md
Thanks for FlexBE; an operator-in-the-loop FSM is a great place to pair human supervision with a static validate-before-actuate gate.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.