Decision Records: Governance Memory
|
CYCLE Calibration position — Active Development This page is a conceptual instrument under Permanent Beta. It declares a real calibration position, not a finished product waiting to ship. Checking continues; an edit is only required when evidence demands it. Stage: Seed to Fruit. Feedback welcome — especially clarity, failure modes, and calibration gaps. Use discussion or Contribute. |
Meta
Decision Records: Governance Memory
| Type | Meta & Framework |
|---|---|
| Functional Layer | |
| Application Layer | Framework Infrastructure |
| Category | Meta & Framework |
| Version | 0.2 |
| Maturity | Development |
| Last Calibration | 2026-07-14 |
| Status | Permanent Beta |
| Description | Defines what a Decision Record is, when one is required, where it lives, and how to write one — the governance memory layer explaining why rules exist, not just what they are. |
Menu
Core Principles
- Reality gets final vote
- See the Game. Refuse the Game. Build Better.
- Permanent Beta
Navigation
Related
Decision Records: Governance Memory
Calibration Reports and Calibration Logs record how a page's content and status changed. Decision Records record why a governance rule, taxonomy category, or structural convention exists in its current form — including the alternatives that were rejected and why. The purpose of a Decision Record can be stated in one question: was this actually considered, or just never questioned? Without an answer to that question preserved somewhere, a future contributor who disagrees with a rule has no way to tell the difference.
Decision Record Principles
These are not procedures — they are the philosophy the procedures below exist to serve. A Decision Record should:
- Preserve reasoning, not advocate for it.
- Record rejected alternatives fairly enough that a future contributor can understand why they were attractive in the first place.
- Distinguish observed facts from judgment calls.
- Make later recalibration possible rather than freezing debate.
- Be concise enough that future contributors will actually read it.
A Decision Record documents governance reasoning, not objective truth. Its existence means "we know why we currently do this" — not "this debate is closed forever." Treating a Decision Record as evidence a matter can no longer be questioned would itself be a Reality Override pattern.
What a Decision Record Is
A Decision Record captures, for one specific structural decision:
- A unique ID
- What was decided
- Significant contributors to each position taken (not necessarily every participant)
- What alternatives were considered and rejected, and specifically why
- The consequences of the decision — what else it affects or requires
- Current status
- Date
When a Decision Record Is Required
Trigger test: Would a future contributor reasonably ask "why does this rule exist?" if they read only the current page, with no other context? If yes, a Decision Record is required. If the change is wording, sequencing, formatting, or a correction of an actual error, it is not.
Concretely, required when a change:
- Establishes, renames, or retires a taxonomy category or Type.
- Adopts or rejects a proposed rule, threshold, or formula.
- Resolves a genuine disagreement between contributors or reviewers, especially one where the losing position had real merit worth preserving.
- Changes a structural convention other pages are expected to follow.
Not required for: typo fixes, rewording for clarity, routine field updates, or anything already fully explained by a normal Calibration Report.
Where Decision Records Live (Hybrid Model)
1. Central Index — Decision Records: Governance Memory/Index A single, chronological, scannable list of every Decision Record, by ID. Each entry: ID, date, short title, page(s) concerned, link to full record. Browsing/search only — never long-form content.
2. Per-Page Subpages — `PageName/Decision Records` (naming locked: matches `/Calibration Log` convention exactly) Full content lives on a subpage attached to the governance page it primarily concerns.
For decisions spanning multiple pages: the record lives on whichever page is most directly responsible for enforcing the decision, with a cross-reference added to other pages involved, and the Index entry notes all affected pages.
ID Format
Every Decision Record receives a sequential ID: DR-0001, DR-0002, DR-0003..., assigned in the order created, never reused even if a record is later superseded or rejected. Pages may reference a decision by ID alone (e.g. "see DR-0004") once the record exists, rather than restating its full title.
How to Write a Decision Record
=== DR-XXXX: [Short, specific title] === '''Decision:''' [What was actually decided — one sentence] '''Status:''' Proposed / Adopted / Superseded / Rejected / Open — Unresolved '''Significant contributors:''' [Major positions and who held them — not necessarily every participant] '''Reasoning:''' [Why the adopted position won] '''Alternatives considered:''' [What else was proposed, and specifically why it was set aside] '''Consequences:''' [What this decision requires or affects elsewhere — other pages, future conventions, follow-up work] '''Date:''' YYYY-MM-DD '''Superseded by:''' [DR-XXXX, date — only if applicable]
"Open — Unresolved" is a valid, complete status — not every decision needs forced closure. A deliberately preserved disagreement (see the severity/disclosure tension in Standards: Types and Calibration Obligations) is a complete record on its own; the record's job is to preserve reasoning on both sides, not manufacture resolution. See Breadcrumb Philosophy.
Superseding a Decision Record: never delete or overwrite a superseded record's content. Mark its status "Superseded," add the superseding record's ID and date, and leave the original content fully intact as historical record — consistent with the append-only principle used throughout this project (Talk page Calibration Reports, page history).
Relationship to Other Mechanisms
| Mechanism | Question Answered |
|---|---|
| Versioning | When did it change? |
| Calibration Report | How did it change? |
| Calibration Log | What's its current calibration state? |
| Decision Record | Why does this rule exist? |
| Breadcrumb | What is still unresolved? |
Decision Records are historical, like Calibration Reports — but narrower: a Calibration Report documents one review pass on one page; a Decision Record documents one structural decision, possibly debated across multiple passes, pages, or contributors before resolving (or deliberately not resolving).
Worked Precedent
Standards: Types and Calibration Obligations/Decision Records predates this page and should be treated as the de facto first per-page Decision Records subpage — retroactively conforming to this standard (adding IDs, Consequences fields, and updated Status values) is a follow-up task, not required immediately.
See the Game. Refuse the Game. Build Better.
Page Transparency & Calibration
- Calibration Log & Decision Records (via Talk Page) — This page uses Talk-only calibration tracking. Full history of reviews, version changes, calibration decisions, and any governance reasoning behind structural decisions all live on the same Talk page, per Calibration Log: When to Create One and Decision Records: Governance Memory. Not every Calibration Log entry is a Decision Record — scan the Talk page's headings for entries specifically marked as decisions; the link itself being active only confirms this page has calibration history, not that a formal decision was ever recorded.
- View Current Page History — Complete edit history.
This page is under continuous calibration in line with the Permanent Beta principle.
Public Discussion Welcome
Questions, suggestions, feedback, disagreement, and proposed improvements are welcome on the Talk page.
Light rules:
- Prefer evidence and concrete examples over slogans.
- Apply Diagnostic Inversion Test when criticizing — the same standard to this page that you would apply elsewhere.
- Distinguish observation from conclusion.
- Calibration entries and Decision Records are maintenance records; public discussion belongs in ordinary Talk threads.
- This framework remains in Permanent Beta. Better calibration is always in scope.
Calibration References
This page is calibrated against the following core standards and reference materials:
- The Sovereign Games Framework — Overall framework philosophy and operating principles
- Permanent Beta — Core maintenance and continuous improvement standard
- Reference Standards — Principles for traceable, confirmed standards
- Calibrating Conceptual Instruments — Methodology for evaluating and refining pages
- Civilizational Traceability Hierarchy — How standards should connect to reality across levels
- Diagnostic Inversion Test — Mandatory self-application standard
- Reality Game — Foundational reality-alignment tool
- Reality Override Game — Standing discipline against protecting an existing model rather than updating it
- Observable Behavior Rule — Standing principle that diagnostics evaluate observable actions, mechanisms, and consequences, not internal motive, belief, or intent
- One-Way Nature of the Sovereign Games — Anti-capture design principles
- The Royal Cubit Civilization (Strategy) — Long-term civilizational vision and metrology metaphor
- Conceptual Instruments — Overall direction and metrology metaphor
- Breadcrumb Philosophy — Standing discipline for making unresolved questions and provisional decisions explicit
- Calibration Dependencies: Standards and Process — Rule that visible and hidden dependency lists must match, and that dependencies describe genuine reliance
Calibration Dependent
Pages that list this page as a load-bearing dependency:
| Page | Priority | Instrument Grade | Last Updated | Cycle Status | Drift Status |
|---|---|---|---|---|---|
| Insights and Future Layers | Core | Experimental | 2026-07-14 | Current | Breadcrumb-Open |
| Calibration Report Standard Format | Core | Experimental | 2026-07-20 | Current | Breadcrumb-Open |
| Decision Records: Governance Memory/Index | Core | Development | 2026-07-14 | Current | Breadcrumb-Open |
| Standards: Types and Calibration Obligations | Core | Development | 2026-07-20 | Current | Breadcrumb-Open |
| Page Structure Calibration Checklist | Core | Development | 2026-07-14 | Current | Breadcrumb-Open |
| Calibration Failure Log | Supporting | Experimental | 2026-07-24 | Current | Breadcrumb-Open |
| Standards: Types and Calibration Obligations/Decision Records | Supporting | Development | 2026-07-14 | Current | None open |
If this page is edited substantively, review the list above per the Ripple Review rule — see Calibration Dependencies: Standards and Process#Rule: Core-Priority Changes Trigger Mandatory Ripple Review.
Calibration Dependencies
Pages this page relies on as load-bearing dependencies: Breadcrumb Philosophy • Calibration Log: When to Create One • Calibration Report Standard Format • Page Structure Calibration Checklist If incorrect, edit the `depends_on` field in Admin Page Status — do not edit this section directly, it is auto-generated.