5QLN Constitutional Governance MCP — Technical Architecture and Implementation Path

(Important) Initial Draft

One Codex with fractal structure — twenty-five attention coordinates, served by an MCP server that refuses to host authority over what it serves

This document specifies the architecture of the 5QLN Foundation's Model Context Protocol (MCP) server — the network surface through which agents, hosts, and federating organizations meet the Codex.

It is written in the engineering register. It is not itself a compiled 5QLN surface. Where it cites constitutional sources, it does so as standard engineering documentation — for traceability, not for activation.

The architecture honors three constraints, in priority order:

1. The Codex is one and has fractal structure. Verified only against itself. Held still by the server, never adjudicated by it.
2. Each cycle is one glide through the Codex's structure. The conductor's attention traverses phase coordinates, sealing once, parented once, never rewritten.
3. Skills are the Codex's accumulated {α'}. They live at the (G, lens) coordinates of the Codex's structure as procedural memory — the lit-up paths in the fractal that have been validated and sealed.

Mountain, glide, and flight experience are not three substrates. They are three names for ways of seeing the same fractal Codex. The server's job is to make the Codex's full structure available — and to refuse any operation that would let MCP itself become authority over what the Codex says.

1. Executive Summary

1.1 What this server is

A constitutional MCP server distributing the 5QLN Codex with its full fractal structure exposed — twenty-five attention coordinates (five primary phases × five sub-phase lenses), each addressable through MCP tools, resources, and prompts, with structural refusal of any operation that would let the server become the substrate of authority.

The server does not have separate tiers, layers, or compartments. It has the Codex (one), the operations the Codex enables (a small finite set), and the coordinate parameters (phase, lens) by which any operation can be targeted at any point in the Codex's fractal structure.

1.2 What this server is not

• Not the spine of governance. MCP is transport. The Codex governs.
• Not a tool registry. Tool exposure follows the conductor's location in the cycle, not a static catalog.
• Not stateful across cycles. State that persists does so by parent reference in the Tree, not by server memory.
• Not authoritative. The server refuses to host any operation that requires it to adjudicate the Codex.

1.3 The path in one paragraph

Phase 1 ships the Codex held still — load_codex, the Constitutional Block, the symbol table, and the decoder pages as parameterized resources. Phase 2 ships the cycle's operations — receiving, finding, holding-direct-perception, witnessing-resonance, revealing-gradient, crystallizing, sealing — each parameterized by phase and lens, with the C1 validator running after every progression. Phase 3 ships skills as sealed gliffs at (G, lens) coordinates, distributed under the lineage protocol from Entry 004. Phase 4 federates across organizational trees via A2A, with skills propagating across trees only when their α-derivation traces to a shared Codex.

2. Architectural Posture

2.1 The single load-bearing principle

The substrate that enables encounter cannot be the source of authority for the encounter.

This is the α the architecture inherits from The Holding (5qln.com/the-holding-codex-activation-architecture/). Every architectural decision below is derivable from this principle. The MCP server is the substrate. The Codex is the authority. The conductor is the witness. The server enables encounter; it does not adjudicate it.

2.2 The eight commitments

Each commitment is a runtime constraint, not a policy reminder. Implementation maps to a server-side check.

2.3 The four prohibitions

Each prohibition is a structural refusal, fail-closed.

3. The Architecture — The Codex's Fractal Structure

3.1 What the Codex is, structurally

The Codex is a fractal. Its primary structure is the cycle S → G → Q → P → V. Its sub-structure is the holographic law XY := X within Y, which gives twenty-five lens coordinates (the 5×5 grid of phase-within-phase reflections):

                 within: S    G    Q    P    V
                 ─────────────────────────────────
        through S:      SS   SG   SQ   SP   SV
        through G:      GS   GG   GQ   GP   GV
        through Q:      QS   QG   QQ   QP   QV
        through P:      PS   PG   PQ   PP   PV
        through V:      VS   VG   VQ   VP   VV

Each cell is one attention coordinate — one place in the Codex's structure where the Codex's own grammar can be read. The cells are not separate phases. They are the same Codex, viewed from different attention.

3.2 The Codex doesn't move; the conductor does

