OpenRGD 0.2.0 — Why Robot Graph Definition exists

SECTION 01

The missing layer is not another robot file format.

Robotics already has strong representations for geometry, kinematics, dynamics, scenes and simulation. OpenRGD does not start from the assumption that those formats are broken. It starts from a different problem: an intelligent system needs to know which body it is reasoning about, what that body can actually do, what evidence supports those claims, which constraints apply, and where semantic context stops before physical execution begins.

That boundary matters most when cognition becomes portable. A planner, VLM, VLA, policy or world model can produce useful proposals, but a proposal is not yet grounded in a specific embodied system. OpenRGD gives that grounding a representation instead of leaving it implicit in application code, prompts, controller configuration or tribal knowledge.

SECTION 02

0.2.0 is a standard bundle, not a claim that the whole ecosystem is finished.

OpenRGD deliberately separates version axes that mature at different speeds. The current standard bundle is 0.2.0 Draft. The Python toolchain is a 0.1.1 working alpha. Agent Contracts are a 0.1.0 convergence candidate and remain non-normative. Keeping those axes separate prevents a CLI release, an experimental contract or a runtime prototype from being mistaken for a new normative standard.

The same discipline applies inside the model. Foundation and Operation are the most stable semantic areas. Agency remains experimental. Volition is experimental. Evolution and Ether are proposals. Maturity is part of the information architecture because users and machines need to distinguish adopted structure from active research.

• Standard bundle 0.2.0 — Draft.
• Python toolchain 0.1.1 — working alpha.
• Agent Contracts 0.1.0 — convergence candidate, non-normative.

SECTION 03

The domain model is about ownership, not decoration.

The current OpenRGD domain sequence is Core, Foundation, Operation, Agency, Volition, Evolution and Ether. These names are useful only if they clarify who owns which class of meaning. Foundation captures body-grounded description. Operation captures executable capability semantics and constraints. Higher domains progressively deal with agency, intent, adaptation and shared context.

The key rule is that later domains do not get to invent missing facts from earlier ones. A cognitive layer cannot compensate for an unknown actuator limit by assuming a convenient value. A capability cannot become executable merely because a planner wants it. The graph is useful when uncertainty remains explicit.

SECTION 04

Source authority is explicit.

The canonical repository maintains an authority order across its artifacts: manifest, modular specification, accepted contracts, candidate contracts, standard mirror, seed, generated material and history. That ordering is designed to stop convenient generated output or old documentation from silently becoming normative truth.

Integrity has the same boundary. OPENRGD_SOURCE_TREE_SHA256_V1 can prove content identity for a source tree. It does not prove authorship, approval, physical safety or compatibility with a particular robot. OpenRGD treats those as different questions.

SECTION 05

The standard stops before physical execution.

The canonical OpenRGD repository owns the representation, contracts, validation, compilation and static interoperability tooling. It does not ship the canonical physical runtime. Physical execution belongs to an independently governed embodied runtime and to hardware-specific Body Adapters.

That separation is not an implementation inconvenience. It is one of the central safety and interoperability decisions of the project. A machine-readable body description can inform execution without itself becoming actuator authority.

CognitionProposal → ActionIntent → Somatic Translator → CapabilityPlan → Operation Safety Gate → DecisionTrace → Body Adapter → Hardware

SECTION 06

What OpenRGD should become.

The objective is not to accumulate an ever larger ontology for its own sake. The useful endpoint is a compact, auditable representation that lets tools, models and runtimes exchange embodied context without collapsing description, cognition, safety and execution into one opaque system.

Version 0.2.0 is therefore best read as a public contract for convergence: enough structure to build against, enough maturity labels to show what is not settled, and enough boundary discipline to keep future runtime work from rewriting the meaning of the standard.