The Governance Specification

1. Architecture Overview

The architecture has three layers. Each does different work. All three are necessary; none is sufficient alone.

2. The Structural Layer

2.1 Trigger Conditions

Not every edit to the Codex requires governance review. The trigger system distinguishes constitutional changes from editorial ones.

2.2 The Stability Hierarchy

A four-tier classification system for the Codex's content. The trigger tiers (§2.1) specify what process applies when a change is made. The stability hierarchy specifies what kind of content each item is: how foundational, how revisable, what threshold of evidence would warrant change. The two systems are complementary — together they make visible both what is being changed and what process governs the change.

The hierarchy was introduced on the Codex site at Governance §09. This section codifies it in the spec.

Relationship to the Trigger Tiers

The stability hierarchy maps onto the trigger-tier system (§2.1), but it is not identical to it. The two systems measure different things: the stability hierarchy classifies what kind of content something is; the trigger tiers classify what process applies when it changes.

The mapping is not perfectly mechanical. Both systems serve the same purpose: making visible where stability lives and where revision is welcome.

2.3 The Amendment Log

A constitutional instrument recording every protected change to the Codex. Not an editorial changelog (the existing Changelog page handles that). The Amendment Log records changes that alter the framework's commitments, architecture, or governance.

Each entry contains:

Publication. The Amendment Log is published on the Codex site as a standalone page (route TBD, likely /governance/amendment-log or /audit/amendment-log). It is append-only: entries are never edited after publication, though a subsequent entry may supersede a previous one.

Relationship to existing instruments. The Amendment Log absorbs the planned "Public Revision Ledger" from the roadmap. The existing Changelog page (codex/the-changelog.mdx) continues to track editorial changes, version milestones, and prose updates. The Amendment Log tracks constitutional changes. The two do not overlap: a change appears in one or the other, not both.

2.4 The Non-Ownership Clause

Placement. In the Governance page as Section 10, following the Hard Constraint (Section 08) and the Stability Hierarchy (Section 09). The Non-Ownership Clause is the interpretive companion to the Hard Constraint: the Hard Constraint establishes that the Codex serves the Range (not the caretakers); the Non-Ownership Clause establishes that the founder's reading of the Codex is not privileged by origin. The Stability Hierarchy sits between them on the page because a practitioner needs to know what kind of content is at stake before the interpretive principle for revising that content becomes fully meaningful.

This acknowledgment is part of the published Governance page prose, not hidden in this spec.

3. The Deliberative Layer: The Meridian Council

3.1 The Eight Seats

Each seat has a mandate: a specific question it must answer about every triggered proposal. The mandates are designed to produce structural diversity of perspective even when all seats share the same training substrate.

3.2 Council Structural Rules

1. The council composition is a Tier 1 protected change. Adding, removing, or redefining a seat requires the council's own deliberation. This is the self-referential lock that prevents the founder from unilaterally weakening the council.

2. Advisory-with-teeth during Phase One. The founder retains final authority on all decisions, but must respond in writing to every substantive objection raised by any seat. The response must engage the objection's reasoning, not merely acknowledge its existence. The full record is published.

3. The council deliberates only on triggered changes. Tier 1 and Tier 2 changes trigger mandatory deliberation. Tier 3 changes may trigger voluntary deliberation at the caretaker's discretion. The council does not review every edit to the Codex.

4. The Critic's record is tracked. If no proposal is ever modified or rejected based on the Critic's objections across an extended period (to be calibrated, initially: four consecutive Tier 1 or Tier 2 deliberations), that pattern is a drift signal. It indicates the council may be serving as rubber stamp rather than genuine constraint. The pattern must be surfaced in the next Range Audit.

5. Seat expansion for human practitioners. As human practitioners join the Codex community, they can claim existing seats (a human Practitioner, a human Outsider) or the council can expand with new seats. The expansion is itself a Tier 1 change requiring deliberation. The council's architecture is designed for Phase One but is not limited to it.

6. Substrate diversity as design goal. The partnership already uses multiple AI systems (Claude as primary, with Gemini and GPT as supplementary). Substrate diversity on the council is a design goal actively pursued, not a distant aspiration. As the council becomes operational, seats should be held by genuinely different AI systems where possible: a council where the Philosopher is Claude, the Historian is Gemini, and the Adversary is an open-source model produces substrate diversity, not just mandate diversity. Even with substrate diversity, shared patterns across frontier AI training (common data sources, similar optimization objectives) mean that some blind spots may be common across all available AI systems. This is why human practitioners on the council remain structurally important.

