URML (robot intent language) — RFC on a BrainFlow intent-input bridge (alternative to natural-language intent)

[idoco2003]

Hi BrainFlow team (and OpenBCI, cross-referenced),

URML (urml.dev) is a small, opinionated, human-readable language for describing robot intent — Apache-2.0. Its job is to turn an intent into verified, safe robot motion: it validates intent against a capability manifest and a safety envelope before anything executes. Natural language is URML's usual source of intent. This RFC asks about a different source: a brain-computer-interface intent signal, delivered through BrainFlow from OpenBCI hardware, feeding URML's behavior layer for users who cannot use the language path.

This is a proposal-only RFC, and the most exploratory thing we have posted. It is honest that this is an input-bridge, not a runtime adapter: URML does not decode EEG and does not classify neural signals — that stays in your pipeline. The bridge is narrow:

OpenBCI board -> BrainFlow stream -> (user's classifier) -> discrete intent label -> URML behavior trigger -> validate -> execute

URML consumes a discrete intent label and runs its normal validate-then-execute path. It is the non-verbal analog of how speech-to-text feeds a text layer: the recognizer produces a token, URML does the rest. MIT composes cleanly with Apache-2.0, so there is no license boundary and nothing to merge. Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0230-openbci-brainflow-outreach.md

A few questions for the maintainers (full list in the RFC):

1. Bridge boundary. Is "BrainFlow stream plus the user's classifier emits a discrete intent label, URML consumes the label" the right boundary, or would you expect URML to engage a different layer?
2. Intent-label contract. Is there a conventional shape for classified-intent events in BrainFlow-based projects that URML should map to, rather than inventing one?
3. Confidence gating. A classifier emits a confidence. Should URML require a per-intent confidence threshold before a behavior fires? This is the safety-relevant question.
4. Two-party scope. Should we engage BrainFlow (the SDK) and OpenBCI (the hardware) separately, or is one the right entry point?
5. Anything else — including whether the assistive-robotics framing matches how your users actually drive robots.

Happy to scope down or shelve. If a maintainer prefers Slack, the OpenBCI forum, or human-only correspondence, that is welcome and we will route to it. Thanks for the vendor-neutral biosignal SDK that makes a question like this even askable.

Ido Yahalomi (URML maintainer, urml.dev, greenvh@gmail.com)

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

[Andrey1994]

hi. BrainFlow doesnt provide labels/classifier outputs from the box, what it does is provide users API and tools to train these classifiers.

So if I understand questions here correctly:

• Bridge boundary. Is "BrainFlow stream plus the user's classifier emits a discrete intent label, URML consumes the label" the right boundary, or would you expect URML to engage a different layer? - if you train a classifier and use brainflow for data collection and analysis it will work
• Intent-label contract. Is there a conventional shape for classified-intent events in BrainFlow-based projects that URML should map to, rather than inventing one? - there were different attempts to classify how focused the person is inside and outside brainflow, but you can have own implementation and add more classes
• Confidence gating. A classifier emits a confidence. Should URML require a per-intent confidence threshold before a behavior fires? This is the safety-relevant question. - dont understand the question, it depends on the desired result and classifier accuracy
• Two-party scope. Should we engage BrainFlow (the SDK) and OpenBCI (the hardware) separately, or is one the right entry point? - up to you, I can help from BrainFlow side
• Anything else — including whether the assistive-robotics framing matches how your users actually drive robots.

[Andrey1994]

you can have p300 based speller like implmentation to trigger events also, I am not familiar enough with URML to advice which way would work better

[idoco2003]

Thanks, Andrey. This is the correction we needed.

Boundary: understood that BrainFlow is the data and analysis layer, and the classifier is the user's to train. So the discrete intent label comes from user code built on BrainFlow, not from a BrainFlow API. Our diagram already put the classifier outside URML; your note makes the BrainFlow side precise, and we will write it up so nothing implies BrainFlow emits labels itself.

Intent-label shape: got it that there is no conventional event contract. URML will define a small one of its own, an intent name plus an optional confidence, and let users add classes as they need them, rather than claim to mirror a BrainFlow standard.

Confidence gating: this is the answer I was hoping for. It tells me the threshold belongs on URML's side, tuned to the classifier's accuracy and the action's risk, not on yours. URML will own a per-intent confidence floor before a behavior fires, alongside the capability manifest and safety envelope it already checks.

P300 speller is a useful pointer. A speller-style selection is a clean, explicit trigger and may be a better first target than a continuous classifier, since the intent is discrete by construction. We will look at both.

Your offer to help from the BrainFlow side is appreciated and taken. This stays an input-bridge on our end, with no code or merge asked of you, and anything hardware-specific we will route to OpenBCI separately.

Thanks again for taking the time.
Ido (urml.dev, greenvh@gmail.com)

[Andrey1994]

Good, I will close this one, in case of further questions feel free to ping me in slack