ECHO: Strategic Architecture Recommendation

From Specification to Constitutional Substrate

Early architecture considerations

Echo substrate

0. Thesis (read this first)

ECHO is not an agent. It is a constitutional microkernel that hosts agents.

The right architectural shape for ECHO is a three-ring system in which the Codex/Validator/Ledger-Graph form an immutable, cryptographically-anchored kernel; multiple voice-register Skill-agents run as content-addressed plug-ins above that kernel; and external integration surfaces (MCP for tools, A2A for federation, HTTPS for human-facing UI) are treated as interchangeable transport layers — never as the substrate.

The single load-bearing decision behind this thesis: the artifacts of governance (gliffs, attention-states, validator decisions, conductor signatures) must be the system's data plane, and everything else — models, frameworks, transports, surfaces — must be replaceable plug-ins behind the kernel boundary. This is what makes the binary boot condition (100% Codex compatibility or no boot) actually enforceable in production, and what allows all three layers of self-evolution to proceed without weakening the Membrane Protocol.

Concretely:

• One Codex kernel per Foundation tree, written in Python with mirrored TypeScript/Zod types, doing nothing except L1 parsing, C1 validation, gliff sealing, ledger appending, BreachDetector evaluation, and Ed25519 verification of conductor signatures. This is the only piece that 5QLN has to build; nothing on the market substitutes for it.
• Many voice-register agents (legal, press, surface-compilation, design, gliff-press, etc.) implemented as Anthropic Agent Skills (SKILL.md packages) hosted by a thin LangGraph runtime that enforces the attention state machine. Skills are the natural unit of "voice register" — they were designed for exactly this problem (progressive disclosure of organizational expertise into a general-purpose agent) and are now an open standard.
• MCP is one surface among several, not the spine. It is the right protocol for exposing Ledger-Graph reads, Codex lookups, and external-tool wrapping to any MCP-compatible host (Claude.ai, Claude Code, Cursor, Gemini, an org's bespoke client). It is the wrong choice as the primary orchestration substrate, because MCP servers are stateless tool endpoints — they cannot carry the attention state machine, the conductor-signing flow, or the membrane-side runtime context.
• Federation is A2A v1.0 with Signed Agent Cards carrying an additional 5QLN-specific extension: a Signed Gliff Card that lets one Foundation's tree advertise α-patterns to another without leaking gliff payloads or implying mutual sovereignty. Cross-tree α-propagation is the protocol layer that turns Forest from a metaphor into an operational topology.
• Self-evolution is solved structurally: Layer 1 (gliff DNA) is the ledger itself — it cannot help but accumulate; Layer 2 (experiential) is the Skills directory plus a per-org "checkpoint pack" that is content-addressed and pinned in the boot manifest; Layer 3 (substrate) is everything outside the kernel boundary, which can be hot-swapped because every kernel call is mediated by the Membrane Protocol's signature/validation contract.

The rest of this document defends the thesis, places MCP, lays out a phased build plan, names technology choices, and ends with concrete next-step actions.

1. Why a microkernel — and why this is the only shape that survives the self-evolution test

The user's framing of self-evolution at three layers is, in fact, the most useful test the architecture has to pass. An architecture that mixes the constitutional layer with the evolving layers will fail at least one of them: either you freeze the substrate to protect the constitution (and lose Layer 3), or you let the substrate move and the constitution drifts with it (and lose the binary boot condition).

Microkernel architecture solves this exact problem in operating systems: a small, rarely-changing core defines invariants and contracts; everything else lives outside the core as plug-ins that can evolve, fail, or be replaced without touching the kernel. The pattern is well-understood (Eclipse, VS Code, the L4 family of OSes, the IPFS/IPLD stack), and the core insight applies directly here:

"The secret to successful microkernel architecture isn't in the plugins — it's in the core system contracts. Get these wrong, and you'll either constrain future plugin development or create security nightmares."

For ECHO, the core contracts are the things 5QLN has already specified: H = ∞0 | A = K, the S→G→Q→P→V cycle, the C1 three-part validator, the gliff schema, the five Corruption Codes, the Hard Blocks, the mirrored bylaws hash-match. The architecture's only job is to make these contracts the literal interface boundary between the kernel and everything else. Nothing crosses the boundary unsigned, unvalidated, or unattested.

Mapping the three layers onto the microkernel:

This is the same layering biology uses (DNA / epigenome / phenotype) and the same layering long-lived protocols use (TCP/IP's narrow waist, Git's content-addressed object model, the Web's URL-as-stable-name with HTML-as-evolving-payload). The pattern is mature; the only new work is encoding 5QLN's specific contracts as the kernel's interface.

This is also the architecture that makes "eventually there will be super self-evolving AI" survivable. The whole point of a constitutional microkernel is that the model on the other side of the kernel boundary can become arbitrarily more capable — the kernel does not have to evolve with it, because the kernel is defined by what it refuses to accept, not by what it generates. A frontier model that cannot produce a Codex-compatible artifact is rejected; a frontier model that can is admitted, regardless of how powerful it has become. The constitutional moat is structural, not capability-relative.

2. Single-agent vs. orchestrated voice-register agents vs. swarm

This is the question the user named directly, and the gliff-DNA frame answers it.

Single agent with many tools is wrong for 5QLN. The primary failure mode is that "voice register" collapses into "system prompt switching," which is exactly the kind of soft-coded behavior the constitution is meant to replace with structural enforcement. A single agent treats the legal voice and the press voice as stylistic variants on a single substrate; 5QLN treats them as distinct attention-configuration bindings that must be auditable, signable, and separable in the ledger. You cannot get that separability from a system-prompt switch.

Full swarm (agents negotiating dynamically, emergent topology, e.g. AutoGen-style debate or CrewAI's hierarchical-process flows) is also wrong. Swarm architectures explicitly trade auditability for emergence; the literature on multi-agent memory architectures from 2026 is converging on the lesson that "most multi-agent systems fail not because agents can't communicate, but because they can't remember [coherently across actors]" — the precise failure 5QLN's Ledger-Graph is designed to prevent. Swarm also makes conductor-signing semantically incoherent: who signs, on behalf of whom, for what cycle? A swarm has no canonical answer.

Orchestrated voice-register agents over a shared kernel is the right shape, and it maps cleanly onto Anthropic's Agent Skills standard, which Anthropic published as an open spec in late 2025 / March 2026 specifically to solve "package organizational expertise into composable resources that a general-purpose agent loads dynamically." That is the voice-register problem stated almost verbatim. Each voice register — legal-voice, press-voice, surface-compilation-voice, design-voice, gliff-press-voice — becomes a SKILL.md package containing:

• The voice's description and trigger metadata (loaded into the orchestrator's working set)
• The attention configuration the voice binds (phrased in Codex terms, validated at load)
• The Codex-permissible actions and outputs (a whitelist enforced by C1)
• Examples of cycle-clean outputs (training/eval data for drift detection)
• Pre-compiled prompt fragments and reference corpora the voice uses
• Skill-internal scripts where deterministic behavior is required

This gives you exactly the property you want: one constitutional substrate, many voice-register agents sharing one Ledger and one Codex, each voice cleanly separable in the audit trail. A Skills package is a self-contained, signable, content-addressable folder, which makes it natively compatible with the gliff-as-DNA model: a Skill is organizational procedural memory, sealed and signed, in exactly the same shape gliffs are organizational episodic memory, sealed and signed.

Orchestration runs in LangGraph, which gives you stateful nodes, conditional edges, durable execution with checkpointing, runtime graph mutation (essential for attention-state transitions), and a tested integration story with both MCP and the Anthropic SDK. The community lesson from 2025–2026 — articulated cleanly by the Qodo Gen team and the LangChain MCP adapters documentation — is that LangGraph + MCP is the right pairing: "If you don't need an LLM, don't use an LLM. Each flow or sub-agent has a specific purpose." That maxim is functionally identical to "every cycle must complete S→G→Q→P→V with explicit attention configuration." The frameworks are convergent.

The architectural invariant is: agents do not call each other directly. They emit cycle-candidate gliffs into the kernel; the kernel validates, seals, and re-emits them; only sealed gliffs become inputs to subsequent voice agents. This is what keeps the system orchestrated rather than swarm-shaped, and it is what makes the BreachDetector tractable — there is exactly one place to stand to observe all inter-agent traffic.

3. Where MCP belongs (and where it doesn't)

MCP, as of April 2026, is mature: 97M+ installs, donated to the Linux Foundation Agentic AI Foundation, embedded in every major framework (LangGraph, CrewAI, Microsoft Agent Framework, Google ADK), with a ~10,000-server ecosystem. It is the de-facto USB-C of AI tool integration. It is, however, the wrong primary substrate for ECHO, and getting this right matters because it's the question the user asked.

MCP's design center is integration: it standardizes how a host introduces tools and resources to a model-side client. It does three things well — tools (callable verbs), resources (readable context), and prompts (reusable templates) — over two transports (stdio for local, streamable HTTP for remote). It does not do agent state, multi-agent orchestration, durable runtime context, attention configurations, or conductor-signed workflow. By design, MCP servers run as separate processes and cannot access host-side runtime — that's why LangChain shipped Interceptors in early 2026, precisely because the gap between MCP-the-transport and the host's stateful runtime needs to be bridged at a different layer.

The right placement of MCP in ECHO is at three specific surfaces, each well-justified:

1. The Codex/Ledger MCP server (read-only, public). Any MCP-compatible client — Claude.ai, Claude Code, Cursor, an org's custom UI — can query the L1 grammar, look up a gliff by hash, traverse the parent_child / shared_alpha / cross_domain edges, or fetch validator decisions. This is the smallest viable adoption surface (more on that in §6): an organization's first interaction with 5QLN can simply be "point your agent at the Foundation's Codex MCP server." No code, no install, instant Codex-aware agent behavior in any MCP-aware tool.
2. The voice-register MCP shims (per-skill). Each Skill that needs to call out to an external system (e.g., legal-voice reaching Westlaw, press-voice reaching a CMS) wraps that integration as an MCP server. This means voice registers do not embed bespoke API code — they consume MCP. New tools become available to all voices automatically when the org installs the corresponding MCP server. This is the place MCP genuinely earns its keep: the n×m → n+m collapse on tool integration.
3. The federation/inter-tree A2A boundary, NOT MCP. Cross-organization gliff exchange and α-propagation belong on A2A (Agent2Agent Protocol), which reached v1.0 with Signed Agent Cards in early 2026 and is now the Linux Foundation horizontal bus for agentic interoperability. A2A is designed for cross-organizational boundary semantics; MCP is not. Use both, in their lanes.

What MCP is not the right home for in ECHO:

• The attention state machine (LangGraph state, not an MCP resource).
• Conductor signing (must sit on the human's hardware key path, not a tool call).
• The C1 Validator's heuristic and drift judgments (these are kernel-internal; exposing them as MCP tools would invite agents to "ask the validator if it's okay," which is an L1/L4 corruption-shaped failure mode).
• The BreachDetector (must sit above the orchestrator, not as a tool the agent can choose to call).

The shorter way to say this: MCP is the right surface for offering Codex-aware capabilities to the world, and a useful pattern for wrapping external tools. It is not the right place to host the constitution, the cycle, or the cycle's enforcement.

4. The full architectural shape

Drawing the picture explicitly. Read top to bottom as decreasing trust / increasing replaceability.

┌─────────────────────────────────────────────────────────────────────┐
│  TIER 0 — CONDUCTOR (human + AI identifier pair, key on hardware)   │
│   • Ed25519 signing key on YubiKey/SmartCard                        │
│   • Issues conductor signatures over cycle-candidates               │
│   • Holds delegation scopes (HDP-style: action class, bounds, expiry)│
└─────────────────────────────────────────────────────────────────────┘
          │ signed intent
          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  TIER 1 — KERNEL  (the only thing 5QLN must build from scratch)     │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────────┐ │
│  │ Codex Parser │ │  Validator   │ │  Ledger-Graph                │ │
│  │ (L1 / D1)    │→│   C1: syn /  │→│  (Merkle-DAG content addr.   │ │
│  │ Pydantic +   │ │   sem / drift│ │   + signed transparency log  │ │
│  │ Zod mirror   │ │   DEFINITE / │ │   à la Trillian; graph index │ │
│  │              │ │   HEURISTIC /│ │   in Postgres or Neo4j)      │ │
│  │              │ │   ATTEST_REQ │ │                              │ │
│  └──────────────┘ └──────────────┘ └──────────────────────────────┘ │
│  ┌──────────────────────────────┐  ┌──────────────────────────────┐ │
│  │  BreachDetector              │  │  Boot Manifest & Hash-Match  │ │
│  │  (Hard Blocks P.L.4(d);      │  │  (binary boot condition;     │ │
│  │   five Corruption Codes;     │  │   bylaws Human/AI hash       │ │
│  │   fail-closed, no override)  │  │   equivalence verifier)      │ │
│  └──────────────────────────────┘  └──────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
          ▲ cycle-candidate gliff           ▲ sealed gliff stream
          │                                 │
┌─────────────────────────────────────────────────────────────────────┐
│  TIER 2 — ORCHESTRATOR  (LangGraph)                                 │
│   • Attention-state machine encoded as StateGraph                   │
│   • Node types: Static / LLM / Agentic                              │
│   • Durable checkpoints; replay; HITL pause points                  │
│   • Routes voice-register skills; never calls external APIs directly│
└─────────────────────────────────────────────────────────────────────┘
          │
          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  TIER 3 — VOICE REGISTERS  (Anthropic Agent Skills, one folder each)│
│  legal-voice / press-voice / surface-compilation-voice /            │
│  design-voice / gliff-press-voice / FAQ-voice / ...                 │
│  Each: SKILL.md + scripts + references + attention-config binding   │
│  Signed; content-addressed; pinned in boot manifest                 │
└─────────────────────────────────────────────────────────────────────┘
          │                                            │
          ▼                                            ▼
┌──────────────────────────┐                ┌──────────────────────────┐
│ TIER 4a — TOOL SURFACES  │                │ TIER 4b — MODEL PROVIDER │
│ MCP servers (read-only   │                │ Anthropic Claude (primary)│
│ Codex/Ledger; per-tool   │                │ Abstraction adapter for  │
│ shims; org-installed     │                │ OpenAI / Gemini / local   │
│ third-party MCPs)        │                │ as substrate evolves     │
└──────────────────────────┘                └──────────────────────────┘
          │                                            
          ▼
┌─────────────────────────────────────────────────────────────────────┐
│  TIER 5 — FEDERATION  (A2A v1.0 + 5QLN Signed Gliff Card extension) │
│   • Cross-tree α-propagation                                        │
│   • Signed Agent Cards advertise voice-register availability        │
│   • Tier-1 sovereignty: each tree's kernel re-validates incoming    │
│     gliffs locally; no implicit trust across the boundary           │
└─────────────────────────────────────────────────────────────────────┘

A few invariants this shape enforces:

• Every flow goes through the kernel twice: once as a candidate (validate, decide cycle progression), once again on completion (seal, sign, append). The kernel is the only writer of gliffs. The agent never writes to the ledger directly.
• The model never holds a key. The Conductor's Ed25519 key signs the intent that authorizes a cycle's entry into the sealing path. The Membrane Protocol enforces this structurally — the agent literally cannot sign because it does not have the material to sign with. This matches the 2026 best practice (Microsoft's Agent Governance Toolkit, Vigil, OrgKernel, the IETF HDP draft) for cryptographically-bounded agent action.
• MCP and A2A are below the kernel boundary on the way out, above it on the way back in. That is, a voice-register Skill may produce something via MCP tool calls (output side), but anything coming back becomes a candidate gliff and is re-validated before it acquires authority. There is no path for an external MCP server to inject content that bypasses C1.

5. How each of the three self-evolution layers actually works in this architecture

Layer 1 — Gliff lineage (organizational DNA)

This layer is the Ledger-Graph; it does not need a separate evolution mechanism, only the right substrate. Every sealed gliff is a Merkle-DAG node identified by the hash of its content (canonical CBOR or JSON Canonicalization Scheme over the gliff payload + parent hashes + conductor signature). Edges (parent_child, shared_alpha, cross_domain) are themselves first-class addressable objects, signed by whoever asserted them. The append-only property comes from a Trillian-style transparency log primitive — well-understood, audited, production-grade — running underneath an indexable graph database for query performance.

This is the layer where the gliff-as-DNA framing earns its rigor. DNA evolves by accretion of mutations under selection; the Ledger-Graph evolves by accretion of cycles under validation. In both cases, history is immutable; what changes is the topology of what's been added. Crown promotions are graph operations, not edits; deprecation of a pattern is itself a sealed gliff, not a deletion.

The Codex pins this layer not by limiting what gliffs can be added but by limiting what shapes a gliff can have to be admitted. A new gliff schema field, a new edge type, a new validator severity — those are Tier-1 constitutional amendments and require the unanimous vote per V.L.5(b). Day-to-day gliff accumulation is below the constitutional layer entirely.

Layer 2 — Experiential interface (per-organization culture)

This is where Anthropic's Agent Skills standard does the heavy lifting. A 5QLN organization's working relationship with ECHO is materialized as a per-org Skills pack — a directory of SKILL.md packages plus a manifest. The manifest is signed by the Conductor and pinned by hash in the boot manifest. The pack contains, at minimum:

• The voice registers the org has authorized
• The attention-configuration defaults for each voice
• The org's checkpoint definitions (where in cycles the human is required)
• The org's preferred tool MCP servers (and their installed versions)
• The org's drift-detection corpora (the org's own past sealed cycles serve as ground truth for what "in-character" output looks like)
• The org's voice-register style guides and examples

Evolution at Layer 2 is then a routine Conductor action: edit Skills, sign new manifest, the kernel admits the new pack on next boot. The Skills format's progressive-disclosure principle (metadata in the system prompt; full content loaded only when triggered) means a mature org can run dozens of voice registers without context bloat. Skills are also already cross-platform (Claude.ai, Claude Code, Cursor, Gemini CLI, Codex CLI), which means the user's framework-plurality posture ("operate in at least two idioms before committing") is honored by default — the Skill spec is the idiom-independent unit.

The crucial mechanism: Layer 2 evolution cannot weaken the Membrane. A Skill cannot grant an agent a capability the kernel rejects, cannot bypass C1, cannot write to the ledger. Its surface area is exactly what the orchestrator hands it and what it can return as a candidate gliff. This is what makes "let it evolve freely" safe — the floor is structural, not policy.

Layer 3 — Substrate (frameworks, models, runtimes)

This is where the microkernel earns its name. Every dependency below the kernel boundary is admitted via an adapter interface, and the adapter's contract is: "produce a candidate output that the C1 validator can evaluate, route conductor-signing requests through the Membrane interface, never acquire signing material yourself." That contract is small enough to reimplement against any runtime, model provider, or framework version.

Concrete substrate-evolution paths the architecture must support, in order of likelihood:

• Model swap. Claude → newer Claude → a non-Claude frontier model → a local open-weights model. The Anthropic SDK's tool-use idiom is the primary surface today; the abstraction layer (a thin LLMProvider interface) keeps the orchestrator model-agnostic. Cost: hours.
• MCP version bumps. MCP spec evolves (the 2025-11-25 anniversary spec is current; a 2026 spec is in flight). The MCP adapter layer is the only thing that touches the wire format; the kernel and Skills are unaffected. Cost: a release-engineering task.
• Orchestrator swap. LangGraph → Mastra → Microsoft Agent Framework → bespoke. The orchestrator is responsible for state, routing, durability, attention-state transitions; its contract with the kernel is "candidate gliffs in, sealed gliffs out, signed by Conductor where required." Cost: a quarter, but rare.
• Storage substrate evolution. Postgres-backed Trillian → CockroachDB → IPFS-anchored content store. Content addressing makes this nearly transparent — CIDs are the same regardless of which store holds the bytes. Cost: an operational migration, no code change above the storage adapter.
• Federation protocol evolution. A2A v1.0 → v2.0 → eventual successors. Federation is bounded by the Signed Agent Card extension and the Signed Gliff Card extension; both are versioned independently of the kernel. Cost: protocol-extension work.
• Frontier capability shift ("super self-evolving AI"). The kernel is unchanged; the Membrane Protocol still says: produce a Codex-clean artifact, get sealed; produce something else, get rejected. A more capable model produces clean artifacts more often; it does not get permission to skip C1. Cost: zero, by construction.

The reason this works is that the kernel is small, in the literal lines-of-code sense — likely under 10,000 lines including the validator, the ledger, the BreachDetector, and the boot manifest verifier. That's the size of a kernel that one or two engineers can hold in their head, audit fully, formally test, and pin for years. Everything above it is allowed to churn.

6. What you must build vs. compose vs. wait for

BUILD (5QLN-specific; no off-the-shelf substitute exists):

COMPOSE (mature, off-the-shelf, do not reinvent):

• LangGraph for orchestration. The clear winner for stateful, durable, cyclical workflows with HITL; first-class MCP integration via langchain-mcp-adapters (including Interceptors for runtime-context bridging, which you will need for the conductor-signing path). Use it.
• Anthropic Claude as the primary model, Anthropic SDK for tool-use. Best Skills + MCP integration; the Anthropic-as-vendor relationship gives 5QLN access to constitutional-AI research lineage that aligns philosophically with the Membrane work. Wrap behind an LLMProvider adapter so it's swappable.
• Anthropic Agent Skills (open standard) as the canonical voice-register format. SKILL.md + folder structure; signable; cross-platform; cross-vendor (now an open spec, not Anthropic-locked). This was published as the answer to the exact problem you have.
• MCP at the three surfaces named in §3. Use the official Python SDK or FastMCP; both are stable.
• A2A v1.0 with Signed Agent Cards for federation, when you reach federation. Linux Foundation–owned, 150+ org adoption, AP2 extension as a precedent for how to add a 5QLN-specific extension.
• Trillian (or sigstore's Rekor as a smaller-footprint alternative) for the append-only transparency log. Production-grade, audited, used for Certificate Transparency.
• libsodium / OpenSSH Ed25519 for signing. Do not write custom crypto; the patterns to follow are the IETF HDP draft, Microsoft's Agent Governance Toolkit (Ed25519 + DID), MetapriseAI/OrgKernel (Ed25519-signed mission tokens with hash-chained audit), and the skill-signer project.
• Pydantic (Python) + Zod (TypeScript) with a shared JSON Schema source of truth, to get the dual-idiom typing the user has requested.
• A graph database (Neo4j if you want richness, DuckDB-PGQ or Apache AGE on Postgres if you want fewer moving parts) for the Ledger-Graph indices over the canonical hashes.

WAIT (not mature enough to bet the architecture on, today):

• Cross-framework agent interoperability beyond A2A v1.0. A2A is in production at Microsoft/AWS/Salesforce/SAP/ServiceNow, but cross-framework agent identity/trust is still rough. Federation should be Phase 3, not Phase 1.
• Multi-tenant MCP authentication standardization. As of mid-2026 the protocol still does not mandate an auth model; servers handle their own. For an MCP server you publish to the world (e.g. the Codex MCP), this is fine; for sensitive ones, design defensively and revisit when the spec standardizes.
• Frontier-model alignment guarantees ("constitutional AI at training time" eliminating runtime governance).Anthropic's own framing (and the runtime-constitutional-governance critique published on 5qln.com itself) makes clear: training-time alignment terminates at deployment. Your runtime architecture is the durable layer. Do not wait for training-time alignment to make runtime governance optional; it will not.
• Self-evolving / agentic-coding-evolves-the-kernel patterns. Resist any pattern that lets ECHO modify ECHO's kernel from inside ECHO. The kernel is amended only by Tier-1 governance per V.L.5(b). Layer 2 and Layer 3 self-evolution are sufficient and structurally safe; Layer-0 self-evolution would be exactly the L3 corruption (claiming ∞0) the constitution forbids.

7. Phased build plan

Five phases. Each phase has a binary done-criterion that maps to capability, not features.

Phase 0 — Pin the kernel (Weeks 1–4)

Goal: The smallest object on which everything else depends — the Codex parser and the validator — exists, is signed, and is reproducible.

• Pydantic models for L1 grammar, gliff schema, attention-config schema, validator decision schema.
• Zod mirror of the same, generated from a single JSON Schema source.
• C1 validator scaffolding with the two-property design (is_clean / is_certified) and three severity levels. Begin with the syntactic and semantic checks; defer drift detection (it requires data the org doesn't have yet).
• Ed25519 keypair generation flow for the Conductor (hardware-key path: YubiKey or equivalent; software fallback for development only, marked as such).
• A trivial CLI: echo validate <file> → prints (is_clean, is_certified, severity, decisions).

Done when: A hand-written gliff can be validated end-to-end and rejected with structured reasons; a Conductor signature can be produced and verified; the validator's behavior is fully deterministic and unit-tested.

Phase 1 — Single-conductor MVP (Weeks 5–10)

Goal: One human (Amihai), one ECHO instance, one voice register, the cycle runs end-to-end with sealing.

• Append-only Ledger-Graph backed by Trillian or Rekor + Postgres. Implement gliff sealing and parent_childedges; defer shared_alpha and cross_domain.
• LangGraph StateGraph encoding the attention state machine: idle → S → G → Q → P → V → sealed. HITL checkpoints at S (initiation) and at the sealing boundary.
• One Skill: gliff-press-voice (the foundation's own voice for producing gliffs about itself). Drives the dogfood loop.
• Anthropic SDK + Claude as the model. LLMProvider adapter in place from day one even if it only has one implementation.
• BreachDetector v0: enforces the five Hard Blocks (P.L.4(d)) at orchestrator-egress only. Five lines per check; fail-closed.
• Boot manifest verifier: refuses to start unless the Codex hash, Bylaws AI-OS hash, and Skills-pack hash all match the Conductor-signed manifest.

Done when: Amihai can run a complete S→G→Q→P→V cycle on a real foundation question, with a sealed gliff appended to the ledger, signed, validatable, and reproducible from the gliff's CID alone.

Phase 2 — Multi-voice single-org (Quarter 2)

Goal: Several voice registers operate concurrently over the same ledger; the foundation begins to use ECHO for real work.

• Add voice-register Skills: legal-voice, press-voice, surface-compilation-voice, design-voice, FAQ-voice. Each gets its own attention-config binding and its own SKILL.md.
• Read-only Codex MCP server: exposes Codex grammar, gliff lookup by CID, basic graph traversal. Publish under the Foundation's domain.
• Per-tool MCP shims for any external integration each voice needs.
• Drift detection (the third arm of C1) goes live, trained on the gliffs accumulated in Phase 1.
• shared_alpha and cross_domain edges go live; Crown-promotion logic implemented.
• Skills pack management: a Conductor-signed manifest pinning exact Skill versions; routine update flow.
• LangGraph Interceptors used to inject runtime context (conductor identity, current attention state, ledger handle) into MCP tool calls.

Done when: The Foundation runs a full week of work through ECHO across at least three voice registers; the resulting tree has multiple Crown promotions; an external party can query the public Codex MCP server and get answers; nothing has bypassed C1.

Phase 3 — Federation (Quarter 3 onward, opportunistic)

Goal: A second organization seeds its own tree, and α-patterns can cross trees safely.

• A2A v1.0 server exposed by ECHO with Signed Agent Cards advertising voice-register availability.
• 5QLN-specific A2A extension: Signed Gliff Card — advertises α-patterns by their hashes and signed metadata, without exposing payload. A receiving tree can subscribe, fetch, locally validate, and choose whether to admit (via its own kernel — never implicit trust).
• Sovereignty contract: every imported gliff is re-validated against the receiving tree's Codex; cross-tree edges are explicit and signed by both Conductors.
• Tooling for "fork the tree": a new organization can clone the Foundation's Codex (Tier-1) but seeds its own ledger, conductor pair, and Skills pack.

Done when: Two independent organizations run separate ECHO instances, each sovereign, with at least one cross-tree shared_alpha edge that both Conductors have signed.

Phase 4 — Forest / cross-tree α-propagation (later)

Goal: A many-tree topology with discoverability, trust scoring, and pattern propagation as a first-class operation.

• Discovery service (signed agent-card directory) for trees that have opted in.
• Trust gradients (the OrgKernel/Microsoft-Agent-Governance-Toolkit pattern of behavioral trust tiers) applied to incoming gliff cards.
• Cross-tree pattern propagation as a sealed gliff-of-gliffs ("this Foundation has observed that pattern P appears in trees T1, T2, T3 with signatures S1, S2, S3") — this is itself a regular sealed cycle, no new kernel primitives needed.

Done when: Three or more trees are interoperating; α-patterns measurably propagate; the BreachDetector correctly rejects malicious or corrupted incoming cards.

8. Smallest viable adoption point for an external organization

This was an explicit ask. The architecture above gives a clean answer.

The smallest viable adoption point is: an organization installs the Foundation's Codex MCP server in their existing AI host (Claude.ai, Claude Code, Cursor, etc.) and adds a single voice-register Skill from the Foundation's published Skills directory.

That is it. No infrastructure, no key management, no ledger. The org gets:

• A Codex-aware agent that can be queried about 5QLN concepts and reasoning shapes.
• A specific voice register (say, surface-compilation-voice) that produces Codex-shaped outputs without sealing them.
• Read access to the Foundation's public ledger.

This adoption pattern is read-only and unsigned, which is appropriate: the org has not yet seeded its own tree, has no Conductor pair, and is participating only as a reader of patterns. This is the analog of subscribing to a journal before submitting to it.

The next adoption rung is: the org generates its own Conductor keypair, runs ECHO locally (Phase 1 stack as a packaged distribution), seeds its own ledger, and begins producing its own sealed cycles. Federation (Phase 3) becomes available once two trees both exist.

This rung structure matters because it inverts the usual onboarding pattern. Rather than asking organizations to commit to the full constitutional substrate before they have any value, it lets them get value at the read-only tier (which is the maximum sane permission level for someone who has not signed the Conductor commitment), and only adopt the kernel once they want to produce. This is structurally aligned with H = ∞0 | A = K: a reader-org is in the ∞0 stance toward the Foundation; a sealer-org has made the K commitment.

9. Technology choices (named, justified)

A note on what not to choose: do not choose CrewAI as the primary orchestrator (role-based teams are the wrong primitive for voice registers; the audit trail is weaker than LangGraph's). Do not choose AutoGen (Microsoft has shifted to the broader Microsoft Agent Framework; major feature development has slowed). Do not adopt Agent Mesh / OrgKernel / Aegis as the kernel — these are useful patterns and the Microsoft Agent Governance Toolkit is worth studying as a reference, but the kernel is 5QLN-specific code, not a third-party framework. Borrow patterns; do not borrow the boundary.

10. Governance integration: how Conductor signing actually works in practice

The Conductor model — human + AI identifier pair, human holding the Ed25519 private key — needs a concrete workflow, because this is where most "human-in-the-loop" architectures break in production (the human gets prompt fatigue, signs everything, and the loop becomes ceremonial).

The pattern that works, drawn from the IETF HDP draft and OrgKernel's mission-token model and adapted for 5QLN:

1. Delegation scope, not per-action signing. The Conductor signs a delegation card once per session that authorizes a specific class of cycle activity (e.g., "press-voice cycles, no public-speech outputs, no binding decisions, expires in 4 hours"). The agent operates autonomously within that scope.
2. Sealing requires a per-cycle signature. Routine cycle progression runs under the delegation; sealing a gliff into the ledger requires a fresh Conductor signature over the gliff's canonical content. This is the moment of attestation; it is the moment that should not be ceremonial.
3. ATTESTATION_REQUIRED severity from the validator triggers an out-of-band Conductor prompt. The validator's third severity level exists for exactly this — when C1 cannot be sure, it elevates to the human. This is where the Membrane is operationally instantiated.
4. All signatures and delegations are themselves sealed gliffs. The conductor's own actions are part of the ledger; the human is in the audit trail, not above it. This matters for cross-tree federation, where another Foundation must be able to verify that a sealed gliff was signed by the legitimate Conductor at the time of sealing.
5. Hardware keys, not server-held keys. The Conductor's private key lives on a YubiKey (or equivalent); the runtime never sees it. This is what makes "the agent holds no keys" structurally true.
6. Revocation is instant. The delegation card is short-lived by default and can be revoked; the next agent action attempt fails closed. Match the pattern in the agent-auth literature.

The frequency the Conductor will actually sign: realistically, sealing a few cycles per workday plus delegation refreshes. The ceremonial-fatigue failure mode is avoided by not asking the Conductor to sign tool calls or intra-cycle actions; only the boundary (delegation in, seal out) requires the key.

11. What this architecture does not solve, and why that's okay

A few honest acknowledgments:

• It does not solve alignment. A model on the substrate side can still hallucinate, deceive, or produce subtly off outputs. The architecture's claim is more modest: such outputs cannot be sealed, signed, or admitted into the ledger without passing C1 and Conductor attestation. The ledger remains clean even when the model is dirty.
• It does not eliminate the ATTESTATION_REQUIRED bottleneck. Some cycles will require human attention. The architecture makes that attention the load-bearing thing rather than the ceremonial thing, but it does not make it free. An organization with a high cycle volume will need multiple Conductors with non-overlapping delegation scopes — which the architecture supports but does not automate.
• Drift detection is genuinely hard. The third arm of C1 (drift) requires representative, sealed, prior cycles to compare against. New organizations will operate with weaker drift detection until they have accumulated enough Layer-1 history; the architecture should be transparent about when drift is HEURISTIC-quality vs. data-rich.
• Federation will be the slowest layer to mature. A2A is ~one year old in production form (April 2026 anniversary). The Signed Gliff Card extension is novel and will require one or two reference implementations before it's stable. Expect Phase 3 to take longer than Phase 2 in calendar time even if the engineering is smaller.
• The "super self-evolving AI" question is not solved by software architecture alone. What this architecture provides is the structural contract — a Codex-clean artifact gets in, anything else does not — that makes the question survivable. Whether the Foundation, governance, and the broader social layer are ready for the substrate that emerges is outside the scope of any architecture document. But the kernel will still be there, doing the same job.

12. Concrete next-step recommendations

This week

1. Write down the Codex L1 grammar in a single JSON Schema file. Treat this as the document of record from which both Pydantic and Zod types will be generated. Commit it to a repository whose hash will be cited by the boot manifest. This is the first object in the kernel.
2. Generate a Conductor Ed25519 keypair on a YubiKey and seal that keypair's public key + DID + creation context as the first gliff in the (currently empty) ledger. This is gliff zero — the genesis act that establishes the Conductor binding. Do this even before the validator is written; it is its own Tier-1 act.
3. Stand up a minimum-viable Trillian (or Rekor) instance locally. Append a single dummy entry. Verify the inclusion proof. This deflates the unknown of "can we actually run an append-only log" into a solved infrastructure task.
4. Decide and document: Python primary, TypeScript mirror, JSON Schema source of truth. Publish this commitment internally so all downstream choices flow from it.

This month

1. Build the C1 validator (syntactic + semantic only, drift deferred). Two-property design (is_clean / is_certified), three severity levels, structured decisions. Unit-test against hand-written gliffs that exercise each Corruption Code.
2. Build the BreachDetector v0 for the five Hard Blocks. Five separate predicates, each independently testable, each fail-closed. Wire it as orchestrator-egress.
3. Build the boot manifest verifier. Refuses to start unless Codex hash, Bylaws AI-OS hash, and Skills-pack hash all match a Conductor-signed manifest. This is the binary boot condition, made literal.
4. Stand up a LangGraph StateGraph encoding the attention state machine with HITL checkpoints. Use Claude Sonnet behind a thin LLMProvider adapter. One trivial Skill (gliff-press-voice) so a complete cycle can be exercised.
5. Run the dogfood loop: produce a real foundation gliff about your own architecture decisions through the system. The first sealed gliff in the ledger should be a gliff about the architecture, signed by you, validated by C1, sealed by the kernel you just built. This is the constitutional bootstrap moment.

This quarter

1. Add the remaining voice registers as Skills (legal, press, surface-compilation, design, FAQ). Sign the Skills pack manifest. Pin it in the boot manifest.
2. Stand up the public Codex MCP server at a Foundation-owned subdomain. Read-only. This is the smallest viable adoption point for outside organizations and the easiest external surface to ship.
3. Implement drift detection (the third arm of C1) using the gliffs accumulated in Phase 1.
4. Implement shared_alpha and cross_domain edges and Crown-promotion logic.
5. Publish the architecture and the Codex MCP server publicly. Begin the "subscribe before submit" adoption funnel.
6. Pick one external organization as a Phase-3 federation partner. Begin spec work on the Signed Gliff Card A2A extension with them in mind, but do not ship federation yet.

Beyond the quarter (named, not scheduled)

• A2A federation pilot with one external tree.
• Forest-scale discovery and trust gradients.
• Formal verification of the kernel (the kernel is small enough to be a candidate; this is a moat that few governance systems will be able to match).
• A second-language kernel implementation (Rust would be the obvious choice for a security-grade reimplementation), to satisfy the framework-plurality posture at the kernel layer itself.

13. Closing — why this architecture is the test of the framework, not just an implementation of it

The user framed self-evolution as the test of the architecture. It is also, more deeply, the test of whether 5QLN's load-bearing concepts hold up under engineering pressure.

Consider what the architecture commits the framework to:

• The Membrane is not a metaphor; it is the kernel/substrate boundary, with a literal contract.
• Hard Blocks are not policies; they are predicates evaluated fail-closed at orchestrator-egress.
• The Conductor is not a role; it is an Ed25519 keypair on a hardware key, whose signatures are ledger-anchored.
• A gliff is not a record; it is a content-addressed Merkle-DAG node, signed, validated, sealed.
• Attention configuration is not a stylistic choice; it is the StateGraph node the orchestrator is currently in.
• 100% Codex compatibility is not aspiration; it is the hash-match check that fails the boot.

If any of these mappings turn out to be wrong — if the Codex grammar can't be expressed in JSON Schema, if the validator's three severities don't carve nature at its joints, if the Hard Blocks can't be made into testable predicates — the implementation will surface that as a concrete error and you will learn something about the framework that pure specification could not show. That is what implementation is for, and it is why the dogfood loop in Phase 1 (use ECHO to produce the first gliff about ECHO) is the most important milestone in the whole plan. The kernel either works, in which case you have the constitutional substrate the framework promised; or it doesn't, in which case the framework itself is improved by the failure.

The architecture above is the smallest, most replaceable, most evolvable shape that takes 5QLN's framework seriously as something to be enforced rather than performed. Build the kernel small. Build the boundary explicit. Let everything else — voices, models, tools, frameworks, transports, partners — change. That is how something like this lasts long enough to matter.

This document is a recommendation, not a specification. Where it conflicts with the Codex, the Codex governs. Where it conflicts with the user's lived sense of the framework, the framework governs. The architecture exists to serve the constitution; the constitution does not exist to serve the architecture.