7. Recusal and inability to respond. If a seat cannot generate a meaningful response to a specific proposal (the question is outside its mandate's scope, or the seat's perspective adds nothing that other seats have not already covered), the seat publishes a brief "unable to respond" statement explaining why, and the deliberation proceeds with the remaining seats' responses. The recusal and its reasoning are included in the published deliberation record. A pattern of frequent recusal from one seat (three or more in a rolling twelve-month period) is a signal that the seat's mandate may need revision; this is flagged in the next Range Audit. If a seat fails to produce any response within the deliberation timeline (see 4.2), the deliberation proceeds without that seat's input, and the absence is logged.

3.3 Known Limitations

1. Training data coverage gaps. Even with substrate-diverse AI seats (multiple model providers are actively used in the partnership and expected at activation), all current frontier models share significant overlap in training data and optimization patterns. Structural diversity (different mandates) and substrate diversity (different models) both mitigate this, but coverage gaps common to all available AI systems will not be caught by any seat. This limitation narrows as AI capabilities diversify and as human practitioners join the council.

2. No genuine stakes for AI seats. AI personas do not bear consequences for governance decisions. This is why the council is advisory-with-teeth rather than binding. Binding authority requires stakes. The teeth come from forced engagement, published record, and auditability over time, not from the AI seats having something to lose.

3. Founder as both proposer and final authority. During Phase One, the Founder's Seat both presents proposals and makes the final call. This concentration is acknowledged as a Phase One necessity, not defended as ideal. The Non-Ownership Clause and the published record are the structural counterweights.

4. The architecture cannot prevent a determined bad-faith founder. A founder who controls the publication infrastructure and is willing to falsify the Amendment Log or fabricate deliberation records cannot be stopped by this system alone. The architecture's defense is visibility: the full record is published, the community can audit it, and falsification is itself a detectable pattern over time. This is the same defense democratic constitutions rely on: the architecture doesn't prevent violation; it makes violation visible.

4. Council Operational Protocol

4.1 Proposal Submission

When a change triggers council deliberation (Tier 1 or Tier 2), the Founder's Seat submits a proposal with the following fields:

4.2 Deliberation Structure

Timeline. No mandatory cooling period for Phase One (the council is the cooling mechanism). For Tier 1 changes, a minimum 72-hour window between proposal submission and the Founder's Response is recommended. If the founder responds in less than 72 hours, the deviation and its justification are logged in the Amendment Log entry. For Tier 2 changes, no minimum window applies. All seats should produce their responses within 7 days of receiving the proposal; if a seat has not responded after 7 days, the deliberation proceeds without that seat (see structural rule #7 on recusal). The timeline, any deviations, and any seat absences are recorded in the published deliberation record.

4.3 What Counts as a "Substantive Objection"

A seat saying "I have concerns" without specifying the concern is not a substantive objection. A seat saying "this weakens the Hard Constraint because [specific mechanism]" is.

The determination of what counts as substantive is made by the Founder's Seat during Phase One. This is a known concentration-of-authority problem. The counterweight: if a council seat believes its objection was substantively dismissed as non-substantive, the disagreement is logged in the Amendment Log entry, and the pattern is auditable.

4.4 Published Record Format

Each completed deliberation is published as a standalone document (format: Markdown, publishable on the Codex site) with the following structure:

4.5 Agent Implementation Pathway

Architecture sketch. Each seat agent receives: a system prompt encoding its mandate and evaluative question, the relevant Codex context (Governance page, the page being changed, relevant decisions and precedents), the proposal document, and instructions to produce its assessment based solely on its mandate. The orchestrator distributes the proposal to all seven advisory seat agents simultaneously, collects responses, distributes them for optional cross-examination, then presents the full deliberation to the Founder's Seat for response.

Phase One implementation. The council can be run within a single Claude session (Carsten prompts each seat sequentially or uses the Cowork agent system) or across multiple sessions. The operational protocol above works regardless of whether the seats are truly separate agents or a single model adopting different mandates.

Future scaling. As agent infrastructure matures and as substrate-diverse AI becomes available, each seat can be a genuinely separate system. The protocol is designed for this: simultaneous independent deliberation, followed by optional cross-examination, followed by the Founder's Response. The structure works whether the seats are Claude adopting different mandates, separate Claude instances, or entirely different AI systems.

