**RCOS — Regenerative Community Operating System**

# Invariants Register

- **Generated:** 2026-04-29
- **Source (latest version):** [https://blueprint.ecohubs.community/articles/rcos-templates/layer-0/invariants-register](https://blueprint.ecohubs.community/articles/rcos-templates/layer-0/invariants-register)
- **All RCOS templates:** [https://blueprint.ecohubs.community/articles/rcos-templates](https://blueprint.ecohubs.community/articles/rcos-templates)

---
- **Layer:** 0 — Identity & Scope
- **Status:** Template — adapt for your community
- **RCOS reference:** [§2.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [§2.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#25-artifacts)

> Invariants are constraints that MUST NOT be violated while they are in force. No decision, role, process, or emergency measure may override an invariant. If a conflict arises between an invariant and any other rule, the invariant prevails.

---

## Active Invariants

*RCOS clauses: [2.3.1](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [2.3.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [2.3.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [2.3.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [2.3.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants), [2.3.6](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-0-identity-scope#23-invariants)*

<details data-kind="rationale">
<summary>Why are invariants unoverridable?</summary>

Invariants are the hard floor of the system — the things that must hold true even under pressure, emergency, or a popular vote. If any decision, role, or crisis measure could override them, they would stop being constraints and become preferences. Listing them explicitly and binding them across every layer is what makes the governance system trustworthy under stress, not just on calm days.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

Each invariant is a hard constraint. Keep them few, specific, and absolute — phrased so that any violation is unambiguously identifiable. Common categories: purpose protection, authority traceability, exit rights, ideological neutrality, non-extraction, safety primacy.

</details>

| ID | Invariant | Added | Decision record |
|---|---|---|---|
| INV-001 | _<Invariant statement, e.g. The primary purpose may never be overridden by any operational or strategic decision, role, or emergency measure.>_ | <YYYY-MM-DD> | [link] |
| INV-002 | _<Invariant statement, e.g. Authority must always be explicit and traceable to the governance system — no person or role may hold or exercise undeclared authority.>_ | <YYYY-MM-DD> | [link] |
| INV-003 | _<Invariant statement, e.g. Exit from the community must always be possible and must never be blocked, penalised, or made conditional beyond what is defined in Layer 1.>_ | <YYYY-MM-DD> | [link] |
| INV-004 | _<Invariant statement.>_ | <YYYY-MM-DD> | [link] |
| INV-005 | _<Invariant statement.>_ | <YYYY-MM-DD> | [link] |
| INV-006 | _<Invariant statement, e.g. Physical, psychological, and child safety always override participation rights, role continuity, and reputational concerns.>_ | <YYYY-MM-DD> | [link] |

---

## Ratification Record

- **Adopted:** <YYYY-MM-DD>
- **Decision type:** Constitutional
- **Version:** <version>
- **Decision record:** <link to decision record>