- Layer: 6 — Evolution & Adaptation
- Status: Template — adapt for your community
- RCOS reference: §8.1, §8.5, §8.6
How Changes Are Proposed
RCOS clauses: 8.1.1, 8.1.3, 8.6.3, 8.8.1
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.
How to fill this in
State who may propose, where proposals are submitted, and the mandatory content fields. Tie this to the Governance Protocol (Layer 2).
How Proposals Are Classified
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.
How to fill this in
Define what falls under each decision type. State the default-higher rule for ambiguous cases.
- Operational:
- Strategic:
- Constitutional:
If classification is unclear, it defaults to the higher-impact type.
Review and Deliberation
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.
How to fill this in
Set minimum deliberation periods for each decision type, and a ratification period for Constitutional changes.
- Operational:
- Strategic:
- Constitutional:
Adoption and Publication
RCOS clauses: 8.2.1, 8.2.2, 8.2.5, 8.6.3
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.
How to fill this in
State the ordered steps that must run after a proposal passes. Include time bounds and the version-history obligation.
When a proposal passes:
Rejection
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.
How to fill this in
State the archive location for rejected proposals and the re-vote conditions for revisiting the question.
When a proposal is rejected:
Transition and Migration
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.
How to fill this in
State the rules protecting existing role holders, members, and records when a rule change takes effect.
When a rule change affects existing roles, agreements, or records:
Rollback
RCOS clauses: [8.1.5](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#81-change-mechanisms), [8.5.1](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#85-change-safety-and-reversibility)
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.”
How to fill this in
State that rollback uses the same decision type and process as the original adoption.
Emergency Changes
RCOS clauses: [8.5.3](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#85-change-safety-and-reversibility)
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.
How to fill this in
Define the conditions under which an emergency change may be made, who can make it, and the mandatory report-review-ratify-or-rollback cycle.
An emergency operational change may be made by
Emergency changes must be:
Experiments
RCOS clauses: [8.3.1](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#83-experiments), [8.3.2](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#83-experiments), [8.3.3](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#83-experiments), [8.3.4](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#83-experiments), [8.3.5](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#83-experiments), [8.7.3](/articles/rcos-core/v0-1/layer-6-evolution-adaptation#87-layer-invariants)
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.
How to fill this in
Define the rules every experiment must satisfy. Reference the Experiment Template for the full submission shape.
Ratification Record
- Adopted:
- Decision type: Constitutional
- Version:
- Decision record: