Version History
The authoritative human-readable record of all adopted changes to your community's RCOS implementation. The currently active version is the most recent entry at the top of this file. Superseded rules remain accessible via version control.
Download this template
Generated 2026-08-31 · Download all templates
Entry Format
What do we record about each version of our rules, so anybody can trace what changed?
RCOS clauses 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.6.4, 8.7.2
- 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:
- 8.2.3 At any point in time, the community MUST be able to unambiguously determine:
- 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.6.4 The Version History MUST define:
- 8.7.2 All adopted changes MUST be versioned, documented, and traceable.
Why record every adopted change?
Governance that cannot point to "what changed, when, and why" is indistinguishable from governance by whoever speaks loudest. A single append-only ledger of adopted changes — with the superseded versions preserved in version control — makes the current state of the rules unambiguous and gives members, auditors, and future stewards a way to reconstruct the path that got us here.
How to fill this in
Use the entry template below for every adopted change. New entries are prepended above the most recent. Do not edit historical entries — corrections are recorded as new entries.
## <version> — <Short title>
- **Effective date:** <YYYY-MM-DD>
- **Decision record:** <link to decision record>
- **Decision type:** <Operational / Strategic / Constitutional>
- **Mechanism:** <vote mechanism / delegated authority>
- **Summary:** <one to three sentences describing what changed.>
- **Layers affected:** <e.g. Layer 2, Layer 5>
- **Artifacts changed:** <list of artifacts>
- **Migration notes:** <any transition rules; "none" if not applicable>
What to cover
- How are versions numbered, and what makes the number change?
- What does every entry record — version, adoption date, effective date, the decision it came from, a summary, and any migration notes?
- How can anyone tell which version is in force today, and which documents count as the official ones?
- Where are earlier versions kept, and how can someone see the dates each one applied?
- How is a mistake in an old entry corrected without editing it?
Examples
Each version gets a number like 2.3: the first number goes up for Constitutional changes, the second for all others. Every entry records the version, adoption and effective dates, the decision reference with its mechanism and threshold, a short summary and any migration notes, newest first. The top entry is the version in force, and only documents in the "current" folder count. Earlier versions stay in the archive with the dates they applied, and mistakes are corrected with a new entry, never by editing an old one.
Examples, not recommendations. Your answers will be your own.
Current Version: v0.0 — Repository Initialized
- Effective date: <YYYY-MM-DD>
- Decision record: N/A — initial scaffold
- Decision type: N/A
- Mechanism: N/A
- Summary: Templates initialized. All artifacts are templates — no rules are yet adopted.
- Layers affected: All (scaffold only)
- Artifacts changed: All files created as templates
- Migration notes: None — initial state
New entries are prepended above this line.