# Who governs the constitution A federated standard invites a fair question: if participation requires conforming to a shared constitutional model, who controls that model, and what happens to me if I disagree with where it goes? This page answers that directly. It does not create new governance; it surfaces the governance already written into the specification. The full normative text is linked at the bottom. The short version: the standard is stewarded, not owned; anyone may propose a change through a public, versioned process; and if that process ever fails you, you keep two hard rights that do not depend on anyone's good faith, the right to leave and the right to fork. --- ## Who owns the standard Every standard in the family declares, on the record: - its owner and maintainers; - its current version and status; - its full change history. But ownership here is defined narrowly and on purpose: > Ownership implies stewardship of the specification, not ownership of implementations. A steward is responsible for the words of the specification. A steward has no claim over the models you build, the knowledge you publish, or the systems you run. Assuming a governance role "SHALL NOT grant ownership of implementations or of knowledge published by sovereign Universes." The governance itself is described as a set of architectural roles, not as a company or foundation. The roles say which responsibilities exist and which document each one owns: - **Constitution Council** owns the Constitution (MUC) and is the final authority on whether a change preserves constitutional supremacy. - **Architecture Board** owns the architecture standard (MMAS) and ensures it never contradicts the Constitution. - **Federation Working Group** owns the federation protocol (MUFP) and the guarantees that let sovereign Universes collaborate. - **Domain Registry Authority** maintains the registry of compatible meta-models, enabling discovery without transferring ownership. - **Certification Authority** owns conformance and keeps certification criteria publicly available and versioned. These roles are organization-independent by rule: "The standard SHALL remain valid regardless of which entity holds any role." Any conforming organization or community MAY assume one or more of them. The standard is governed by a hierarchy in which each layer constrains the ones below it: Constitution, then architecture standard, then federation protocol, then domain-specific standards, then reference implementations. Two structural guarantees keep the standard from capture: - **Constitutional supremacy.** Lower documents may not contradict higher ones. A domain standard cannot quietly override the Constitution. - **Intellectual independence.** "No programming language, vendor, platform or storage technology SHALL become a normative dependency." The standard is technology-neutral by rule, so no single implementer can make the standard depend on their product. --- ## How a change is proposed and accepted The process is open at the front door and disciplined behind it. It rests on stated principles: constitution before implementation, explicit over implicit, traceability by design, backward compatibility whenever practical, community review, versioned evolution, and, plainly, no silent semantic changes. **Anyone may propose.** "Any stakeholder MAY propose improvements." There is no membership gate on proposing a change. **Every change is a Change Request (CR).** A proposal is not a comment; it is a document. A CR carries a unique identifier, title, motivation, the affected documents, rationale, expected benefits, a compatibility assessment, migration considerations, implementation impact, author, and date. That structure is what makes a change reviewable and traceable rather than a matter of opinion. **Every change walks a fixed lifecycle.** Proposal, discussion, impact analysis, draft specification, review, approval, publication, adoption, and optionally deprecation and retirement. For normative changes, "No stage SHALL be skipped." **Every change is classified on two axes.** The first axis is impact: - **Editorial**: wording and formatting, no change in meaning. - **Corrective**: fixing a defect or ambiguity. - **Evolutionary**: new capability that preserves compatibility. - **Breaking**: an intentional break of compatibility, which "SHALL require explicit justification." The second axis is the semantic subject of the change: whether it touches model structure, the meaning of a concept, federation rules, contract semantics, projection behaviour, or conformance requirements. Declaring the semantic type is not bureaucracy; it lets an agent read a CR, determine what kind of meaning it affects, compute the compatibility impact, and propose migration steps. Change management is meant to be analyzable, not just a manual read. A change to the rule base must also pass a pre-merge policy consistency check: a change that would make the rule set logically unsatisfiable "SHALL NOT be merged." **A change is judged against fixed criteria.** A proposal is not accepted because it is popular. It is evaluated for consistency with the Constitution, impact on interoperability, backward compatibility, implementation complexity, and long-term sustainability. The Constitution comes before any implementation's convenience. **Frozen text cannot move silently.** Once a document is reviewed and approved it enters the Frozen state. Frozen documents become normative references, "SHALL NOT be silently modified," and "MAY only change through an approved Change Request," preserving complete revision history. Released versions are immutable; new function arrives as a new version, never as a quiet edit to an old one. **Compatibility is assessed, and breaks come with a bridge.** Every CR carries a compatibility outcome (fully compatible, backward compatible, forward compatible, requires migration, or breaking). Where compatibility cannot be preserved, "migration guidance SHALL accompany the new specification," including the affected concepts, the required transformations, a compatibility strategy, and examples. Features are deprecated with a named replacement and a planned removal version before any breaking removal. --- ## What you do if you disagree Three recourses, in increasing order of how much they depend on anyone else. **1. Exit.** Your artifacts are plain files under an open license (Apache-2.0). Your models, your published knowledge, and your data are yours. If the standard goes somewhere you will not follow, you leave and you take everything with you. Leaving costs you the federation. It does not cost you your models. Because a steward's ownership is stewardship of the specification and never of implementations, there is nothing for anyone to withhold. **2. Fork.** The standard forks like any open standard. If you believe the steward has made a wrong call, you can copy the specification and evolve your own line. This is the recourse that keeps the steward honest: the value of stewarding the shared layer only holds while people choose to stay on it, so a credible threat of forking is a standing check on capture. Constitutional supremacy and organization-independence mean the text, not the office, is what people conform to, and text can be forked. **3. Participate.** Before exit or fork, there is the ordinary path: file a Change Request. Any stakeholder may propose; the CR is judged against the Constitution, interoperability, backward compatibility, implementation complexity, and long-term sustainability, in public, on the record. Disagreement is a first-class input to the process, not an exception to it. Exit and fork already hold today, because they are properties of open files under an open license rather than promises. Participation is the process described above. Together they are the answer to "who governs the constitution": not a single steward whose good faith you must trust, but a stewarded text you can change, leave, or fork. --- ## Transparency The process is only a real check if you can see it. Exit and fork are worth little if you cannot tell what the steward is doing; transparency is what makes those rights informed rather than blind. The following are meant to remain publicly accessible: published specifications, version history, governance decisions, change requests, and compatibility statements. And the evolution of every normative document must remain auditable: it must be possible to determine why a change happened, who proposed it, when it was accepted, and which version introduced it. Historical versions remain available rather than being overwritten, and certification criteria are kept publicly available and versioned. Change requests and the decisions on them are public by rule, not by favor. --- ## The full text This page condenses two normative documents. Read them for the exact wording and the parts not surfaced here: - **Governance of the Meta-Universe Standard** (MU-V2-CONST-002): stewardship, the standards hierarchy, decision principles, the freeze rule, transparency, intellectual independence, and the governance roles. See [/spec/#01-constitution/Governance.md](/spec/#01-constitution/Governance.md). - **Change Process** (MU-V2-CONST-003): the change lifecycle, the Change Request, change categories and the semantic change classification, compatibility assessment, migration, versioning, and auditability. See [/spec/#01-constitution/Change-Process.md](/spec/#01-constitution/Change-Process.md). The model these govern is the Meta-Universe Constitution (MUC), the thin, mandatory agreement on the form of meaning. What that shared form costs you, and what it deliberately does not touch, is set out in [Limits and trade-offs](/limits/). --- ## Working definition of sovereignty Sovereignty is not the absence of shared rules. It is the right to leave with your models, the right to fork the shared layer, and the right to participate in changing it. Conforming to the shared form is the price of interoperability, and it is named explicitly.