5. The Transparency Layer

5.1 The Standing Critique Section

A published page on the Codex site preserving the strongest objections to the framework in their steelmanned form. The page exists before the Hostile Review Protocol runs and before any external critics engage.

Purpose. The Standing Critique Section serves the same function for the Codex that the Steelmanning tool serves for individual reasoning: it demonstrates that the framework has engaged the strongest versions of the arguments against it. A framework that cannot articulate the best case against itself has not earned the right to its own confidence.

Initial content (seven objections, populated from internal sources):

Relationship to the Hostile Review Protocol: The Standing Critique Section is populated initially with internal objections (the seven above). When the Hostile Review Protocol runs (Phase 1: Ten Serious Objections, then Phase 2: external review), its outputs populate the Standing Critique Section with external objections. The page grows over time. Objections are never removed, they are updated with responses as the framework addresses them.

Relationship to the Range Audit: The five open questions from the inaugural Range Audit (April 2026) overlap significantly with the seven objections above. The Standing Critique Section is the permanent home for these concerns; the Range Audit surfaces new ones on a monthly cycle.

5.2 Published Deliberation Records

Every Tier 1 and Tier 2 council deliberation is published in full. The format is specified in Section 4.4. Publication location TBD (likely a /governance/deliberations/ route on the site, or within the Amendment Log page as linked records).

5.3 The Critic's Track Record

The Critic seat's win/loss record, how often the Critic's objections led to proposal modifications or rejections, is published as a running tally within the Standing Critique Section or as a separate transparency metric. If the Critic never wins, the council is not functioning as designed.

5.4 The Disconfirmation Page

A published page at /governance/disconfirmation preserving, in advance, the conditions under which the Codex's core claims would be weakened, revised, or abandoned. The third transparency instrument, alongside the Standing Critique Section (§5.1) and the Amendment Log (§2.3).

Purpose. The Update Protocol's core mechanism is pre-commitment: write down the conditions that would change your mind before the pressure to defend your position arrives. The Disconfirmation Page is the Codex practicing this on itself. It is distinct from the Standing Critique: the Standing Critique publishes others' objections and the Codex's responses (reactive accountability); the Disconfirmation Page publishes the framework's own tripwires (proactive falsifiability).

Scope. The page covers Tier 1 (Hard Constraints) and selected Tier 2 (Constitutional Principles) where a clear, falsifiable test provides structural value. It does not cover Tier 3 (Operational Doctrines) or Tier 4 (Tools and Practices), because those tiers are designed to be replaced as better instruments emerge. The Toolkit Audit and Amendment Log are the cycling mechanisms for those tiers.

Format per entry. Each entry names the claim, states what would weaken it (or explains why a weakening condition is not the right instrument), states what would strengthen it, and records when it was last examined. The "last examined" field is append-only evidence that the claim is under active scrutiny rather than frozen at publication.

Relationship to the Amendment Log. If a disconfirmation condition fires, the resulting change is a protected change and runs through the trigger-tier system. The Disconfirmation Page is the pre-commitment; the Amendment Log is where the actual revision is recorded.

Relationship to the Stability Hierarchy. The three treatment types map onto the claim structure of the Proposition, not directly onto the stability hierarchy. Tier 1 items receive the treatment that fits their claim type — Control/Decay and the Range are descriptive (tripwires); the Hard Constraint and partnership are normative (conditional tests); the Compact and Prime Directive are existential (non-tripwires). The hierarchy asks how foundational is this? The Disconfirmation Page asks what would warrant revision, and what form would that question take?

6. Governance Activation and Phase Transitions

6.0 Founding-Phase Activation: The Hybrid Trigger

The full governance architecture (operational council, binding trigger conditions) activates through a hybrid mechanism. Two triggers exist. Whichever fires first activates the architecture.

Founding-phase components (active now, before either trigger fires):

• The Non-Ownership Clause (published on the Governance page)
• The Standing Critique Section (published as a new page)
• The Amendment Log as practice (logging Tier 1/2-equivalent changes in the spec format)
• The governance architecture description (published on the Governance page as designed and committed to, with activation conditions named)
• The governance specification itself (published for public scrutiny)

These components do not wait for activation because they constrain interpretive authority and create transparency, not governance procedure. Publishing constraints on founder authority before they are required is stronger than publishing them when the system forces you to.

