OPENRGD GOVERNANCE

Meaning changes through evidence, review and explicit human acceptance.

OpenRGD separates normative standard changes, candidate experiments, tooling work and historical evidence so that repository location or implementation convenience cannot silently redefine the standard.

Canonical governance ↗About OpenRGD →Security →

CITATION RECORD

Canonical source ↗Citation guide →

MATURITYNORMATIVE GOVERNANCE SUMMARY

LAST VERIFIED27 Sep 2026

SOURCE VERSIONGOVERNANCE.md · current main lineage

EVIDENCE BOUNDARYWeb summary of canonical governance. GOVERNANCE.md and machine-enforced repository policy remain authoritative.

SCOPE

The canonical repository governs representation and contracts.

Governance covers the modular specification, cross-component contracts, canonical hashing, deterministic compilation, evidence-only importers, static exporters, validation tooling and compatibility records.

LIMIT

Governance does not grant physical execution authority.

Body Adapters, hardware orchestration and embodied runtimes remain separately governed implementation responsibilities. No repository decision turns a semantic artifact into permission to actuate hardware.

HUMAN ACCOUNTABILITY

AI may assist. A human maintainer accepts normative change.

Current steward

Pasquale Ranieri (@phate6872) is named as the current project steward.

Normative acceptance

A human maintainer remains accountable for accepting normative changes, merging pull requests and publishing releases.

AI participation

AI systems may help draft, review, test or analyze changes, but temporary AI profiles are not governance authorities.

MATURITY STATES

Location in the repository never overrides declared maturity.

candidateCANDIDATEReviewable convergence material; non-normative and subject to breaking change.

acceptedACCEPTEDApproved through governance and normative within its declared version or profile.

deprecatedDEPRECATEDRetained for compatibility and provenance but no longer recommended.

historicalHISTORICALEvidence only; never current authority.

NORMATIVE CHANGE

Changes that alter meaning require more than a code diff.

Evidence

A normative change must state the problem and the evidence supporting the proposed change.

Compatibility

Meaning-changing work must analyze compatibility, migration and affected consumers.

Decision record

RFC or decision evidence is required when compatibility, governance, hard invariants or ownership change.

Integrity

Canonical hashes and derived artifacts are updated when their selected source bytes change.

CI

Required validation and conformance checks must pass on the reviewed head.

Acceptance

A human maintainer records explicit acceptance before the normative change is merged.

RFC & CONTRACT PROMOTION

Candidate material becomes normative only through an explicit promotion decision.

01Complete contract

Schemas and normative text are complete.

02Compatibility

Versioning and compatibility rules are explicit.

03Conformance

Producer and consumer conformance tests exist.

04Reference flow

At least one validated reference flow is available.

05No contradiction

The candidate does not conflict with the Canonical Core.

06Governance decision

An accepted RFC or equivalent decision records promotion.

07Machine-readable state

Status metadata is updated to reflect the new maturity.

MERGE ≠ RELEASE

A merged change is not automatically a published standard or stable contract.

Standard, toolchain and contract releases use separate scoped version axes. Release preparation requires its own evidence, compatibility statement, artifact inventory and provenance.

CANONICAL RECORD

Use the repository governance files when precision matters.

GOVERNANCE.md ↗Release policy ↗Contributing ↗