SECTION 01
Description and authority answer different questions.
A URDF can encode links, joints, inertial properties and limits. SDFormat can describe richer simulation models and worlds. OpenUSD can compose complex scenes and physics schemas. MJCF can represent detailed MuJoCo dynamical systems. Those are powerful forms of evidence about a robot or simulated system.
But none of those facts automatically establish the operational context required to issue a command to physical hardware. A joint limit authored in a model is not proof that a specific actuator is calibrated, connected, healthy, mapped to the expected device ID or currently safe to energize.
SECTION 02
OpenRGD keeps the evidence chain visible.
When source material enters OpenRGD, the goal is to preserve what the source supports and keep everything else explicit. Structural evidence can populate Foundation semantics. Provenance can record where a claim came from and when it was reviewed. Capability semantics can describe what an embodied system may support under stated conditions.
The representation becomes more useful precisely because it refuses to erase uncertainty. Unknown calibration remains unknown. Missing controller semantics remain missing. A manufacturer-stated value remains different from an independently measured result.
source description → evidence → semantic grounding → capability context → runtime validation → hardware authoritySECTION 03
No implicit controller should appear during import.
A common failure mode in robotics tooling is to make a model convenient by filling gaps with defaults. That may be appropriate inside a tightly controlled simulator, but it is dangerous as a general semantic rule. If a source does not declare a transmission, controller, bus mapping, calibration or safety policy, OpenRGD should not manufacture one merely to make the graph look complete.
This fail-closed posture also makes imported profiles easier to audit. A downstream runtime can tell which facts were sourced, which values were derived and which execution-critical bindings still require explicit commissioning.
SECTION 04
Semantic safety is not functional safety.
A rich semantic representation can help identify incompatible actions, missing prerequisites, unsupported capabilities or policy conflicts. That is useful safety context. It is not a substitute for inherently safe mechanical design, application integration, certified safety functions, deterministic runtime constraints or physical validation.
OpenRGD therefore avoids turning labels such as verified, allowed or safe into overloaded assurances. The meaning of each state must remain narrow enough that a consumer cannot mistake data quality for physical certification.
SECTION 05
The separation improves interoperability.
Once description, semantic grounding and execution are separate layers, the same evidence can be reused across multiple consumers. A simulator may need geometry and dynamics. A planner may need capabilities and constraints. A provenance system may need claim lineage. A physical runtime may need a commissioned projection plus hardware-specific bindings.
Interoperability then becomes composition between explicit contracts instead of a requirement that every tool agree on one giant file format or one runtime.
SOURCES & PRIMARY CONTEXT