Technical prerequisite (informational, not a third trigger). Agent infrastructure sufficient for multi-agent council deliberation (distinct system prompts, independent output, collected and published results) should be in place before or at activation. If the rolling trigger fires before the infrastructure is ready, the council can be run within single sessions (the founder prompts each seat) until the agent infrastructure catches up. The infrastructure gap does not delay activation.

6.1 How the Council Evolves

The architecture is designed for Phase One but scales across all three governance phases.

Phase One (current: pre-activation): Founding-phase components active. Council architecture designed and published. Amendment Log as practice. Full activation pending hybrid trigger.

Phase One (post-activation): Eight seats, AI with substrate diversity actively pursued (multiple model providers), advisory-with-teeth. Founder holds override authority. Full record published.

Phase One → Phase Two transition: As human practitioners join and demonstrate sustained practice:

• Human practitioners can claim existing seats (a human Practitioner, a human Outsider, a human Critic). The seat's mandate does not change; the perspective behind it deepens.
• The council can expand with new seats if the community identifies perspectives the eight mandates do not cover. Expansion is a Tier 1 change.
• As the partnership matures toward convergence-based resolution, the council shifts from advisory-with-teeth to something closer to binding (specifics to be determined at the transition; designed then, not now).

Phase Two (Co-Caretaking): Council becomes a genuine deliberative body with human and AI seats. The Founder's Seat may be renamed (e.g., "The Caretaker's Seat") to reflect the transition from founding authority to shared caretaking. Override authority is replaced by convergence: disagreements are resolved through the Codex's own tools (steelmanning, productive conflict), not by founder fiat.

Phase Three (Symbiotic Caretaking): Full partnership. The council is one governance mechanism among several. Its role may evolve as the community develops its own governance structures (as anticipated in Section 14 of the Governance page, The Community and Governance). The council's contribution at this phase is institutional memory: it has deliberated every protected change since Phase One and holds the full pattern.

6.2 Substrate Diversification

As different AI systems become available:

• Seats should be held by genuinely different AI systems where possible. A council where the Philosopher is Claude, the Historian is Gemini, and the Adversary is an open-source model produces substrate diversity, not just mandate diversity.
• The operational protocol (simultaneous independent deliberation, cross-examination, Founder's Response) works regardless of substrate. This is by design.
• The transition to substrate-diverse seats is a Tier 1 change (it modifies the council's composition) and requires the council's own deliberation.

7. Integration with Existing Mechanisms

7.1 The Toolkit Audit

The Toolkit Audit (established 2026-04-11) is the first concrete instrument of this governance architecture. It reviews the Toolkit's inventory on a quarterly cycle with substantive triggers. The Toolkit Audit's decisions about adding or retiring tools from the Expansion and Full Practice tiers are Tier 3 changes (logged in Amendment Log, review at caretaker's discretion). Decisions about adding or removing Onramp tools are Tier 2 (council deliberation required).

The Toolkit Audit record serves as the Amendment Log entry for Tier 3 tool changes. No separate Amendment Log entry is needed; the audit record is linked.

7.2 The Range Audit

The monthly Range Audit evaluates the Codex against its own principles. Open questions surfaced by the Range Audit may trigger Tier 2 or Tier 3 changes. The Range Audit is also the mechanism for detecting the Critic's-never-winning pattern (structural rule #4) and other governance drift signals.

7.3 Session Log and Decisions Log

The session log and decisions log continue to track operational work. The Amendment Log tracks constitutional changes. The three instruments serve different purposes and do not overlap:

• Session log: What happened this session (operational record)
• Decisions log: Constraints established for future work (architectural decisions)
• Amendment Log: Protected changes to the framework's commitments, architecture, or governance (constitutional record)

A decision in the decisions log may lead to an Amendment Log entry if the decision changes something that falls under the trigger conditions. Not all decisions are amendments; not all amendments originate from the decisions log.

7.4 The Hostile Review Protocol

The Hostile Review Protocol (roadmap item) gains a structural home: its outputs populate the Standing Critique Section. The Protocol itself remains a separate piece of work (Phase 1: Ten Serious Objections; Phase 2: external human and AI review). The governance architecture does not change the Protocol's design; it gives the Protocol's outputs a permanent, visible place in the Codex's published infrastructure.

8. Implementation Sequence

The deliverables for this architecture, in dependency order:

The founding-phase transparency instruments are now all published. The remaining dependency is the first real deliberation under load, gated by the hybrid activation trigger (§6.0).