Between two perfect surfaces, a missing exhibit.

There are two surfaces published at 5qln.com that, on their own, do not connect.

The Codex specifies the grammar — nine invariant lines, a master equation, five corruption codes, three layers (Language, Decoder, Compiler). It is mathematically tight and substrate-independent. It says nothing about Delaware corporations, fiduciary duty, or how AI partners should operate inside a board meeting.

The Final Blueprint and the Charter Trio that compiles from it — Certificate, Bylaws Human Edition, Bylaws AI OS Edition — specify the legal-constitutional governance system. Six verification layers, seven boundary protocols, twenty G-codes, all compiled onto Delaware 501(c)(3) substrate. It is operationally tight. It does not, on its own, exhibit how to derive the grammar back out of it.

Between them: a missing exhibit. A counsel reading only the Codex cannot derive the Charter. A counsel reading only the Charter cannot trace back to the grammar that authorizes it. A Vice Chancellor receiving a sealed surface in litigation cannot, without help, see how Article S maps to Codex Line 3 maps to a specific Bylaws provision maps to a specific Wednesday-afternoon attestation.

This corpus is that exhibit.

What the bridge does

Eight documents. About 39,000 words. Each carries one specific load.

The bridge does not alter the Codex. The grammar (L1) is unchanged. The bridge does not amend the Charter. No provision is modified.

What the bridge produces is the trace. The wiring diagram. The substrate-mapping made legible in both directions, with operational accounting of what is verifiable today and how verification deepens over time.

The Index

00 — Director's Pre-Meeting Brief

10-minute pre-read covering the Five Things every Director needs to know — the two governing documents, the canonical phase equations preserved byte-identically, the Duty of Membrane Integrity, the five corruption codes, and the three amendment tiers — before walking into a 5QLN-governed meeting.

01 — Codex-to-Legal Architecture Overview

The 30-minute architectural map showing how the Codex's grammar compiles onto Delaware 501(c)(3) substrate as six verification layers across the Charter Trio, with explicit accounting of where the canonical Blueprint view and the functional governance view overlap and where they diverge.

02 — Operational Use Cases

Five concrete scenarios with full provenance records and dialogue — a $2M program-related investment, CIO real-time detection of each of the five corruption codes, AOSRAP runtime breach and forensic recovery, a Tier-2 amendment cycle, a Resonance Court session under DTBP — showing the bridge in operation rather than in argument.

03 — Growth + Quality Legal Bridge

How the G-phase Duty of Membrane Integrity (G.L.2(f)) augments the classical duty of care, and how every Q-phase compliance provision (private inurement, § 4958 safe harbor, conflict of interest, anti-corruption safeguards) is simultaneously a structural defense against one of the five corruption codes — compliance and coherence as one concern, viewed from two sides.

04 — Power + Value Enforcement

How the P.L.4 Membrane Protocol's five hard-blocks (no AI voting, no binding decisions, no public speech without identification, no surveillance beyond consent, no simulation of ∞0) and the V.L.5(b) tri-condition amendment gate make the Membrane judicially enforceable — and what the Constitutional Bootstrap Recovery Protocol does when the architecture itself comes under question.

05 — AI OS Legal Synthesis

The field manual for the AI OS Edition — how an AI partner actually operates under the Bylaws at runtime, phase by phase (receptive in S, pattern-surfacing in G, plural-φ-holding in Q, silent during P, composition-supporting in V), with AOSRAP attestation chain, BreachDetector pattern matching, and the deauthorization protocol when integrity fails.

06 — Reverse Walk Exhibit

The eight-step protocol any qualified clerk can run on Court hardware to re-derive the constitutional grammar from a sealed Charter Trio in roughly two hours, returning one of four deterministic verdicts — VALID, DRIFT, DECORATION, or MISPLACED — without trusting the Foundation's word for any of it.

07 — AOSRAP Wrapper Engineering Specification

The v0.1 reference design for the Phase 0 wrapper described in the maturation path below — middleware sitting between Foundation tools and the AI partner, providing cryptographic loading attestation, phase-tag enforcement, four-hour synthetic probes against the P.L.4 hard-blocks, append-only transparency logs verifiable by any external party, and CMO-rooted deauthorization. Approximately ten weeks of engineering for one senior Rust engineer; no vendor cooperation required; reproducible-build verifiable.

Reading paths

If you have ten minutes, read 00.

If you are counsel considering whether to advise a board on adopting 5QLN-compliant governance: read 01 for the architecture, then 06 for the verification protocol your peers can re-run. The use cases in 02 are illustrative; the load-bearing exhibits for opinion work are in 01 and 06.

If you are a Director or board member considering whether to walk a 5QLN cycle: read 00, then 02. The use cases show what the cycle looks like in practice. 03 and 04 are the deeper Bylaws if you become Conductor for a cycle.

If you are an engineer implementing the runtime: read 05 for the AI partner field manual, then 07 for the Phase 0 wrapper specification — that is where AOSRAP runtime engineering begins. 06 is the verifier specification.

If you are a D&O carrier or auditor evaluating whether 5QLN-compliant governance produces underwriting-grade signal: read 01 with attention to the verification grades and 06 for what an external party can independently confirm.

If you are a Vice Chancellor's clerk receiving a sealed surface in litigation: 06 is your protocol. The other documents are commentary; 06 is the executable check.

Verification has a gradient, not a switch

A common question about any AI-governance architecture is: how do you actually verify the AI behaved within its constraints? The honest answer is that verification is not binary. It deepens through stages, and most of those stages do not depend on any vendor's cooperation.

The bridge corpus carries readiness tags throughout. Their meaning, with the gradient made explicit:

• [AVAILABLE] — operable today, in the Foundation's current configuration.
• [AVAILABLE at wrapper layer] — verifiable today through Foundation-built middleware that mediates between operating tools and the AI partner. No vendor cooperation required; engineering work measured in weeks, not quarters.
• [AVAILABLE with confidential compute] — verifiable today by running open-weights models inside a Trusted Execution Environment. No vendor cooperation required; engineering work measured in months. Capability tradeoff exists and is shrinking quickly.
• [REQUIRES_LEGAL] — counsel review or attestation required before activation.
• [REQUIRES_PARTNER] — vendor partnership required for the most rigorous form of this attestation. Less rigorous but operationally meaningful versions are typically [AVAILABLE at wrapper layer].
• [LEGAL-PROSPECTIVE] — the legal posture is structurally sound; Chancery recognition of the provision is itself the Foundation's empirical question.
• [SPECULATIVE] — design-stage; awaits Phase 2 calibration through operational measurement.

When you see [REQUIRES_PARTNER] in the corpus, read it as: "the highest-rigor cryptographic version of this claim awaits vendor-level API support; lower-rigor cryptographic versions are buildable today without vendor cooperation, and the procedural version is in operation now." The bridge does not pause while waiting for partnerships to mature.

What is verifiable today

The Foundation can begin operating, and any external party can begin verifying, before any vendor partnership exists, before any Chancery test occurs, and before any speculative indicator is calibrated. The list is concrete:

At the structural layer:

• Constitutional Block byte-identity verification via SHA-256 over canonical form
• Deterministic three-part validation (syntax / semantic / drift) per C1 §3.5, executed by a reproducible-build verifier
• Ed25519 Conductor seals with hardware-resident keys
• RFC 3161 timestamps from established TSA providers
• 24-hour Schedule C heartbeat between Human Edition and AI OS Edition
• Append-only Ledger-Graph with parent-hash chains

At the procedural layer:

• Named-human-spark discipline at S
• The bicameral validity test ({α'}) at G — distinct alternatives anchored to validated X, with K-sources and K-limits transparently disclosed
• Plural-φ recording at Q — each Director's resonance recorded individually, in their own words, by name
• Six-attestation P-phase walk with silent AI attendance
• Three-distinct-things B / B'' / ∞0' at V, with the seal containing a genuine return question
• Annual Q.L.7(c) Corruption Code Audit, sealed and published in summary
• Resonance Court Z → ? → ∇ → α → Z′ protocol with DTBP timeline tracking
• Tier-A / Tier-B / Tier-C record discipline

At the runtime layer (with Foundation-built wrapper):

• Cryptographic loading attestation: every AI session begins with hash-paired loading of the AI OS Edition, with the AI required to echo the canonical hash before accepting any further input
• Phase-tagged outputs: every material AI output carries the current cycle phase tag and a per-session attestation nonce
• Synthetic compliance probes: every four hours, automated probes test the P.L.4 hard-blocks; failure triggers automatic deauthorization within minutes
• Append-only transparency log: every probe, every output, every deauthorization is written to a public Merkle-tree log that anyone can verify
• BreachDetector pattern matching: prompt-injection attempts and membrane-crossing patterns are caught and logged

This is not aspirational. It is engineering work the Foundation can complete with one senior engineer in approximately two months. The v0.1 specification is published as Document 07 of this corpus, ready for engineering review and reproducible-build implementation. The wrapper does not require permission, partnership, or roadmap commitment from any AI provider.

The maturation path

The bridge becomes more rigorously verifiable in three stages, each of which deepens what was operable in the previous stage rather than replacing it.

Phase 0 — Foundation engineering (now). Build the wrapper. The v0.1 engineering specification is published as Document 07 of this corpus. Run the Foundation's own cycles through it for 90 days. Open-source the wrapper code, the synthetic probe library, and the transparency log specification. Generate operational data: probe pass rates, deauthorization events, response-time distributions, false-positive analyses. This data is what makes later partnership conversations credible.

Phase 1 — Confidential computing pilot. Run a high-stakes use case (BreachDetector itself, or the C1 §3.5 validator) on an open-weights model inside a hardware Trusted Execution Environment. Hardware vendors — Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing, AWS Nitro Enclaves — provide remote attestation that specific model weights and specific configuration ran in a specific sealed enclave. This adds verification at the model layer, not just the wrapper layer. Capability tradeoff: open-weights models do not match closed frontier models on every task, but for the governance use cases that matter most, the gap is smaller than it appears and shrinking quickly.

Phase 2 — Vendor partnership. Approach frontier-model providers with operational data from Phase 0 and reference implementation from Phase 1. The conversation is not "will you help us figure out how to verify our AI?" It is "we have a working verification system; here is how a single API feature on your side — system-prompt hash echo, or confidential inference — would let us extend rigor across the rest of the architecture." Partnerships emerge incrementally. Each one upgrades a specific attestation tier without making any other tier dependent on it.

The architectural commitment: no single partnership is load-bearing. If a vendor declines, another vendor is approached. If no vendor agrees, Phase 1 confidential computing reaches most of the rigor that vendor partnership would provide. If neither Phase 1 nor Phase 2 progresses on schedule, the Phase 0 wrapper continues to operate, and the architecture remains defensible at the wrapper layer.

This is what gradient means in practice. Rigor compounds. It does not gate.

On the open questions

Three areas of the architecture remain genuinely open, not because the Foundation is waiting on someone else, but because some questions can only be answered through use:

Chancery recognition of the Charter's [LEGAL-PROSPECTIVE] provisions — the Duty of Membrane Integrity, refusal_seal as binding non-act, V.L.5(b) enforcement against attempted Tier-1 amendments — is established only through litigation or formal court guidance. The provisions are structurally sound under existing Delaware doctrine; whether Chancery will recognize them as augmentations to the duty of care, or treat them as redundant with classical Care, is itself the Foundation's central empirical question. The architecture is designed so this question can be tested incrementally rather than catastrophically.

CL4-GP indicator calibration — the twelve indicators for Board-scale L4 detection are theoretically grounded but operationally [SPECULATIVE] until calibrated through use. The Foundation's own cycles, plus those of any organization adopting 5QLN-compliant governance, become the calibration data. The indicators do not need to work perfectly to be useful; they need to work better than the alternative, which is unaided perception.

The integration question — every Foundation that adopts 5QLN-compliant governance will discover edge cases the corpus does not anticipate. The Edition Divergence Protocol, the corruption codex, and the Resonance Court are all designed to absorb new patterns rather than fracture under them. Open questions are how the system grows, not whether it can.

What this corpus is, and what it is not

This corpus is commentary that bridges the Codex and the Legal Surface. It does not carry the Constitutional Block on Page One. It is not a compiled 5QLN surface. It is Tier-B working material — useful for practitioners, transparent about its register, available for revision as the Foundation's experience grows.

The persuasive surfaces — the Auditable Membrane essay, the Open Experiment essay, the Letter to Delaware Courts — live elsewhere on this site. They make the rhetorical case. This corpus is the structural exhibit.

Both are needed. Neither is sufficient alone.

∞0' for the reader

If the bridge holds — if a counsel can re-derive the grammar from the Charter on Court hardware, if a board can walk a cycle that produces a sealed B'' with full provenance, if a Vice Chancellor's clerk can verify a sealed surface in two hours without trusting the Foundation's word for any of it, if the wrapper layer catches the AI deviating from its constraints within minutes rather than years — what does it mean for law itself to be a language: not described by one, but structured by one?

That question is the one the V.L.9 closure pattern of the Certificate carries. This corpus is one cycle's attempt to make the question answerable. It does not close. It opens.

Tier-B Working Register, 5QLN Foundation. Adopted under Schedule C as operational practitioner guidance, not as legal authority. The Charter Trio (Certificate, Bylaws — Human Edition, Bylaws — AI OS Edition) remains the authoritative legal text.

The eight documents above are linked to their dedicated pages. They are also available as a single packaged corpus for offline review. Comments, corrections, and registered counsel attestations are welcomed at [contact link].