- Layer: 2 — Governance & Decision Logic
- Status: Template — adapt for your community
- RCOS reference: §4.2, §4.4, §4.7
Maps every decision type and domain to an authorized role or body, mechanism, threshold, and escalation path. Decisions made outside this matrix are considered invalid.
Voting Principles
RCOS clauses: 4.2.1, 4.2.3, 4.2.4
Why pin down mechanism, threshold, and timing?
A vote without a predefined mechanism, threshold, and deliberation window is an invitation to manufacture outcomes after the fact — whoever counts the votes or sets the clock wins. Declaring these parameters in advance makes every collective decision reproducible and contestable on the same terms, regardless of who is in the room.
How to fill this in
State the voting platform, the threshold for each decision type, the deliberation period, the tie rule, the re-vote rule, and any delegated-authority spending or scope limit.
- Voting platform:
- Operational threshold:
- Strategic threshold:
50%); minimum X-day deliberation.> - Constitutional threshold:
- Tied vote:
- Re-vote:
- Reasoned objection:
- Delegated authority spending limit:
Matrix
RCOS clauses: 4.4.1, 4.4.2, 4.4.3, 4.4.4
Why a single authoritative matrix?
If the rules for who decides what live in people’s heads, authority becomes whatever the loudest or most senior person says it is. A public matrix that binds every decision to a domain, body, mechanism, and threshold makes out-of-scope action visible the moment it happens — and makes any decision made outside it invalid by construction.
How to fill this in
For each decision domain (membership, treasury, platform, partnerships, governance, etc.), set the decision type, the authorized body, who is eligible to participate, the mechanism, threshold, blocking conditions, and escalation path.
| Decision Domain | Decision Type | Authorized Body | Eligible Participants | Mechanism | Threshold | Blocking / Veto conditions | Escalation |
|---|---|---|---|---|---|---|---|
| <…> | <…> | <…> | <…> | <…> | <…> | <…> | |
| <…> | <…> | <…> | <…> | <…> | <…> | <…> | |
| <…> | <…> | <…> | <…> | <…> | <…> | ||
| <…> | <…> | <…> | <…> | <…> | <…> |
Operational role holders: Each operational decision is executed by the named role holder responsible for that domain, acting within their defined scope per the Role Registry (Layer 5). Where a decision spans multiple domains, each role holder acts within their own scope.
Decision Type Definitions
RCOS clauses: 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5
Why classify every decision?
Without a type, every decision gets handled at whatever speed and scrutiny happens to suit the moment — routine changes stall in debate, and constitutional shifts slip through unnoticed. Fixed types tie the weight of a decision to the process it must pass through, and the default-higher rule closes the gap where ambiguity would otherwise be exploited.
How to fill this in
Define each decision type by what it covers, who executes it, what process it requires, and how disputes about classification are resolved.
- Operational —
- Strategic —
- Constitutional —
If a decision cannot be clearly classified, it defaults to the higher-impact type.
Ratification Record
- Adopted:
- Decision type: Constitutional
- Version:
- Decision record: