Governance Versioning and Stewardship

Governance, Versioning & Stewardship

Status: Complete · The authority signals that separate a framework from a pile of essays — kept deliberately lightweight, because anti-bureaucracy is a value, not an accident.

A framework earns the word framework by being more than good writing. It needs three things a pile of essays does not have: someone accountable for it, a way to tell which version you are reading, and a defined path for changing it. Without those, "the canon" is just whatever the last loud edit happened to say.

SAE has all three. It also has a standing rule: govern the framework the way SAE tells you to govern software. That means the lightest possible ceremony that still produces accountability — ceremony scales with Context Entropy, not with calendar. Most changes to this wiki are low-entropy and move fast. A change to a First Principle is high-entropy and moves slowly, on purpose. The governance here is the framework eating its own cooking.

---

Stewardship

The SAE Framework is maintained by Sanjeev Azad and contributors.

Property	Value
Steward	Sanjeev Azad, with contributors
License	MIT
Home	Open on GitHub — repository (README, license, canonical docs) and the wiki (the living playbook)
Canon	The SAE Guide, governed by the version scheme below

MIT licensing is not decoration. It is the mitigation for the single-maintainer risk discussed in the Reality Check below: the canon is version-controlled and openly licensed, so the framework can outlive any one steward.

---

How the framework is versioned

The canon uses a semantic scheme — the same MAJOR.MINOR.PATCH shape developers already know, applied to ideas instead of code. The trick is mapping each digit to a class of change to meaning, so the version number tells you how much your understanding has to move.

Bump	Triggered by	Meaning for the reader
MAJOR	A change to a First Principle (P1–P7) or a non-negotiable	The spine moved. Re-read what you thought you knew.
MINOR	A new page, practice, or role clarification	Additive. Nothing you relied on broke; there's more.
PATCH	Wording, examples, typos, fixes	Cosmetic or corrective. Same meaning, said better.

Concrete examples of each:

• MAJOR (e.g. 1.0.0 -> 2.0.0) — Renumbering or rewording P3 from "the writer never judges its own work" to a different independence model; demoting one of the five non-negotiables; adding an eighth First Principle. Anything that changes what SAE is.
• MINOR (e.g. 1.0.0 -> 1.1.0) — Publishing a new Scenario Playbook; adding a fifth role to the Digital Org Chart; clarifying the boundary between Engineer and Guardian. New surface area, stable spine.
• PATCH (e.g. 1.0.0 -> 1.0.1) — Fixing a broken cross-link; correcting a metric formula in KPIs and Metrics; sharpening a sentence in the Manifesto without changing its claim; replacing a weak example with a stronger one.

The test for a MAJOR bump is blunt: would someone who learned SAE last month now be wrong? If yes, it is MAJOR. If they would merely be missing something, it is MINOR. If they would be right but could have said it cleaner, it is PATCH. This mirrors P5 — Gate the irreversible by blast radius: the bigger the blast radius of the change, the heavier the gate.

---

How the canonical SAE Guide is amended

The SAE Guide is the source of truth, so it gets the framework's own discipline applied to it — P2: the spec is the source of truth, turned on the framework itself. The path is short by design:

1. Propose — Open a GitHub issue or pull request. State the change and which class it is (MAJOR / MINOR / PATCH) and why.
2. Review against First Principles — The proposal is checked against P1–P7. A change that contradicts the spine is rejected or escalated to a MAJOR. This is the Guardian role applied to the doctrine: the proposal must survive refutation, not just sound good.
3. Version bump — On acceptance, the version increments per the scheme above.
4. Log — The change is recorded in the Revision Log so the canon's history is auditable, not folklore.

No mandated meeting. No certification gate. No fixed reviewer roster. Just propose, refute against the spine, bump, log — the smallest loop that still produces accountability.

Reality check. Every new claim added to the canon must ship with its own Reality Check (P7 — honest by construction). A proposed page or practice with no stated failure mode, no honest disclosure of what it does not do, is incomplete by definition and will be sent back. "Honest by construction" is not a slogan we apply only to features; it is the acceptance criterion for the framework's own pages.

---

Revision Log

Version	Date	Class	Change
1.0.0	2026-05-29	Initial canon	First published canon: the Manifesto, First Principles (P1–P7), Modules 1–5, the End-to-End Lifecycle, Best Practices, KPIs and Metrics, and this governance model.

The log grows downward. Every accepted amendment adds a row, so the version you are reading always has a traceable lineage back to 1.0.0.

---

How to contribute

Contribution is a first-class activity, not a favor. The full mechanics — where wiki edits land, how repository changes go through pull request, what the framework is actively looking for — live in the Contribution Guidelines. The short version: wiki pages are edited via Git in the wiki repository; structural and licensing changes go through a pull request against main.

Bring tooling scored against the rubric, real Solo Production Case Studies, sharper diagrams, or honest Reality Checks. The one universal rule, restated: a new claim without a Reality Check does not ship.

---

Reality check. Single-maintainer governance is itself a bus-factor — the same risk SAE warns about in any solo system. One steward is a single point of failure for the canon's direction, and pretending otherwise would violate P7. The mitigation is structural, not heroic: the framework is MIT licensed and the canon is version-controlled and public. If the steward disappears, anyone can fork the repository and the wiki, keep the version history intact, and continue the line. The license plus the versioned canon mean the framework's survival does not depend on any one person — which is exactly the property SAE asks every operator to engineer into their own work (P6 — you own the output).

---

See also: The SAE Guide · First Principles · Contribution Guidelines · The Verification Doctrine · The SAE Manifesto