Layer 2 · Governance
2 Governance Protocol
- Layer: 2 — Governance & Decision Logic
- Status: Stub — not yet adopted
- RCOS reference: §4.5, §4.6, §4.7
Defines the full lifecycle of a collective decision — from proposal submission to documentation and appeal.
Proposal Submission
RCOS definition4.5.1, 4.5.2
- 4.5.1 The community MUST define a Governance Protocol describing the full lifecycle of a decision.
- 4.5.2 The Governance Protocol MUST include:
Why formalize how proposals enter the system?
A decision process that accepts proposals informally — a message, a verbal suggestion, a founder’s idea — has no reliable way to tell what is actually on the table. Requiring a standard submission format, filing location, and mandatory content fields means every proposal arrives with the same information, visible to everyone, traceable from day one.
<Proposal submission process, required content, and withdrawal rules — to be defined.>
Review and Deliberation
RCOS definition4.5.1, 4.5.2
- 4.5.1 The community MUST define a Governance Protocol describing the full lifecycle of a decision.
- 4.5.2 The Governance Protocol MUST include:
Why enforce a minimum deliberation window?
Rushed votes favor whoever is already paying attention and disadvantage everyone else. A mandatory deliberation period, tied to the weight of the decision, gives members time to read, respond, and surface concerns before the vote opens — so the vote reflects considered judgment, not speed of reaction.
<Deliberation forums, minimum deliberation guidelines, and discussion norms — to be defined.>
Decision Execution
RCOS definition4.5.1, 4.5.4
- 4.5.1 The community MUST define a Governance Protocol describing the full lifecycle of a decision.
- 4.5.4 All governance actions MUST be documented according to Layer 5 documentation rules.
Why tie execution to the record?
A passed proposal that never reaches the affected artifact is a decision in name only — the rules on the ground still say what they said before. Binding execution to a concrete artifact update and version-history entry closes the gap between what was decided and what is actually in force.
<Consensus testing, absentee review period, publication of passed/rejected proposals, and artifact update process — to be defined.>
Documentation and Publication
RCOS definition4.5.4
- 4.5.4 All governance actions MUST be documented according to Layer 5 documentation rules.
Why document every outcome, including rejections?
Keeping a record of only the decisions that passed erases the reasoning history — members lose track of what was already considered and rejected, and the same debates get re-litigated indefinitely. Archiving both passed and rejected proposals, with a time bound and a verifiable decision record, preserves institutional memory and makes the governance system auditable.
<Meeting minutes storage, hard copy requirements, and version history update process — to be defined.>
Appeal and Review
RCOS definition4.5.2, 4.6.2
- 4.5.2 The Governance Protocol MUST include:
- 4.6.2 Governance mechanisms MUST allow for challenge and review without retaliation.
Why make re-votes possible but bounded?
A governance system with no appeal route hardens mistakes into permanent rules; one with unlimited informal appeal paths never settles anything. Allowing any Full Member to trigger a re-vote — but only with a written, reasoned objection raising something not already addressed — keeps the system self-correcting without turning every decision into a standing referendum.
<Re-vote and objection conditions — to be defined.>
Sovereignty of Community Areas and Properties
Why define sovereignty of areas?
Recognizing the sovereignty of localized areas ensures that decisions primarily affecting a specific physical community or property are made by the people actually residing there, preventing overreach by the broader network while maintaining shared standards.
<Rules governing community area sovereignty, autonomy, and federation — see Federation Protocol (Layer 2).>
Conflict Between Decisions
RCOS definition4.5.3
- 4.5.3 The Governance Protocol MUST define how conflicts between decisions are resolved.
Why predefine conflict resolution?
When two decisions point in different directions, someone has to choose which one counts — and if that choice is made ad hoc, it reduces to whoever has the authority or energy to enforce their reading. A fixed precedence rule (higher type wins; more recent wins at the same type) resolves conflicts mechanically, without a judgment call.
<Decision precedence rules and conflict surfacing process — to be defined.>
Safeguards and Failure Modes
RCOS definition4.6.1, 4.6.2, 4.6.3
- 4.6.1 The governance system MUST include safeguards against:
- 4.6.2 Governance mechanisms MUST allow for challenge and review without retaliation.
- 4.6.3 Persistent governance failures MUST trigger a formal review or constitutional process.
Why plan for governance failure up front?
Every governance system fails somewhere — captured by a subgroup, frozen by informal vetoes, drifted by a role holder who quietly expanded their remit. Naming the specific failure modes in advance, wiring in challenge routes that cannot be retaliated against, and requiring a formal review when failures accumulate, is what keeps governance from slowly hollowing out while no one is watching.
<Safeguards against power concentration, informal vetoes, decision capture, and persistent failure — to be defined.>
Ratification Record
- Adopted:
- Decision type: Constitutional
- Version:
- Decision record: