Layer 6 defines how the system evolves without collapsing.
Its purpose is to ensure that change is deliberate, constrained, reversible where appropriate, and produces learnings rather than hidden damage. Evolution under RCOS is treated as a governed process, not as improvisation.
8.1 Change Mechanisms
8.1.1 The community MUST define explicit change mechanisms for modifying, adding, suspending, or removing rules, roles, artifacts, or decision structures.
8.1.2 Change mechanisms MUST explicitly distinguish between:
- Permanent rule changes
- Time-bounded experiments as defined in Section 8.3
8.1.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
8.1.4 Changes affecting Layer 0 purpose, scope, invariants, or identity constraints MUST be classified as constitutional changes and MUST follow the constitutional decision mechanism.
8.1.5 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.
8.2 Versioning and Authority
8.2.1 All adopted changes MUST be versioned and traceable.
8.2.2 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)
8.2.3 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
8.2.4 Superseded rules MUST remain accessible for auditability, learning, and dispute resolution, together with the dates during which they were in force.
8.2.5 No informal, undocumented, or “understood” rule changes MAY be considered valid.
8.3 Experiments
8.3.1 The community MAY adopt experiments as explicitly time-bounded and reversible deviations, extensions, or pilots intended for learning.
8.3.2 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
8.3.3 Experiments MUST NOT override Layer 0 invariants and MUST NOT bypass governance constraints defined in Layer 2.
8.3.4 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.
8.3.5 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.
8.4 Learning and Feedback Capture
8.4.1 Major failures, adaptations, reversals, and systemic learnings MUST be documented.
8.4.2 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
8.4.3 Learning records MUST be accessible according to Layer 5 information access rules.
8.4.4 Repeated failure patterns MUST trigger structural review rather than individual blame.
8.5 Change Safety and Reversibility
8.5.1 The system MUST prefer reversible changes over irreversible ones where possible.
8.5.2 Irreversible or high-impact changes MUST include:
- Extended deliberation or review periods
- Higher decision thresholds where appropriate
- Explicit risk acknowledgment
8.5.3 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.
8.6 Artifacts
8.6.1 The following artifacts are mandatory for Layer 6 compliance:
- Change Protocol
- Version History
- Learning Log
8.6.2 Layer 6 artifacts MUST be:
- Explicit and unambiguous
- Versioned
- Accessible to all members, with clearly bounded privacy protections
- Adopted through an authorized governance process
8.6.3 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
8.6.4 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
8.6.5 The Learning Log MUST define:
- What constitutes a learnable event
- Documentation format and ownership
- Review and synthesis cadence
8.7 Layer Invariants
8.7.1 Change MUST be possible but constrained; no change MAY be instantaneous, implicit, or unreviewable.
8.7.2 All adopted changes MUST be versioned, documented, and traceable.
8.7.3 Experiments MUST be time-bounded, explicitly labeled, and reversible.
8.7.4 Major failures and adaptations MUST be captured as shared learning, not erased or hidden.
8.8 Explicitness Rules
8.8.1 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
8.8.2 The following MAY be explicit:
- Review frequency and cadence
- Sunset clauses
- Feedback and sensing methods
8.8.3 The following MUST remain optional and out of scope:
- Pace of innovation
- Cultural attitudes toward risk within defined bounds