Regenerative Community Operating System (RCOS)

A community MUST define exactly one primary purpose.

The primary purpose MUST describe the enduring reason for the community’s existence and MUST NOT be a short-term goal, project, or strategy.

The primary purpose MUST be stable across time and MUST only be changed through a constitutional decision as defined in Layer 2 and executed via the change process defined in Layer 6.

Secondary purposes MAY be defined, but MUST NOT conflict with or override the primary purpose.

No action, decision, or allocation of resources MAY materially contradict the stated primary purpose.

The community MUST explicitly declare the scope of what it governs.

The scope declaration MUST include, at minimum:

• Assets governed by the community
• Domains of decision-making authority
• Activities and responsibilities under collective control

The scope declaration MUST explicitly list what is out of scope.

Anything not explicitly declared as in scope MUST be treated as out of scope.

The community MUST NOT exercise authority over persons, assets, or domains that are declared out of scope.

Invariants are constraints that define what MUST NOT be violated while they are in force.

Invariants MUST be explicitly listed and documented.

Invariants MUST apply across all layers of RCOS.

No decision, role, process, or emergency measure MAY override an invariant.

If a conflict arises between an invariant and any other rule, the invariant MUST prevail.

Invariants MAY only be changed or removed through a constitutional change process as defined in Layer 2 and Layer 6.

The community MUST declare any identity-level constraints that materially affect participation, behavior, or governance.

Identity constraints MAY include, but are not limited to:

• Ethical or behavioral boundaries
• Participation prerequisites
• Non-negotiable cultural or ecological constraints

Identity constraints MUST be testable and enforceable through defined processes.

Identity constraints MUST NOT be enforced implicitly or informally.

The following artifacts are mandatory for Layer 0 compliance:

• Purpose Charter
• Scope Declaration
• Invariants Register
• Identity Constraints Register

Layer 0 artifacts MUST be:

• Publicly accessible to all members
• Versioned
• Adopted through a formal ratification process

If Layer 0 artifacts are missing, ambiguous, or internally contradictory, the community MUST be considered non-compliant with RCOS-Core.

The community MUST define explicit membership states.

At minimum, the following membership states MUST exist:

• Applicant
• Trial / Probationary Member
• Full Member
• Exited Member

Each membership state MUST have clearly defined rights, obligations, and limitations.

No individual MAY hold multiple membership states simultaneously.

No rights or obligations MAY be assumed outside of the individual’s current membership state.

Entry into the community MUST follow an explicit onboarding process.

The onboarding process MUST include:

• Review of all RCOS-Core artifacts
• Explicit consent to Layer 0 and Layer 1 rules
• Declaration of initial membership state

Admission criteria MUST be explicit and documented.

Informal, implicit, or retroactive membership MUST NOT be permitted.

The community MUST define a probationary period for new members.

The probationary period MUST have:

• A defined duration
• Explicit evaluation criteria
• A clear transition decision process

During probation, rights MAY be limited but obligations MUST be explicit.

Failure to transition from probation MUST trigger a defined exit or extension process.

The community MUST explicitly define member rights.

The community MUST explicitly define member obligations.

Rights and obligations MUST be symmetrical and proportionate to membership state.

No obligation MAY be enforced without a corresponding, documented right.

Obligations MUST NOT be open-ended or undefined.

Participation expectations MUST be explicitly defined.

Acceptable forms of contribution MUST be listed.

Substitution of participation (e.g., outsourcing labor) MUST be explicitly governed.

Persistent non-participation MUST trigger an accountability process as defined in Layer 4.

Voluntary exit MUST be possible at all times.

Exit procedures MUST be explicit, documented, and non-punitive.

Forced exit MUST follow due process and be handled through Layer 4 mechanisms.

Exit MUST NOT result in loss of rights beyond those explicitly tied to membership.

Asset, role, and responsibility separation MUST be defined prior to exit.

The community MAY define temporary suspension states.

Suspension conditions MUST be explicit, time-bounded, and reviewable.

Suspension MUST NOT be used as an indefinite or punitive substitute for exit.

The following artifacts are mandatory for Layer 1 compliance:

• Membership Agreement
• Onboarding Protocol
• Exit & Separation Protocol
• Membership State Registry

Layer 1 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members

Absence, ambiguity, or systematic violation of Layer 1 artifacts MUST result in loss of RCOS-Core compliance.

All collective decisions MUST be classified into exactly one of the following decision types:

• Operational Decisions
• Strategic Decisions
• Constitutional Decisions

Operational Decisions concern day-to-day functioning and execution within existing rules.

Strategic Decisions concern long-term direction, allocation of significant resources, or creation/removal of major structures.

Constitutional Decisions concern changes to Layer 0 invariants, purpose, scope, or the governance system itself.

If a decision cannot be clearly classified, it MUST default to the higher-impact decision type.

Each decision type MUST have an explicitly defined decision-making mechanism.

Decision mechanisms MAY include, but are not limited to:

• Consent-based decision-making
• Majority vote
• Supermajority vote
• Delegated authority
• Randomized or rotational assignment

Decision mechanisms MUST specify:

• Eligible participants
• Decision thresholds
• Blocking or veto conditions, if any
• Time constraints

No informal or ad hoc decision mechanism MAY be used for collective decisions.

All authority MUST be assigned to explicitly defined roles, circles, or bodies.

Authority assignments MUST include:

• Scope of authority
• Limits of authority
• Duration or term, if applicable

No individual or body MAY exercise authority outside its explicitly assigned scope.

Authority MUST NOT be derived from charisma, seniority, ownership, or informal influence.

Temporary or emergency authority MUST be explicitly defined, time-bounded, and subject to review.

The community MUST maintain a Decision Matrix as a core governance artifact.

The Decision Matrix MUST map, at minimum:

• Decision type
• Decision domain
• Authorized role or body
• Decision mechanism
• Approval threshold
• Escalation path

The Decision Matrix MUST be publicly accessible to all members.

Decisions made outside the Decision Matrix MUST be considered invalid.

The community MUST define a Governance Protocol describing the full lifecycle of a decision.

The Governance Protocol MUST include:

• Proposal submission requirements
• Review and deliberation process
• Decision execution
• Documentation and publication
• Appeal and review mechanisms

The Governance Protocol MUST define how conflicts between decisions are resolved.

All governance actions MUST be documented according to Layer 5 documentation rules.

The governance system MUST include safeguards against:

• Concentration of decision power
• Informal vetoes
• Decision capture by subgroups
• Founder or role entrenchment

Governance mechanisms MUST allow for challenge and review without retaliation.

Persistent governance failures MUST trigger a formal review or constitutional process.

The following artifacts are mandatory for Layer 2 compliance:

• Decision Matrix
• Governance Protocol
• Authority Registry

Layer 2 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members

Absence, ambiguity, or systematic violation of Layer 2 artifacts MUST result in loss of RCOS-Core compliance.

All resources within the declared governed scope MUST be explicitly classified as either commons or private.

The community MUST maintain a single, explicit, and versioned registry of governed resources, including at minimum:

• Resource name or unique identifier
• Classification (commons or private)
• Steward or owner (as applicable)
• Access and use rules
• Transfer, sale, or privatization constraints (if any)

Any resource not explicitly classified MUST be treated as unclassified, and the community MUST NOT allocate, encumber, monetize, or transfer it until classification is completed through an authorized decision.

For commons resources, the community MUST explicitly define:

• Stewardship responsibilities
• The authorized decision-making body or role
• Maintenance obligations
• Funding or contribution mechanisms (if any)

For private resources, the community MUST NOT exercise authority beyond what is explicitly declared in the scope, membership agreements, or other governed artifacts.

The community MUST explicitly define which contribution categories are recognized. These MAY include, but are not limited to:

• Labor
• Care and emotional work
• Knowledge and education
• Stewardship and maintenance
• Administrative or coordination work

The community MUST define a contribution recognition mechanism specifying:

• What qualifies as a contribution
• How contributions are recorded or acknowledged
• Who may record, validate, or contest contributions
• Whether and how contribution recognition affects access to resources, privileges, or obligations

The community MUST NOT structurally depend on unpaid, invisible, or informal labor for system survival without explicitly defining corresponding obligations, recognition, or compensation mechanisms.

If internal economic units are used (e.g. time credits, points, tokens), the Internal Economy Protocol MUST define:

• Issuance rules
• Transferability rules
• Expiration, decay, or cap mechanisms (if any)
• Fraud prevention, dispute handling, and correction mechanisms
• Privacy and transparency rules for balances and transactions

Contribution recognition MUST NOT create implicit decision authority, veto power, or governance influence beyond what is defined in Layer 2.

The community MUST explicitly define which resources are held in the shared treasury and how treasury boundaries interface with private resources.

Income sources and any external income interfaces MUST be explicitly defined.

Spending authority MUST be explicitly bounded through:

• Clear authority assignments
• Thresholds by amount and/or category
• Approval and escalation paths
• Mandatory recordkeeping requirements

Transparency MUST be the default for treasury balances, inflows, outflows, obligations, and commitments.

Any exceptions to transparency MUST be explicitly defined, justified, time-bounded, and MUST NOT prevent members from auditing compliance.

The community MUST define reserve, risk, and liability policies, including:

• Limits on debt
• Long-term obligations
• Contingency reserves (if any)

Internal economic systems MUST prevent unbounded concentration of internal influence or control through resources, credits, or financial obligations.

If internal units exist, the community MUST define one or more accumulation-limiting mechanisms, which MAY include:

• Caps
• Decay or expiration
• Non-transferability
• Redistribution or taxation mechanisms
• Time-bounded validity

Economic mechanisms MUST NOT allow members to bypass governance authority boundaries defined in Layer 2, including through purchasing influence, creating dependency, or converting economic power into informal decision authority.

The community MUST define reviewable indicators of economic concentration risk and an explicit mechanism to adjust constraints when such risks are detected.

The following artifacts are mandatory for Layer 3 compliance:

• Internal Economy Protocol
• Treasury Ruleset

Layer 3 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members (with explicit, bounded exceptions)
• Adopted through an authorized governance process

The Internal Economy Protocol MUST define, at minimum:

• Contribution categories and recognition mechanisms
• Commons vs private boundaries and allocation rules
• Internal units (if any) and accumulation constraints
• External income interfaces (if any)
• Dispute resolution and correction mechanisms for economic records

The Treasury Ruleset MUST define, at minimum:

• Income sources
• Spending authority thresholds and approval paths
• Transparency and reporting requirements (including any bounded exceptions)
• Reserve, risk, and debt constraints
• Conflict-of-interest rules for spending and procurement

Shared resources, flows, and obligations MUST be visible to the community by default, with only limited and explicit exceptions.

Resources declared as commons MUST NOT be privatized through informal, implicit, or unilateral action.

Contribution recognition MUST be explicit such that unpaid or invisible labor is not structurally required for system survival.

Economic mechanisms MUST prevent indefinite concentration of internal influence.

The following MUST be explicit:

• Commons vs private classifications
• Allocation and access rules for shared resources
• Spending authority limits
• Transparency rules
• External income interfaces

The following MAY be explicit:

• Contribution valuation models
• Internal units (tokens, hours, points)
• Budget categories and internal accounting structures

The following MUST remain optional and out of scope:

• Attitudes toward wealth
• Equal vs differentiated outcomes
• Personal financial choices

The community MUST define an explicit conflict classification system that is known, accessible, and usable by all members.

At minimum, the classification system MUST include the following classes:

• Interpersonal conflicts (between individuals)
• Role-based conflicts (authority, responsibility, or mandate disputes)
• Structural conflicts (systemic incentives, rules, or resource allocation issues)
• Ethical or boundary violations (violations of declared norms, scope, or safety boundaries)

Each conflict class MUST explicitly define:

• Entry criteria (how a situation is classified into this class)
• Expected response priority and timelines (if any)
• Permitted and required resolution pathways
• Documentation requirements and privacy boundaries

Conflicts involving credible safety risks, coercion, abuse, or threats MUST be classified as safety-critical and MUST trigger elevated safeguards as defined in Section 6.3.

Misclassification or avoidance of classification MUST be treated as a process failure subject to review.

The community MUST define a minimum conflict resolution process applicable to all conflict classes.

The resolution process MUST include a clearly defined resolution ladder with explicit escalation steps.

The resolution ladder MUST define, at minimum:

• How a conflict is raised, logged, and acknowledged
• How involved parties are notified and invited to participate
• How refusal, non-response, or withdrawal is handled
• How mediators or facilitators are selected, replaced, or declined
• Time-bounded expectations for each stage (where applicable)
• Documentation requirements and access rules
• A process for reviewing procedural failures or deadlock

The resolution process MUST be accessible without requiring social status, seniority, charisma, or informal proximity to decision-makers.

Unresolved conflicts MUST escalate through defined governance pathways without bypassing the Decision Matrix defined in Layer 2.

The community MUST define explicit safeguards for conflicts involving power asymmetries, dependency relationships, or safety risks.

Safeguards MUST include protections against retaliation for:

• Raising a concern
• Requesting mediation
• Providing testimony or evidence
• Participating in a review or appeal

Where a power differential exists between parties, elevated safeguards MUST be applied, which MAY include:

• Independent or external facilitation
• Separate intake, documentation, or communication channels
• Temporary suspension or limitation of role authority
• Additional evidence and review thresholds prior to sanctions

For safety-critical conflicts, the community MUST define immediate protective actions that may be taken prior to full process completion, which MAY include:

• Temporary separation measures
• Restricted access to shared spaces or resources
• Temporary role suspension
• Emergency escalation timelines

Safety safeguards MUST override participation rights, role continuity, and operational convenience.

The community MUST define an explicit sanctions and repair framework.

Sanctions and repair actions MUST be:

• Proportional to the violation
• Explicitly documented
• Time-bounded where applicable
• Reviewable and appealable

The framework MUST define, at minimum:

• Available sanction and repair types
• Preconditions and evidence standards
• Authorized roles or bodies for application
• Review and appeal mechanisms
• Conditions for restoring rights, roles, or participation

Separation, suspension, or removal actions MUST follow due process and MUST align with exit and separation rules defined in Layer 1.

Sanctions MUST NOT be applied through informal exclusion, social pressure, silence, or implicit withdrawal of rights.

Repair-oriented actions MUST be prioritized over punitive actions except in safety-critical cases.

The following artifacts are mandatory for Layer 4 compliance:

• Conflict Resolution Ladder
• Accountability Protocol

Layer 4 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members, with clearly bounded privacy protections
• Adopted through an authorized governance process

The Conflict Resolution Ladder MUST define, at minimum:

• Conflict classification inputs and escalation thresholds
• Resolution stages and facilitator selection rules
• Documentation and information access boundaries
• Safety-critical exceptions and immediate safeguards

The Accountability Protocol MUST define, at minimum:

• Investigation, review, and decision mechanisms
• Due process guarantees and anti-retaliation protections
• Sanction and repair options with proportionality rules
• Appeals, oversight, and escalation paths
• Coordination with Layer 1 exit and separation processes

Conflict MUST be treated as a handled condition with defined pathways; ignoring, suppressing, or normalizing unresolved conflict MUST be considered a system violation.

Conflicts involving power asymmetries MUST trigger elevated safeguards.

Repair and restoration MUST precede punishment except where immediate safety is at risk.

Physical, psychological, and child safety MUST override participation rights, role continuity, and reputational concerns.

The following MUST be explicit:

• Conflict classification system
• Minimum resolution and escalation process
• Safeguards and anti-retaliation protections
• Sanction, repair, and separation thresholds

The following MAY be explicit:

• Mediation styles or methodologies
• Facilitator selection preferences beyond minimum safeguards
• Restorative or reparative practices

The following MUST remain optional and out of scope:

• Emotional expression norms
• Therapeutic, spiritual, or ideological framing of conflict

All ongoing responsibilities MUST be assigned to explicit, named roles rather than implicit expectations or informal agreements.

The community MUST maintain a Role Registry that includes, at minimum:

• Role name and purpose
• Scope of responsibility and decision authority
• Explicit boundaries and interfaces with other roles, circles, or domains
• Eligibility criteria (if any)
• Term length, rotation, or review conditions (if any)
• Appointment, review, and removal process

Each role MUST include an explicit accountability mechanism defining:

• How role performance is reviewed
• How underperformance, overload, or role failure is handled
• How handover and knowledge transfer occur

No ongoing responsibility MAY exist without an explicit role, and no person MAY be held accountable for responsibilities not formally assigned to a role.

Temporary or ad-hoc responsibilities MUST be explicitly time-bounded and MUST NOT become ongoing without formal role definition.

The community MUST define explicit meeting types sufficient to support:

• Operations
• Governance
• Coordination and alignment
• Reflection and learning
• Conflict handling (as required by Layer 4)

Each meeting type MUST define, at minimum:

• Purpose and decision scope
• Required vs optional participants
• Cadence and duration boundaries
• Facilitation role and selection or rotation process
• Agenda structure
• Documentation and publication requirements
• Decision capture requirements where decisions are made

Meetings MUST NOT exceed their declared decision scope or bypass authority boundaries defined in Layer 2.

Meeting load MUST be bounded, monitored, and reviewable as defined in Section 7.4.

The community MUST define explicit documentation rules for decisions, roles, operations, and shared obligations.

Documentation rules MUST specify, at minimum:

• What information MUST be recorded
• Where records are stored
• Who has access to which records
• Publication or notification timelines (if any)
• Privacy boundaries and conditions for restricted access

All decisions MUST be traceable to:

• Decision type and domain
• Authorized role or body
• Decision mechanism and threshold
• Recorded outcome and effective date

Critical operational processes MUST be documented such that continuity does not depend on tacit knowledge held by specific individuals.

Information flow MUST be designed to prevent gatekeeping, bottlenecks, or dependency on informal intermediaries.

Time, attention, coordination capacity, and emotional labor MUST be treated as finite and limited resources.

The community MUST define explicit workload boundaries, including:

• Limits on meeting load (frequency, duration, or total time)
• Limits on role load (number of roles, scope, or expected hours)
• Expectations for response times and availability (if any)
• Mechanisms for renegotiation, relief, substitution, or redistribution

Workload boundaries MUST be reviewable and adjustable through an authorized governance process.

Persistent overload, burnout risk, chronic non-participation, or dependency on over-functioning individuals MUST trigger review or repair processes as defined in Layer 4.

The community MUST ensure that no single individual is a critical single point of failure for core operations.

Core operational roles and processes MUST include:

• Documented procedures
• Clear handover mechanisms
• Backup or redundancy arrangements where feasible

Operational continuity planning MUST be reviewed periodically.

The following artifacts are mandatory for Layer 5 compliance:

• Operations Manual
• Role Registry
• Meeting Templates

Layer 5 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members, with clearly bounded privacy protections
• Maintained as living documents with defined ownership and review cycles

The Operations Manual MUST define, at minimum:

• Core operational processes relied upon by the community
• Interfaces between roles, domains, and meeting types
• Documentation locations and update procedures

Meeting Templates MUST define, at minimum:

• Agenda structure
• Notes and record format
• Decision capture format where applicable

Ongoing responsibilities MUST NOT exist without an explicit role.

Critical operational processes MUST NOT rely solely on individual memory, goodwill, or informal transmission.

Meeting load, coordination burden, and unpaid or invisible labor MUST be bounded and reviewable.

Information access rules MUST be explicit and enforceable.

The following MUST be explicit:

• Roles and responsibilities
• Operational authority boundaries and interfaces
• Meeting types and scopes
• Decision documentation rules
• Information access and privacy boundaries

The following MAY be explicit:

• Detailed meeting cadence beyond minimum constraints
• Tooling choices for documentation and coordination
• Role rotation or succession schedules

The following MUST remain optional and out of scope:

• Personal work styles
• Aesthetic or cultural preferences
• Informal social coordination

The community MUST define explicit change mechanisms for modifying, adding, suspending, or removing rules, roles, artifacts, or decision structures.

Change mechanisms MUST explicitly distinguish between:

• Permanent rule changes
• Time-bounded experiments as defined in Section 8.3

Every proposed change MUST specify, at minimum:

• The artifact(s), layer(s), and section(s) affected
• The decision type and authorized decision path as defined in Layer 2
• The intended effect, scope, and known risks
• The effective date and any transition period
• Migration requirements for existing roles, agreements, or records