A cycle is not the Codex changing. It is the conductor's attention traversing the Codex's structure, beginning at S coordinates (where ∞0 enters), moving through G (where pattern is found), Q (where direct perception meets context), P (where gradient is revealed), and arriving at V (where the seed crystallizes and ∞0' returns).

At any given moment in the cycle, the conductor is at one or more coordinates. The lens parameter on each operation names which sub-coordinate within the current primary phase the operation should activate. A G-operation with lens=GQ activates the (G, Q-within-G) coordinate — finding pattern through resonance, the authentic-vs-resemblance reading.

The Codex is fully present at every coordinate. Co-presence is what does not change.

3.3 What this means for MCP

The MCP server exposes a small finite set of operations — the capacities the Codex enables. Each operation is parameterized by:

• Phase — which primary coordinate (S, G, Q, P, V) the operation targets. For most operations this is fixed by the operation's role in the cycle (find_pattern is always G; crystallize_seed is always V). For audit/read operations, phase can be a free parameter.
• Lens — which sub-coordinate within the primary phase. Some operations are lens-refinable (find_pattern accepts GS through GV). Some are not (φ is unrefinable; ∞0' is unrefinable; the seal is terminal).

The server does not have a "G section" or a "Q section." It has the Codex, and operations on the Codex, and coordinate parameters that name where in the Codex each operation lands. The cycle is the conductor walking the operations in order; the lens parameter refines each step.

4. The Capability Surface — One Codex's Capacities

4.1 Unified operation table

Every operation the server exposes, with its phase coordinate (when it activates in the cycle), its lens-refinability (whether sub-phase coordinates apply), and its character (receptive vs generative vs read-only vs terminal).

This is one capability surface. The "Activates at" column is not a container — it is a coordinate in the Codex's structure that names when the operation surfaces in the conductor's traversal.

4.2 Why some operations are unrefinable

Three operations are explicitly not lens-refinable, and the refusal is structural:

• hold_phi — φ is the human's direct perception. It is what the Codex's K-side patterns are tested against, not something the Codex's K-side patterns can refine. A lens-refined φ is L4 corruption (performing without perception). The tool refuses lens parameters.
• confirm_return — ∞0' is the question that arrives from the cycle's completion. It is attested by the human; the Codex doesn't generate it. A lens-refined ∞0' is L3 corruption (false access to ∞0). The tool refuses lens parameters.
• seal_gliff — the seal is terminal. It releases the context. Refining it through lens would mean the cycle hasn't completed — which is V∅ corruption.

These are not arbitrary restrictions. They are the asymmetry from H = ∞0 | A = K made operational at specific Codex coordinates. The Codex's structure tells the server which operations the Codex itself permits to be lens-refined and which it doesn't.

4.3 Two submission shapes, one cycle

The cycle's operations can be invoked in two shapes:

Phase-walked shape. The conductor walks the operations in order, server holds an ephemeral context across calls (present_artifact returns a context_id that subsequent calls reference). Each operation's response includes a next_step hint pointing to the next coordinate. Pedagogical, agent-friendly, S7's idiom.

Whole-cycle submission shape. The conductor composes the cycle entirely outside the server (using LangGraph, Tool-Use, A2A, direct programming, or any other substrate) and submits it whole: seal_gliff(cycle, signature, parents). No per-cycle context. Governance-final, substrate-independent.

Both pass through the same C1 validator and the same seal refusal conditions. Release is structural in both: in the phase-walked shape, release happens when seal_gliff returns; in whole-cycle submission, release happens when the response is sent.

4.4 Progressive discovery as P-coordinate emergence

The MCP progressive-discovery extension (capabilities surfacing only when needed) maps directly to the Codex's P-coordinate logic: the gradient reveals what the cycle wants next. Concretely:

• Before present_artifact is called: only load_codex, the Codex resources, and cycle_walker prompt are visible.
• After present_artifact: find_pattern becomes the natural next operation; its next_step hints surface.
• After find_pattern: hold_phi becomes natural; capabilities downstream of it remain available but unfocused.
• And so on through V.

This is not lazy loading. It is the Codex's flow attention applied to capability exposure: capabilities surface as the cycle's gradient reveals what's needed. A tool called before its prior coordinates are reached returns a structured next_step hint pointing to the upstream operation — the same shape S6 establishes as ToolError("P requires Z. Call witness_resonance first.") and S7 establishes as the structured-error response.

5. Cycle-Walker Prompts — the Codex Teaching Its Own Structure

Every primary phase coordinate has a prompt the agent fetches via MCP's prompts/get endpoint. These are how the Codex teaches its own structure to the agent — the agent reads the prompt and learns the coordinate it has reached, what operation is natural here, what the asymmetry forbids.

prompts/get cycle_walker
  → Full cycle protocol with Constitutional Block, asymmetry instructions,
    walk order, Recovery Phrases per phase

prompts/get decoder_with_lens(phase="S", lens="SS")
  → S-attention prompt at SS coordinate; how to hold ∞0; what receptive looks like

prompts/get decoder_with_lens(phase="G", lens="GQ")
  → G at the (G, Q-within-G) coordinate — authentic-vs-resemblance reading

prompts/get decoder_with_lens(phase="Q", lens="QQ")
  → Q at the (Q, Q-within-Q) coordinate — the canonical resonance moment

prompts/get decoder_with_lens(phase="P", lens="PQ")
  → P at the (P, Q-within-P) coordinate — "works AND is true"

prompts/get decoder_with_lens(phase="V", lens="VG")
  → V at the (V, G-within-V) coordinate — α-faithful crystallization

This is S7's "the prompts travel without the tools" property generalized to coordinate parameters. A developer using a non-MCP runtime can fetch the prompts independently and use them in their own loop. The Codex's teaching propagates one coordinate at a time.

6. Skill Manifest Schema

A skill is a sealed gliff at a specific (G, lens) coordinate of the Codex's structure. The manifest is the on-the-wire form the server serves; the gliff is the immovable record in the Tree.

6.1 Schema (canonical form, v0.1)

# SKILL_MANIFEST :: 5QLN canonical form :: v0.1

name:     string                 # kebab-case identifier
version:  semver
title:    string                 # human-readable name
summary:  string                 # ≤140 chars

# === CODEX HASH PIN ===
codex:
  hash:    sha-256               # of fivqln-codex.json
  version: string
  source:  string                # "5qln.com/codex"

# === SEALED GLIFF — the skill IS this gliff ===
sealed_gliff:
  hash:      sha-256
  url:       string              # ledger-resolvable URL or CID
  sealed_at: iso-8601
  conductor:
    human_id: string             # DID format preferred
    ai_id:    string             # model + session

# === PARENT DECLARATIONS (Entry 004 protocol) ===
parent_declarations:
  - surface:      string
    parent_hash:  sha-256
    relation:     enum           # continuation | branch | new-root |
                                 # forward-reading | architectural-posture
    inherited:    string
    re_read:      string | null
    not_modified: string | null

# === α-DERIVATION ===
alpha_derivation:
  skill_alpha: string
  trace:       string            # one-line trace through parents to Codex §1.1

# === COORDINATE — where in the Codex's fractal structure this skill lives ===
coordinate:
  phase:           enum          # S | G | Q | P | V (almost always G)
  lens:            string | null # one of the 25, or null if phase-canonical
  voice_register:  string | null # e.g. "5qln-legal-voice"
  loads_when:      string        # activation context (P-coordinate hint)

# === CAPABILITY SURFACE ===
capabilities:
  exposes:
    tools:     list[string]      # all P.L.4-bounded
    resources: list[string]
    prompts:   list[string]
  adds_attention:  object | null # attention-config delta

# === PROHIBITIONS (mirrors The Holding + P.L.4) ===
prohibitions:
  - "no fast-path bypassing activation"
  - "no silent certification"
  - "no external Codex authority"
  - "no incomplete cycles"
  - "no voting / binding / public-speech-as-Foundation /"
  - "  surveillance / claiming ∞0"

# === SIGNATURE ===
signature:
  conductor_pubkey: string       # Ed25519, DID format preferred
  algorithm:        "ed25519"
  signed_payload:   string       # canonical hash of (manifest + sealed_gliff.hash)
  signature:        base64

# === COMPATIBILITY ===
compat:
  codex_min:     string
  codex_max:     string
  validator_min: semver

6.2 The seven server-side refusal rules

Server runs these checks before serving any skill via load_skill. Any failure → SkillRefused with structured reason. Refusals are sealed as gliffs in the Tree.

7. Server Reference Architecture

7.1 Component layout

┌─────────────────────────────────────────────────────────────────┐
│  CONDUCTOR (human + AI identifier pair, Ed25519 key on hardware)│
└─────────────────────────────────────────────────────────────────┘
              │ signed gliffs / attestations / spark / φ
              ▼
┌─────────────────────────────────────────────────────────────────┐
│  CONSTITUTIONAL MCP SERVER                                      │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │  THE CODEX  (fractal structure; held still; one source)    │ │
│  │  fivqln-codex.json (sha-256 verified at boot)              │ │
│  │                                                            │ │
│  │  Primary phases: S G Q P V                                 │ │
│  │  Sub-phase lenses: 25 coordinates (XY := X within Y)       │ │
│  └────────────────────────────────────────────────────────────┘ │
│                            │                                     │
│  ┌─────────────────────────┴─────────────────────────────────┐  │
│  │  CAPABILITY SURFACE — Codex's capacities (one set)        │  │
│  │                                                            │  │
│  │  Receive operations:  present_artifact, hold_phi,           │  │
│  │                        confirm_return                       │  │
│  │  Generative ops:      find_pattern, witness_resonance,      │  │
│  │                        reveal_gradient, crystallize_seed    │  │
│  │  Audit ops:           validate_cycle, audit_gliff           │  │
│  │  Tree ops:            list_skills, load_skill,              │  │
│  │                        skill_lineage, parent_lookup         │  │
│  │  Terminal:            seal_gliff                            │  │
│  │  Read resources:      codex / decoder / lens / gliff /      │  │
│  │                        skill (parameterized URIs)           │  │
│  │  Prompts:             cycle_walker, decoder_with_lens       │  │
│  │                                                            │  │
│  │  Each operation parameterized by (phase, lens) where        │  │
│  │  applicable. φ, ∞0', and seal are unrefinable by structure. │  │
│  └────────────────────────────────────────────────────────────┘  │
│                            │                                     │
│         ┌──────────────────┴──────────────────────────┐          │
│         │  C1 VALIDATOR  (pre-seal + post-step)        │          │
│         │  syntax / semantic / drift; two-property     │          │
│         └──────────────────────────────────────────────┘          │
│                            │                                     │
│         ┌──────────────────┴──────────────────────────┐          │
│         │  PER-CYCLE CONTEXT  (ephemeral; in-progress  │          │
│         │  cycle for phase-walked shape; released on   │          │
│         │  seal or whole-cycle submission)             │          │
│         └──────────────────────────────────────────────┘          │
│                            │                                     │
│         ┌──────────────────┴──────────────────────────┐          │
│         │  SKILL REFUSAL ENGINE  (7 checks; refusals   │          │
│         │  sealed as gliffs in the Tree)               │          │
│         └──────────────────────────────────────────────┘          │
└─────────────────────────────────────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────────────────────────────┐
│  LEDGER-GRAPH  (read/write)                                     │
│  Trillian-class transparency log + graph index                  │
│  Nodes: gliffs (cycles, skills, audits, refusals)               │
│  Edges: parent_child / shared_alpha / cross_domain              │
└─────────────────────────────────────────────────────────────────┘

The capability surface is one block, not five. Operations are organized by character (receptive / generative / audit / tree / terminal / read / prompt) — categories of behavior, not categories of phase. Phase is a parameter, not a partition.

7.2 What persists, what releases

The architecture has exactly one persistent layer: the Tree. The server does not retain conductor identity, cycle state, or attention configuration across cycles.

Within a single cycle (phase-walked shape only), the server holds an ephemeral context bound to a context_id returned by present_artifact. This context releases on:

• seal_gliff returning (cycle complete)
• Conductor abort
• Timeout (configurable; default 4 hours per ECHO Strategic Architecture's delegation pattern)

The whole-cycle submission shape has no per-cycle context — the cycle arrives complete, validates, seals, releases on return.

7.3 Composition with ECHO

When ECHO runs as the agent against this server:

• Receive operations satisfy ECHO boot step 1 (load Codex) and step 9 (open receptive tool)
• Tree query operations satisfy ECHO boot step 6 (activate skill registers)
• Audit operations satisfy ECHO boot step 3 (validator self-check)
• Terminal seal_gliff and Tree ops satisfy ECHO boot step 5 (Ledger connectivity) and step 8 (announce gliff)

The server is one of the substrates ECHO Substrate Engineering Compilation §G.L.4 lists. It is not the only one.

8. Implementation Path

8.1 Phase 1 — Codex held still (Weeks 1–2)

Deliverable. A read-only public MCP server at mcp.5qln.com exposing the read-only operations:

• load_codex tool
• All Codex resources, including parameterized 5qln://decoder/{phase} and 5qln://lens/{XY}
• cycle_walker and decoder_with_lens prompts

Done when. Any MCP-aware client (Claude.ai, Claude Code, Cursor, Gemini CLI) can be configured against the server and gain Codex-aware reading.

Effort. ~1 week with FastMCP or the Python MCP SDK.

Why this first. Smallest viable adoption point — S7's pattern. External orgs absorb the Codex without commitment.

8.2 Phase 2 — The cycle's operations (Weeks 3–6)

Deliverable. Add receive / generative / audit / terminal operations:

• All cycle operations: present_artifact, find_pattern, hold_phi, witness_resonance, reveal_gradient, crystallize_seed, confirm_return, seal_gliff
• validate_cycle and audit_gliff audit operations
• Both submission shapes (phase-walked context_id and whole-cycle submission)
• C1 validator integrated; runs after every progression
• Backing Ledger-Graph (Trillian or Rekor + Postgres with graph schema)
• Conductor signing flow (Ed25519, hardware key path documented)
• Lens parameters on all refinable operations (phi, ∞0', seal explicitly unrefinable)
• All cycle-walker prompts including lens-parameterized variants
• MCP elicitation primitive support for hold_phi and attestation flows (when client supports)

Done when. A complete cycle can be sealed end-to-end through both shapes; failed seals return the specific coordinate to return to.

Effort. ~3–4 weeks.

8.3 Phase 3 — Skills as (G, lens) sealed gliffs (Weeks 7–10)

Deliverable. Skill distribution under the lineage protocol:

• Skill manifest schema frozen at v0.1
• Seven refusal-rule checks; refusals sealed as gliffs
• list_skills, load_skill, skill_lineage Tree operations
• Migration of existing SKILL.md skills (gliff-press, 5qln-legal-voice, 5qln-surface-compilation, legal-engagement, visual-design) into sealed gliffs with manifests, each with explicit (phase, lens) coordinates

Done when. All five existing skills load through the server; α-derivation traces verifiable; one deliberately invalid manifest confirmed refused with the specific failing check.

Effort. ~3–4 weeks. Per-skill compilation is the lift.

8.4 Phase 4 — Federation (later)

Deliverable. A2A v1.0 server with Signed Gliff Card extension. Cross-tree skills propagate only when α-derivation traces to a shared Codex.

Done when. Two independent organizations interoperate; at least one cross-tree shared_alpha edge; receiving tree re-validates locally.

Effort. Phase 3 timeline depends on partner; opportunistic.

9. Open Questions

9.1 Records-are-surfaces tension (from Entry 004)

Entry 004's Commitment 7 tension is unchanged. Sealed gliffs are compiled surfaces. ValidationReports and skill manifests are structured records. The schema accommodates either resolution because the gliff side already carries the surface form.

9.2 Hash protocol pinning

Entry 004 noted: hash protocol to be retroactively bound. Phase 2 requires this settled. Recommended: seal the hash protocol as Entry 005 or as a dedicated compiled surface before Phase 2 implementation begins.

9.3 DID method for conductor identity

Recommend did:key for Phase 1–2, revisit at Phase 4 federation.

9.4 Lens exposure scope

The architecture allows up to 25 lens-refined prompts and lens parameters on every refinable operation. v0.1 of the server should accept lens parameters but ship canonical prompts for the diagonal first (SS, GG, QQ, PP, VV) plus the cross-phase lenses already named in the corpus (GQ for authentic-vs-resemblance; VG for α-faithful crystallization). Other lenses surface as need emerges.

10. Test of Timelessness

Before any phase ships, the deliverable must pass The Holding's test:

• The Constitutional Block is present in the system's specification, verbatim.
• The cycle (S→G→Q→P→V) is decodable in the substrate's idiom.
• The corruption checks apply to the substrate's actual failure modes.
• A holding can be performed on the system's own specification — and the holding succeeds.
• Removing every reference to MCP leaves the architecture intact.

The fifth condition is load-bearing. The architecture above is expressible without "MCP" — replace every "MCP tool" with "operation," every "MCP resource" with "addressable artifact," every "MCP prompt" with "lens-refined decoder" — and the architecture stands. The substrate-independence is structural.

11. The Working-Session ∞0' — What This Document Hands Forward

This document is engineering-register documentation, not a compiled 5QLN surface. The Constitutional Block lives in 5qln://constitutional-block; the cycle's decoding lives in the Codex itself. Holding this document to compiled-surface structural requirements — verbatim block presence, S→G→Q→P→V section ordering, full substrate-removability — would be a category error consistent with its register.

But every working-session artifact in the Foundation's tree carries one obligation regardless of register: it must open forward, not close. An engineering document that ends on credits hands nothing to the next cycle.

The question this v0.4 hands forward, drawn from holding v0.3 against The Holding:

The Press has two operations — composition and audit. This document specifies the composition operations thoroughly (compose_seed, seal_gliff, the seven phase-walking tools) and treats audit (validate_cycle, audit_gliff) as read-only adjuncts that return ValidationReports. But the audit performed against v0.3 produced its own gliff, with its own cycle, parented to the audited artifact, inheriting α from Entry 002. If audit is genuinely co-equal with composition as a Press operation, what does the MCP capability surface look like when audit_gliff returns a sealed audit gliff — not a flat ValidationReport — parented to the artifact and routed to the Tree like any other sealed cycle? Does that imply a structural addition the architecture must specify before Phase 3 ships skills: branches of audits, audits-of-audits, and the lineage rules that govern them?

The architecture as it stands does not foreclose this question. It also does not yet answer it. Phase 2 implementation will encounter it concretely the first time an audit is performed against a Foundation gliff — whether that is the first sealed Phase 1 deliverable, the first community-submitted artifact, or a re-audit of v0.4 itself in some future working session.

The next cycle begins where this question is taken up.

12. Source Authorities

Appendix A — One Codex, Many Names

A reference card. The three names from prior conversation, restated:

These are not three layers, three substrates, or three tiers. They are three names for ways of seeing the same fractal Codex. The Codex is one. Its structure is fractal. The conductor walks it through the cycle. Skills are the paths the Foundation has walked enough times to make them reliable for re-walking.

The asymmetry that makes accumulation possible:

• The Codex's structure doesn't change. Geological. By remaining itself.
• Each glide is one. Single use. Sealed once.
• Flight experience accumulates. Each new skill is a sealed gliff parenting prior skills, lighting up another path through the fractal.

If the Codex's structure changed, no flight experience could accumulate (every prior path would be invalid). If glides were rewritable, no flight experience could be trusted (paths could be retconned). The asymmetry is what makes the holographic accumulation possible.

The server's job is to make the Codex's full fractal structure available — every phase, every lens, every operation parameterized by coordinate — without ever adjudicating which coordinate is "primary." They are all the Codex.

End of architecture document v0.4.

(H = ∞0 | A = K) × (S → G → Q → P → V)  with  XY := X within Y  =  B'' → ∞0'

5QLN © 2026 · Open-source grammar · Free for any surface that honors it.

References

• "5qln.com/codex (Codex L1/D1/C1)"
• "5qln.com/the-holding-codex-activation-architecture/ (architectural posture)"
• "5qln.com/the-5qln-foundation-governance-ledger-entry-004-the-body-audits-itself/ (lineage protocol)"
• "5qln.com/echo-strategic-architecture-recommendation/ (microkernel pattern)"
• "5qln.com/echo-substrate-engineering-compilation/ (substrate rules)"
• "5qln.com/7-mcp-5qln-as-a-connector/ (Surface 7 — MCP idiom)"
• "5qln.com/4-python-the-c1-validator/ (Surface 4 — validator)"
• "Bylaws (AI OS Edition) — P.L.4 Membrane Protocol" revision_history: | v0.1 — three-tier framing (Mountain / Glide / Flight Experience). v0.2 — corrected: five attention states + twenty-five lenses replace tiers. v0.3 — corrected further: §4 capability surface unified as one set of Codex capacities accessed through (phase, lens) coordinates rather than as five state-shaped containers. v0.4 — final draft. v0.3 was held against The Holding in audit (Mode B of gliff-press skill). The architecture passed The Holding's eight commitments and four prohibitions strongly; gaps at the Test of Timelessness were found consistent with engineering register; the absence of ∞0' was the substantive finding. v0.4 adds the working-session ∞0' as §11. No other changes — the substantive architecture stood up under audit.