VERCY
view raw markdown

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:

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:

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:

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:

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:

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.

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.