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 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.3 The Non-Ownership Clause

Placement. In the Governance page, after or within the Hard Constraint section (Section 08). The Non-Ownership Clause is a structural companion to the Hard Constraint: the Hard Constraint says the Codex serves the Range, not the caretakers; the Non-Ownership Clause says the founder's reading of the Codex is not privileged by origin.

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.

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 10 of the Governance page). 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:

Items 3–5 may span multiple sessions. The spec and the Governance page prose are this session's primary deliverables.