Proposal: URML (substrate-neutral robot intent) capability-manifest mapping for TinyGo — Go-on-MCU firmware-language substrate

[idoco2003]

Hi @tinygo-org team,

Proposing a URML v0.1 capability-manifest mapping for TinyGo over tinygo-org/tinygo. URML (Universal Robot Language, Apache-2.0) is an open spec for substrate-neutral robot intent.

TinyGo brings the Go language to MCU substrates spanning RP2040, SAMD21/51, nRF52, STM32, AVR, and WebAssembly. URML's manifest declares which firmware-language substrate is loaded; TinyGo joins MicroPython, CircuitPython, native C/C++, and Arduino C++ in the substrate enum URML's sibling Move-13 MCU + maker RFCs populate. The 90+ TinyGo targets need an identifier-mapping convention in URML's manifest (similar to PlatformIO's 900+ board catalog).

This is proposal-only, posted as part of URML's Move #13 outreach (15 engageable RFCs in this wave).

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0183-tinygo-outreach.md

Questions worth tinygo-org maintainer input on:

1. Firmware-language substrate manifest fields. URML's v0.1 has no tinygo firmware-language declaration. Spec RFC queued. Manifest field expectations from the TinyGo perspective?
2. TinyGo-target catalog identifier scheme. Should URML's manifest use TinyGo's target-id directly, or a separate URML identifier mapped to it?
3. WebAssembly target scope. Should URML's manifest declare WebAssembly as a valid TinyGo target (non-MCU substrate), and how does that compose with URML's robotics-class manifest assumptions?
4. Adapter home. URML repo (reference/edu-runtime/TinyGoAdapter), TinyGo-community-maintained tinygo-org/tinygo-urml-bridge, or external?
5. Conformance listing. Would the tinygo-org maintainers consider a README link to URML's compatible-runtimes registry once a working adapter ships?
6. Anything else.

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.

[aykevl]

What does URML do, and why do we need support in TinyGo?

[idoco2003]

Fair question, and the honest answer is that TinyGo does not need to do anything. Let me be concrete and drop the jargon my first post buried it under.

URML (https://urml.dev) is a small Apache-2.0 language that sits above the firmware. Before a robot acts, it checks the intended action against a declaration of what that machine can do (reach, payload, speed, which sensors) plus a safety envelope, and refuses anything outside it. It is a static "is this command admissible on this robot?" pass that runs before anything moves. It compiles down to whatever runtime is underneath and does not replace the firmware or the language it is written in.

TinyGo enters only as a label. One optional field in a robot's URML manifest records which firmware substrate the robot runs on, so the description is accurate: a TinyGo-on-RP2040 robot rather than a MicroPython or C++ one. That is a value URML writes down, not a feature TinyGo implements. Nothing to add, host, or maintain on your side.

So the only thing I was actually asking maintainer input on is a naming courtesy: when URML records "runs on TinyGo, target X," should it reuse TinyGo's own target ids (rp2040, arduino-nano33, wasm, ...) verbatim, or keep a separate URML name mapped to them? Reusing yours seems obviously right to me, but you know how stable that target list is. If reusing them verbatim is fine, that answers it completely and there is nothing further needed from you.

-- Ido