Changes affecting Layer 0 purpose, scope, invariants, or identity constraints MUST be classified as constitutional changes and MUST follow the constitutional decision mechanism.

The community MUST define explicit review mechanisms for adopted changes, including how changes are evaluated, revised, or reverted when they produce harm, instability, or unintended concentration of power.

All adopted changes MUST be versioned and traceable.

The community MUST maintain a Version History that records, at minimum:

• Version identifier
• Adoption date and effective date
• Decision record reference (authority, mechanism, threshold)
• Summary of changes
• Migration notes and compatibility constraints (if any)

At any point in time, the community MUST be able to unambiguously determine:

• Which version is currently in force
• Which artifacts are authoritative for compliance

Superseded rules MUST remain accessible for auditability, learning, and dispute resolution, together with the dates during which they were in force.

No informal, undocumented, or “understood” rule changes MAY be considered valid.

The community MAY adopt experiments as explicitly time-bounded and reversible deviations, extensions, or pilots intended for learning.

Every experiment MUST define, at minimum:

• Scope (what is changed and what is explicitly not changed)
• Duration and review checkpoints
• Success and failure criteria
• Rollback conditions and rollback process
• Authorized decision path for starting, extending, modifying, or terminating the experiment

Experiments MUST NOT override Layer 0 invariants and MUST NOT bypass governance constraints defined in Layer 2.

Experiments MUST be explicitly labeled as experimental in all affected artifacts and MUST include a non-extendable expiration date unless renewed through an authorized decision.

If an experiment introduces safety risk, coercion, or sustained harm, the community MUST suspend or terminate the experiment immediately through a protective action, followed by post-hoc review.

Major failures, adaptations, reversals, and systemic learnings MUST be documented.

Learning capture MUST include, at minimum:

• What occurred and why it mattered
• Which layers, rules, or artifacts were implicated
• What was changed, attempted, or stopped
• What signals, evidence, or thresholds triggered action

Learning records MUST be accessible according to Layer 5 information access rules.

Repeated failure patterns MUST trigger structural review rather than individual blame.

The system MUST prefer reversible changes over irreversible ones where possible.

Irreversible or high-impact changes MUST include:

• Extended deliberation or review periods
• Higher decision thresholds where appropriate
• Explicit risk acknowledgment

Emergency changes MAY be permitted only where explicitly defined, MUST be time-bounded, MUST NOT override Layer 0 invariants, and MUST undergo mandatory post-hoc review and ratification or rollback.

The following artifacts are mandatory for Layer 6 compliance:

• Change Protocol
• Version History
• Learning Log

Layer 6 artifacts MUST be:

• Explicit and unambiguous
• Versioned
• Accessible to all members, with clearly bounded privacy protections
• Adopted through an authorized governance process

The Change Protocol MUST define, at minimum:

• How changes are proposed, reviewed, adopted, published, and rejected
• How proposals are classified by decision type
• Required contents of change proposals
• Transition, migration, and deprecation expectations
• Review, revision, and rollback mechanisms
• Emergency change provisions, including strict time bounds and mandatory review

The Version History MUST define:

• The authoritative structure for version identifiers and change logs
• How superseded versions are retained and accessed
• How the currently active version is determined

The Learning Log MUST define:

• What constitutes a learnable event
• Documentation format and ownership
• Review and synthesis cadence

Change MUST be possible but constrained; no change MAY be instantaneous, implicit, or unreviewable.

All adopted changes MUST be versioned, documented, and traceable.

Experiments MUST be time-bounded, explicitly labeled, and reversible.

Major failures and adaptations MUST be captured as shared learning, not erased or hidden.

The following MUST be explicit:

• How rules change and who decides
• Versioning, authority, and review processes
• Experiment scope, duration, and rollback conditions
• Emergency change conditions and limits

The following MAY be explicit:

• Review frequency and cadence
• Sunset clauses
• Feedback and sensing methods

The following MUST remain optional and out of scope:

• Pace of innovation
• Cultural attitudes toward risk within defined bounds

Optional Modules are domain-specific extensions that build on top of RCOS-Core without modifying its mandatory layers.

Optional Modules MUST:

• Declare which RCOS layers they extend or depend on
• Explicitly state any additional roles, rules, or artifacts they introduce
• NOT override or contradict Layer 0 invariants or RCOS-Core requirements

Optional Modules MAY define:

• Domain-specific practices
• Additional constraints or standards
• Specialized governance or operational patterns

Typical Optional Module domains MAY include, but are not limited to:

• Permaculture and regenerative land stewardship
• Alternative or community-based education systems
• Health, care, and well-being practices
• Cultural or spiritual practices
• Economic specializations (e.g. cooperatives, land trusts, mutual credit)

Adoption of Optional Modules MUST follow the change mechanisms defined in Layer 6.

A community MAY be RCOS-Core compliant without adopting any Optional Modules.

A Reference Implementation is a real-world community that publicly documents how it applies RCOS-Core.

Reference Implementations are descriptive, not prescriptive. They illustrate how RCOS can be instantiated, not how it must be instantiated.

A community MAY claim to be an RCOS Reference Implementation only if it:

• Is RCOS-Core compliant
• Publicly documents its Layer 0–6 artifacts
• Clearly indicates deviations, experiments, or extensions

Reference Implementation documentation SHOULD include:

• Context and scale (size, location, purpose)
• Which Optional Modules are adopted
• Known challenges and failures
• Evolution history and major adaptations

Reference Implementations MUST NOT be treated as authoritative interpretations of the standard.

Known Failure Modes document recurring breakdown patterns observed in real communities.

Failure Modes are informative signals, not compliance criteria.

Failure Modes MAY include, but are not limited to:

• Informal power accumulation
• Founder or land-owner dominance
• Invisible or gendered labor dependency
• Governance paralysis or meeting overload
• Exit blockage or soft coercion
• Economic capture through debt or asset control
• Conflict avoidance leading to silent fragmentation

The purpose of documenting Failure Modes is to:

• Support stress-testing of RCOS structures
• Improve design decisions
• Enable early detection in live communities

Failure Mode documentation SHOULD reference which RCOS layers are intended to mitigate the pattern.

RCOS-Core compliance is binary: a community is either compliant or non-compliant.

Compliance MUST be evaluated per layer (Layers 0–6).

For each layer, the Compliance Checklist MUST verify:

• Presence of mandatory artifacts
• Explicitness and accessibility of required rules
• Adoption through authorized governance processes

Partial compliance or “intent to comply” MUST NOT be considered compliant.

Optional Modules MUST NOT be included in RCOS-Core compliance evaluation.

Test Cases are structured scenarios used to validate whether RCOS mechanisms behave as intended.

Test Cases MAY be:

• Hypothetical scenarios
• Historical community failures
• Simulated stress tests

Test Cases SHOULD cover, at minimum:

• Power concentration attempts
• Exit and separation scenarios
• Governance deadlock
• Economic capture attempts
• Safety-critical conflicts

Test Cases are informative but SHOULD be used during audits, onboarding, and periodic reviews.

A community MUST be considered non-compliant if:

• Any mandatory artifact is missing
• Layer 0 invariants are violated
• Decisions are repeatedly made outside authorized governance structures
• Exit is blocked or informally constrained

Non-compliance MUST be explicitly acknowledged once detected.

A community MAY regain compliance only through:

• Corrective action
• Formal adoption of missing or corrected artifacts
• Documentation of remediation

Claims of RCOS compliance MUST be withdrawn during periods of known non-compliance.

RCOS MUST have an identifiable stewarding body or process.

The steward’s responsibilities MUST include:

• Maintaining the canonical specification
• Managing version releases
• Curating reference materials and learning
• Protecting Layer 0 invariants of the standard itself

The steward MUST NOT act as an enforcement authority over communities.

RCOS stewardship MUST prioritize clarity, stability, and real-world learnings over ideological purity.

Changes to RCOS-Core MUST follow a defined change process.

The change process MUST include:

• Proposal submission
• Public review and feedback period
• Decision mechanism and authority
• Versioning and publication

Backward compatibility SHOULD be preserved where possible.

Breaking changes MUST be clearly marked and justified.

Superseded versions of RCOS MUST remain publicly accessible.

RCOS itself MUST model the same principles it requires of communities: explicitness, bounded authority, reversibility, and learning.