SECTION 01
A semantic standard and a real-time runtime have different failure modes.
Specification code benefits from portability, inspectability and deterministic transformations. Physical execution has additional concerns: timing, buses, device state, actuator limits, emergency behavior, middleware, calibration and hardware-specific failure modes. Combining both responsibilities in one canonical package would make the standard harder to reason about and the runtime harder to evolve safely.
OpenRGD therefore draws a repository boundary. The canonical project owns the standard, cross-component contracts, validators, compilers and static import/export tooling. Physical execution belongs elsewhere.
SECTION 02
Three layers have distinct owners.
The OpenRGD core defines semantic representation and non-actuating tooling. An embodied runtime consumes a validated projection and owns intent ingestion, somatic translation, safety gating, execution lifecycle and runtime coordination. Body Adapters own hardware-specific details such as device mappings, buses, middleware messages, units and actuator behavior.
Those boundaries allow a robot-specific adapter to change without rewriting the semantic standard, and allow a runtime implementation to evolve without turning its internal mechanisms into normative RGD semantics.
- OpenRGD core: specification, contracts, validation, compilation and static interoperability.
- Embodied runtime: intent handling, translation, runtime constraints, execution and lifecycle.
- Body Adapter: hardware-specific interfaces, mappings and actuator behavior.
SECTION 03
The candidate execution path makes authority transitions explicit.
The current architecture describes a sequence from cognition to hardware. The exact runtime implementation remains independent, but the semantic handoffs are useful because each stage has a narrower responsibility.
A CognitionProposal can become an ActionIntent. Somatic translation can ground that intent against the body. A CapabilityPlan can be evaluated by the operation safety layer. DecisionTrace can preserve the reasoning context. Only the Body Adapter crosses into hardware-specific execution.
CognitionProposal → ActionIntent → Somatic Translator → CapabilityPlan → Operation Safety Gate → DecisionTrace → Body Adapter → HardwareSECTION 04
Legacy runtime commands fail closed.
Historical command surfaces are useful for compatibility and migration, but they should not quietly reintroduce physical execution into the canonical CLI. The adopted repository policy keeps legacy physical adapter commands visible only as a boundary and makes them fail deterministically rather than importing middleware or opening devices.
That behavior is intentionally boring. A tooling command that cannot prove it owns execution should not attempt execution.
SECTION 05
Real-time control can still be sophisticated outside the canonical repo.
The runtime boundary does not imply that OpenRGD ignores real-time robotics. It means deterministic loops, reflexes, hardware buses and volatile high-rate state can be implemented in a runtime optimized for those responsibilities while consuming a prevalidated OpenRGD projection.
This also leaves room for different runtime implementations. A research runtime and an industrial runtime may have very different scheduling, safety and observability requirements while agreeing on the semantic contract they consume.
SECTION 06
The payoff is replaceability.
A healthy standard should survive changes in middleware, hardware vendors, model providers and runtime implementations. The runtime boundary is what gives OpenRGD a chance to remain stable while the Physical AI stack around it changes rapidly.
The project can then focus its normative work on representation and contracts: what an embodied system means, what evidence supports that meaning, and which transitions must be explicit before another component takes responsibility for physical action.
SOURCES & PRIMARY CONTEXT