Layer 6 · Evolution
1 Change Protocol
- Layer: 6 — Evolution & Adaptation
- Status: Stub — not yet adopted
- RCOS reference: §8.1, §8.5, §8.6
How Changes Are Proposed
RCOS definition8.1.1, 8.1.3, 8.6.3, 8.8.1
- 8.1.1 The community MUST define explicit change mechanisms for modifying, adding, suspending, or removing rules, roles, artifacts, or decision structures.
- 8.1.3 Every proposed change MUST specify, at minimum:
- 8.6.3 The Change Protocol MUST define, at minimum:
- 8.8.1 The following MUST be explicit:
Why require a structured proposal?
A change that arrives as a vague idea in chat cannot be evaluated, challenged, or rolled back later. Forcing every proposal through the same minimum shape — affected artifacts, rationale, risks, rollback — turns an opinion into a reviewable artifact and makes it impossible to slip a rule change past the community by accident.
<Who may propose, how proposals are submitted, and what every proposal must include — to be defined.>
How Proposals Are Classified
RCOS definition8.1.2, 8.1.4
- 8.1.2 Change mechanisms MUST explicitly distinguish between:
- 8.1.4 Changes affecting Layer 0 purpose, scope, invariants, or identity constraints MUST be classified as constitutional changes and MUST follow the constitutional decision mechanism.
Why classify by impact?
Not every change deserves the same friction. Typo fixes should not need a supermajority; constitutional shifts should not pass quietly. Mapping proposals to decision types — and defaulting unclear cases upward — makes the cost of a change proportional to its blast radius and protects Layer 0 from being eroded through small moves.
- Operational: wording corrections, formatting, and minor content updates to artifacts — no vote required
- Strategic: changes to Layer 1–5 content that affect member rights, processes, or structures
- Constitutional: changes to Layer 0 or to the governance system itself (Layer 2)
If classification is unclear, it defaults to the higher-impact type.
Review and Deliberation
RCOS definition8.1.2, 8.7.1
- 8.1.2 Change mechanisms MUST explicitly distinguish between:
- 8.7.1 Change MUST be possible but constrained; no change MAY be instantaneous, implicit, or unreviewable.
Why enforce minimum deliberation windows?
Without a floor on deliberation time, any change can be rushed through on a slow day when few members are paying attention. Mandatory minimums — longer for higher-impact changes — guarantee that members who are travelling, ill, or simply busy still get a real chance to read, object, or show up.
<Minimum deliberation periods per decision type — to be defined.>
Adoption and Publication
RCOS definition8.2.1, 8.2.2, 8.2.5, 8.6.3
- 8.2.1 All adopted changes MUST be versioned and traceable.
- 8.2.2 The community MUST maintain a **Version History** that records, at minimum:
- 8.2.5 No informal, undocumented, or “understood” rule changes MAY be considered valid.
- 8.6.3 The Change Protocol MUST define, at minimum:
Why fixed publication steps?
A vote that passes but is never written down is the same as no vote at all — and worse, it creates a gap where whoever remembers the outcome gets to define it. Tight, ordered publication steps close that gap and make “what was adopted” a matter of record, not of memory.
<Steps to file passed proposals, update affected artifacts, and record in version history — to be defined.>
Rejection
RCOS definition8.2.2, 8.2.4
- 8.2.2 The community MUST maintain a **Version History** that records, at minimum:
- 8.2.4 Superseded rules MUST remain accessible for auditability, learning, and dispute resolution, together with the dates during which they were in force.
Why archive rejected proposals?
Rejected ideas carry as much signal as accepted ones — they show what the community considered and declined. Keeping rejections filed and accessible prevents the same proposal from reappearing under a new name every six months and gives future members a view of the paths not taken.
<Steps to file rejected proposals — to be defined.>
Transition and Migration
RCOS definition8.5.1, 8.5.2
- 8.5.1 The system MUST prefer reversible changes over irreversible ones where possible.
- 8.5.2 Irreversible or high-impact changes MUST include:
Why protect existing rights during transitions?
If new rules could silently rewrite existing agreements, membership would be meaningless — what you signed up for could be changed out from under you. Explicit transition rules guarantee that rights are not reduced retroactively and that people operating under the old rules are given time and notice before the ground shifts.
<Notification, retroactive protection, and transition period rules — to be defined.>
Rollback
RCOS definition8.1.5, 8.5.1
- 8.1.5 The community MUST define explicit review mechanisms for adopted changes, including how changes are evaluated, revised, or reverted when they produce harm, instability, or unintended concentration of power.
- 8.5.1 The system MUST prefer reversible changes over irreversible ones where possible.
Why make rollback symmetrical with adoption?
A change that cannot be undone through the same path that created it is a trap. Requiring rollback to use the original decision type keeps the door open for correction without letting a single member quietly reverse a community-level decision by calling it a “fix.”
Any passed decision can be reversed through the same process as the original decision. Rollback uses the same decision type as the original decision.
Emergency Changes
RCOS definition8.5.3
- 8.5.3 Emergency changes MAY be permitted only where explicitly defined, MUST be time-bounded, MUST NOT override Layer 0 invariants, and MUST undergo mandatory post-hoc review and ratification or rollback.
Why allow emergency changes at all?
Some harms unfold faster than a vote can be convened. A narrow, well-guarded emergency path lets the community respond to genuine safety or platform failures without handing anyone a general-purpose override. The mandatory report, review, and ratification-or-rollback cycle is what keeps emergency powers from becoming ordinary powers.
<Conditions, authorized body, reporting requirements, and ratification-or-rollback cycle for emergency changes — to be defined.>
Experiments
RCOS definition8.3.1, 8.3.2, 8.3.3, 8.3.4, 8.3.5, 8.7.3
- 8.3.1 The community MAY adopt experiments as explicitly time-bounded and reversible deviations, extensions, or pilots intended for learning.
- 8.3.2 Every experiment MUST define, at minimum:
- 8.3.3 Experiments MUST NOT override Layer 0 invariants and MUST NOT bypass governance constraints defined in Layer 2.
- 8.3.4 Experiments MUST be explicitly labeled as experimental in all affected artifacts and MUST include a non-extendable expiration date unless renewed through an authorized decision.
- 8.3.5 If an experiment introduces safety risk, coercion, or sustained harm, the community MUST suspend or terminate the experiment immediately through a protective action, followed by post-hoc review.
- 8.7.3 Experiments MUST be time-bounded, explicitly labeled, and reversible.
Why treat experiments as a distinct mechanism?
The community needs a way to try new things without having to permanently adopt them to test them. Experiments create that space — but only if they are time-bounded, labeled, and auto-expiring. Without those guardrails, an “experiment” becomes the fastest way to install a permanent rule with no real deliberation.
<What an experiment must define, maximum duration, renewal process, and safety suspension rule — to be defined.>
Decentralization Review
<Periodic review cadence for identifying and addressing points of centralization — to be defined.>
Ratification Record
- Adopted:
- Decision type: Constitutional
- Version:
- Decision record: