Change Protocol

Download this template

Generated 2026-04-29 · Download all templates

  • 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).

Every proposal must include:

How Proposals Are Classified

RCOS clauses: 8.1.2, 8.1.4

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

RCOS clauses: 8.1.2, 8.7.1

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

RCOS clauses: 8.2.2, 8.2.4

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

RCOS clauses: 8.5.1, 8.5.2

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 only if all of the following conditions are met:

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:

RCOS Blueprint by EcoHubs

A modular operating system that defines how intentional communities organize — from governance and roles to resource sharing and conflict resolution — in support of resilience, fairness, and regeneration.

Connect

© 2026 EcoHubs Platform. All rights reserved.