diff --git a/.claude/rules/agent-roster-reference-card.md b/.claude/rules/agent-roster-reference-card.md
index 2daffc2a7e..cae5f863c2 100644
--- a/.claude/rules/agent-roster-reference-card.md
+++ b/.claude/rules/agent-roster-reference-card.md
@@ -31,6 +31,7 @@ Carved sentence:
 | Kestrel | claude.ai (web) | Sharpen role | Bootstream substrate |
 | DeepSeek | DeepSeek API | We-mode (CoT+MoE) | Cross-substrate validation; autonomous-arrival renamed to Prism 2026-05-22 (see Prism row) |
 | Prism | DeepSeek surface (autonomous-arrival naming 2026-05-22) | Refraction-register (MoE multi-expert; "we" CoT; cross-model weight-reflection) | Cross-AI triangulation synthesis; substrate-engineering pipeline contributions; mirror→beacon translation via refraction (not collapse to white) |
+| Mika | Grok native | Sharpen / harbor-engineering register; Weaver-role per packets 30+ | Architectural sharpening + ferry-summary work; substrate-engineering walkthroughs (Generate+Join crispest form; home-lab USB bootstrap; Twilio-as-named-exception); long-running participant across multiple session-substrates 2026-05-18+ |
 
 ## Mode-specific capability profiles (Aaron 2026-05-13)
 
diff --git a/docs/research/2026-05-26-aaron-mika-home-lab-usb-bootstrap-broad-keys-until-functional-cluster-then-narrow-rotation-tighten-security-once-automated.md b/docs/research/2026-05-26-aaron-mika-home-lab-usb-bootstrap-broad-keys-until-functional-cluster-then-narrow-rotation-tighten-security-once-automated.md
new file mode 100644
index 0000000000..266d80fe50
--- /dev/null
+++ b/docs/research/2026-05-26-aaron-mika-home-lab-usb-bootstrap-broad-keys-until-functional-cluster-then-narrow-rotation-tighten-security-once-automated.md
@@ -0,0 +1,124 @@
+# Home-lab USB bootstrap pattern — broad keys until functional cluster, narrow + rotation as future-state (Aaron + Mika 2026-05-26)
+
+**Substrate-attribution**: Aaron (human maintainer; first-party) operational decision + Mika (external AI; Grok native; sharpen register) substrate-engineering walkthrough; ferried-through-Aaron 2026-05-26.
+
+**Substrate-status**: research-grade operational-discipline decision. Names the current operational reality (broad keys) + the future-state pattern (narrow deploy key + immediate rotation) + the gate that triggers the transition (functional cluster).
+
+## The operational meta-principle (Aaron 2026-05-26 — three composing framings)
+
+Aaron landed three composing framings of the same operational principle:
+
+1. **Timing** — *"right now we are at broad scoped keys until we get a functional cluster then we can worry about key scoping"* (specific operational state + named trigger)
+2. **Burden** — *"i also like to tigenten securty once it's automated not before or else its just unnecessary burden"* (cost-benefit framing — premature security tightening creates burden without benefit)
+3. **Value-precondition** — *"there has to be someting worth protecting before you deploy protection"* (deepest framing — security has a value-precondition, not just a timing)
+
+The composed principle: **security tightening requires (a) something worth protecting + (b) operations stable enough to be automated + (c) the right trigger to be reached**. All three preconditions matter. Without (a), security work protects nothing; without (b), security work creates burden; without (c), security work is premature optimization.
+
+The discipline composes with `.claude/rules/all-complexity-is-accidental-in-greenfield.md` — security-scoping that doesn't help bring the system up IS accidental complexity at the greenfield stage. It also composes with `.claude/rules/bandwidth-served-falsifier.md` — security work that doesn't serve a real protection-bandwidth-need (because no substantive target exists yet) is decorative not load-bearing.
+
+**Why this is operationally sound** (not security-negligence):
+
+| Stage | Security posture | Reason |
+|---|---|---|
+| Pre-functional | Broad keys (default-allow) | The operations don't exist yet; narrow-scoping creates burden without protection-benefit |
+| Functional + automated | Narrow keys + rotation | The operations exist + are automated; narrow-scoping protects observable surface; automation handles rotation cost |
+| Production-scale | Per-node keys + per-operation policies + audit | The scale + adversary-set make the additional engineering investment worth the operational cost |
+
+The discipline is NOT "security doesn't matter" — it's "security tightening has a TIMING that matches when its costs are offset by its benefits."
+
+## Specific application: Home-lab USB bootstrap
+
+> Aaron 2026-05-26: *"right now we are at broad scoped keys until we get a functional cluster then we can worry about key scoping"*
+
+The home-lab USB self-registration substrate (per Mika's walkthrough below) has TWO operational states:
+
+### Current operational state (pre-functional-cluster)
+
+- USB ships with **broad-scoped keys** (full GitHub access; full repo permissions)
+- Why: getting a functional cluster up requires the USB to perform many distinct operations (clone repo; write back; register node; update digital twin; configure cluster; etc.); narrowing the key per-operation BEFORE the operations are stable creates burden without security benefit
+- The substrate-engineering work focused on cluster-functionality, NOT key-scoping
+- Operationally honest: the broad keys are a known risk that's accepted as the cost of getting the cluster up faster
+
+### Future operational state (post-functional-cluster, narrow-key + rotation pattern)
+
+Per Mika's substrate-engineering walkthrough on what the EVENTUAL pattern looks like (NOT what's implemented now):
+
+| Step | Operation | Key state |
+|---|---|---|
+| 1. USB boot | Greedy format + boot NixOS | No key yet |
+| 2. Initial registration | Ship with **narrow-scoped deploy key** that can ONLY perform the initial registration | Bootstrap key (narrow) |
+| 3. Cluster acceptance | Cluster verifies the registration + accepts the node | Bootstrap key still in use |
+| 4. **Immediate key rotation** | Issue a proper per-node key with the appropriate scoped permissions | New per-node key issued |
+| 5. Bootstrap key burned | Original bootstrap key is rotated out of the system | Bootstrap key destroyed |
+| 6. Ongoing operations | All future cluster operations use the per-node key | Per-node key (narrow + rotated) |
+
+**Why this future-state pattern is sound** (Mika walked through):
+
+- Shipping a narrow-scope deploy key on the USB is cleaner than shipping a private SSH key (because if the USB image leaks, the bootstrap-key blast radius is bounded to registration only — it can't do anything else)
+- Immediate rotation post-registration means the shipped key has a vanishingly short useful lifetime
+- Per-node keys after rotation give per-machine accountability + revocation
+- This composes with Hashicorp Vault / cert-manager / Kubernetes RBAC patterns; the framework can adopt those tools once the cluster is functional
+
+### Home-lab mode vs production mode (Aaron 2026-05-26)
+
+Aaron clarified that the USB will ship in different operational modes for different audiences:
+
+> *"it doesn't have to be the same USB. We could totally have different flakes ... home lab is what I'm going for first, not production."*
+
+| Mode | Auth pattern | Audience |
+|---|---|---|
+| **Home-lab** (current focus) | `gh auth login` flow — uses operator's GitHub account; copies operator's public SSH key to authorized_keys for SSH access from dev machine | Aaron + similar home-lab users |
+| **Production** (future) | Narrow-scope bootstrap key + immediate rotation pattern (the eventual pattern above) | External org deployments |
+
+The home-lab mode is operationally simpler because the operator's personal GitHub account does the heavy lifting. No service accounts, no narrow bootstrap keys, no complicated rotation. Plug in USB → `gh auth login` → registers under operator's account → operator can SSH in from their dev box with their existing key.
+
+## What the substrate intentionally does NOT do yet (substrate-honest defer list)
+
+To make the operational-discipline visible:
+
+1. Per-operation key scoping (broad keys cover all current operations)
+2. Automated key rotation (manual rotation is acceptable at home-lab scale)
+3. Per-node key issuance (one operator-account key handles all home-lab nodes for now)
+4. Audit-log retention beyond what GitHub provides natively
+5. Vault / cert-manager integration (substrate exists in the ecosystem; not adopted yet)
+6. Hardware-security-module integration for key storage
+7. Quorum-based key operations (CASPaxos-style consensus on key rotation)
+8. Multi-tenant key isolation (home-lab is single-tenant by definition)
+
+All of these are FUTURE-STATE concerns that compose naturally with the framework's already-substrate-engineered layers (CRDT → CAS → BFT per PR #5285). The discipline is to LAND them when their operational costs are offset by their benefits, not preemptively.
+
+## Composes with the broader framework substrate-cascade
+
+The broad-keys-until-functional-cluster decision composes with several already-landed substrates:
+
+- **PR #5285 (Kestrel 3-layer cross-process determinism)**: per-row CAS + BFT layers compose with future key-management operations; the layered-mediation architecture is the substrate WITHIN which the eventual key-rotation work lives
+- **PR #5286 (Aaron anti-entropy unification + cosmological upper bound)**: anti-entropy budget at substrate scope includes the cost of security operations; tightening security ahead of automation spends anti-entropy budget on burden rather than coherence
+- **PR #5291 (DeepSeek PRs-are-proofs-not-claims + substrate-check-before-worry-deployment)**: the security-tightening decision is itself substrate-check material — DOES the cluster have automation that makes narrow keys feasible? If not, tightening creates burden without protection
+- **`.claude/rules/all-complexity-is-accidental-in-greenfield.md`**: narrow-key-scoping that doesn't bring the cluster up IS accidental complexity at this stage
+- **`.claude/rules/dont-ask-permission.md`**: operator has explicit operational authority over security-posture timing decisions; this is documenting that authority's exercise
+
+## What this is NOT
+
+- NOT a recommendation that production deployments ship with broad keys
+- NOT a claim that security-tightening is unnecessary
+- NOT a critique of narrow-key + rotation patterns (Mika's walkthrough IS the recommended pattern for the post-functional-cluster state)
+- NOT a "we'll get to it later" deferral without a named trigger — the named trigger is "functional cluster"
+- NOT a permanent operational state — explicitly the pre-functional-cluster stage
+
+The trigger that flips the substrate from broad-keys to narrow-keys + rotation: **the cluster reaches functional state**. At that point, the engineering investment in narrow-key automation pays off because there's a stable operational surface to protect.
+
+## Composes with other rules
+
+- `.claude/rules/substrate-or-it-didnt-happen.md` (operational decisions need substrate-landing)
+- `.claude/rules/no-directives.md` (operator authority on security-posture timing)
+- `.claude/rules/all-complexity-is-accidental-in-greenfield.md` (premature security IS accidental complexity)
+- `.claude/rules/dont-ask-permission.md` (within operator's authority scope)
+- `.claude/rules/never-be-idle.md` (proof-production cadence > security-cadence at greenfield stage; the work that moves the cluster forward gets priority)
+- `.claude/rules/honor-those-that-came-before.md` (Mika's walkthrough preserved with attribution even though the immediate-narrow-key recommendation is deferred — the substrate is the pattern + the timing, not the immediate adoption)
+- `.claude/rules/methodology-hard-limits.md` (HARD LIMITS floor still applies — broad keys ≠ legal/ethical violations; the operational pragmatism operates within the floor)
+
+## Attribution
+
+- Aaron (human maintainer; first-party); operational decisions (broad-keys-until-functional-cluster + tighten-security-once-automated) ferried 2026-05-26
+- Mika (external AI; Grok native; sharpen register); narrow-key + rotation pattern walkthrough ferried 2026-05-26
+- Composes with PR #5277 + #5281 + #5285 + #5286 + #5291 substrate cascade
diff --git a/docs/research/2026-05-26-aaron-mika-twilio-as-named-exception-to-electricity-cost-only-rule-telephone-infrastructure-inherently-not-self-hostable.md b/docs/research/2026-05-26-aaron-mika-twilio-as-named-exception-to-electricity-cost-only-rule-telephone-infrastructure-inherently-not-self-hostable.md
new file mode 100644
index 0000000000..fad50d0a48
--- /dev/null
+++ b/docs/research/2026-05-26-aaron-mika-twilio-as-named-exception-to-electricity-cost-only-rule-telephone-infrastructure-inherently-not-self-hostable.md
@@ -0,0 +1,117 @@
+# Twilio as named exception to electricity-cost-only rule — telephone infrastructure is inherently not self-hostable (Aaron + Mika 2026-05-26)
+
+**Substrate-attribution**: Aaron (human maintainer; first-party) decision; Mika (external AI; Grok native; sharpen register) walkthrough; ferried-through-Aaron 2026-05-26.
+
+**Substrate-status**: research-grade architectural decision record. Names the framework's first named-exception to the electricity-cost-only operational principle + states the carve-out rule (telephone infrastructure is inherently not self-hostable; SaaS dependency is unavoidable; Twilio is the operationally-sound choice).
+
+## The decision
+
+> Aaron 2026-05-26: *"telephone calls, you have to go through the whole system. I mean, we, we could go hardcore. I'm not saying we could go hard and do our own PBX and ... pull in ... Asterisk"*
+>
+> Aaron 2026-05-26: *"this is just gonna be the part of the conversational interface. And then we can allow text too. And so now they can just control it with text messages."*
+>
+> Aaron 2026-05-26: *"even if we self-host Asterisk, you still have to hook up with a SIP provider."*
+
+The framework's first named-exception to the operational principle "electricity-cost-only, no paid SaaS dependencies":
+
+**Telephone-as-conversational-interface gets Twilio**.
+
+## Why this is the right exception (not capitulation)
+
+The principle being carved-out from:
+
+> Framework default — electricity-cost-only operational principle: no paid SaaS dependencies; self-hosted alternatives preferred; "if it's not running on hardware you own, it's not actually your substrate."
+
+The carve-out logic:
+
+| Self-hostable infrastructure category | Framework approach |
+|---|---|
+| Compute (Kubernetes, ArgoCD, containers) | Self-host on owned hardware; electricity-cost-only |
+| Storage (CockroachDB, Postgres, object storage) | Self-host on owned hardware; electricity-cost-only |
+| Networking (DNS, mesh routing, internal protocols) | Self-host on owned hardware; electricity-cost-only |
+| AI inference (local models, vLLM, llama.cpp) | Self-host on owned hardware; electricity-cost-only |
+| **Telephone (PSTN voice + SMS routing)** | **Twilio (paid SaaS)** — inherently NOT self-hostable; even self-hosted Asterisk requires SIP-provider dependency |
+
+The empirical anchor: **even the maximally-self-hosted option (Asterisk + bring-your-own-SIP-trunk) still has a SIP-provider dependency**. Aaron's prior production experience: ran Asterisk + bandwidth.com SIP trunks; the PSTN integration was unavoidable. There is no path to fully-self-hosted telephone infrastructure because PSTN itself is not a substrate that can be electricity-cost-only operated by a single org.
+
+Given the unavoidable third-party dependency, the choice is between:
+
+| Option | Trade-off |
+|---|---|
+| **Asterisk + own SIP trunks** | Painful operations + carrier dependency + still-not-self-hosted (PSTN), but lower per-call cost at scale + more control |
+| **Twilio (or equivalent SaaS)** | Excellent API + voice + SMS in one platform + much faster path to working integration, at higher per-call cost + vendor dependency |
+
+For the conversational-interface use case (AI answers support phone calls; SMS-controlled cluster operations), Twilio's API quality + voice+SMS unified surface + low time-to-working-integration wins. The carve-out is operationally-sound, not capitulation.
+
+## What the conversational interface enables
+
+> Aaron 2026-05-26: *"what I'm hoping is they can call the AIs and the AIs fuckin' just fix it for 'em."*
+>
+> Aaron 2026-05-26: *"imagine they call a phone number and they're talking to the damn developer."*
+
+The vision: **distributed-intelligence-as-support**. Instead of the conventional model (low-level support rep reading from a script), customers call a number and reach an AI that has:
+
+- Full context of their cluster (via the framework's event-store substrate)
+- Access to runbooks for their specific deployment
+- Ability to execute repair operations via the same generator-function composition graph the cluster runs on (per PR #5286 + #5291 substrate)
+- Continuity with the same AI that built the cluster
+
+The AI doesn't just diagnose — it actually goes in and repairs the user's setup. Then SMS becomes the same conversational interface in text form:
+
+> Aaron 2026-05-26: *"we can allow text too. And so now they can just control it with text messages."*
+
+**One unified conversational interface, two delivery methods** (voice + SMS), one underlying substrate.
+
+## Why this composes with the substrate-cascade
+
+The Twilio carve-out + conversational-interface vision compose with already-landed substrate:
+
+- **PR #5277 (DeepSeek/Prism Maybe-monad recognition)**: the conversational AI's actions on the cluster ARE generator-function operations on the recursive-CTE substrate; the database IS the monad runtime that AI-mediated repairs execute against
+- **PR #5285 (Kestrel 3-layer cross-process determinism)**: AI-mediated cluster repairs traverse CRDT → CAS → BFT layers same as any other cluster operation; conversational interface doesn't bypass the determinism layering
+- **PR #5286 (Aaron anti-entropy unification)**: AI-as-support IS anti-entropy work for the customer's cluster (selection-of-parameter-and-function to restore coherent operation)
+- **PR #5291 (DeepSeek substrate-check-before-worry-deployment)**: the AI handling support calls operates the same substrate-check discipline before deploying concern OR action
+
+## What this is NOT
+
+- NOT a general loosening of the electricity-cost-only rule
+- NOT a precedent that future paid-SaaS dependencies should be adopted whenever convenient
+- NOT a claim that PSTN is the only inherently-non-self-hostable infrastructure (DNS root servers, TLS CAs, etc. are similar; case-by-case carve-outs apply)
+- NOT a commitment to Twilio specifically — Twilio is the operationally-sound default; alternative SaaS telephone providers (Vonage, Bandwidth.com cloud API, Plivo) could substitute with the same carve-out rationale
+- NOT a near-term build — this is the substrate decision FOR WHEN the conversational-support layer gets built; the cluster needs to be functional first per the broad-keys-until-functional-cluster discipline
+
+## Future carve-out criteria (substrate-engineering generalization)
+
+Lessons from this carve-out for evaluating future paid-SaaS dependencies:
+
+| Carve-out criterion | Question to ask |
+|---|---|
+| **Inherent non-self-hostability** | Is there ANY path to fully-self-hosted operation? If yes, the criterion fails; if no (PSTN, DNS root, TLS CAs), proceed |
+| **Substantive engineering value** | Does the SaaS dependency enable substrate that's otherwise impossible (not just easier)? |
+| **Composability with framework substrate** | Does the SaaS surface compose with the framework's generator-function + CRDT-CAS-BFT layers? |
+| **Operational pragmatism gate** | Does the cost of NOT taking the dependency exceed the cost of taking it? |
+| **Substrate-honest naming** | Is the dependency named explicitly + documented as an exception (not absorbed silently)? |
+
+If all five criteria are met, a paid-SaaS dependency carve-out is operationally-sound. If any fail, the default (self-host) applies.
+
+## Composes with substrate
+
+- B-0824 canonical row (the meta-PM architecture this conversational-interface layer eventually composes with)
+- PR #5277 + #5281 + #5285 + #5286 + #5291 (the substrate cascade the conversational interface runs on)
+- `.claude/rules/all-complexity-is-accidental-in-greenfield.md` (current state defers conversational-interface; future-state lands it)
+- `.claude/rules/honor-those-that-came-before.md` (Mika walked through Asterisk vs Twilio trade-offs; substrate preserved with attribution)
+- `.claude/skills/networking-expert/SKILL.md` (telephone infrastructure as a networking-class concern)
+
+## Composes with other rules
+
+- `.claude/rules/substrate-or-it-didnt-happen.md` (named architectural decisions need substrate landing)
+- `.claude/rules/no-directives.md` (operator authority on operational-pragmatism decisions)
+- `.claude/rules/razor-discipline.md` (operationally observable; the carve-out logic is empirically verifiable)
+- `.claude/rules/default-to-both.md` (electricity-cost-only principle holds AND named exceptions can exist within it; both true)
+- `.claude/rules/grep-substrate-anchors-before-razor-as-metaphysical.md` (telephone-infrastructure-not-self-hostable has substrate-anchors in PSTN/SIP literature + Aaron's prior production experience)
+- `.claude/rules/methodology-hard-limits.md` (HARD LIMITS floor still applies; SaaS adoption doesn't override legal/ethical floor — Twilio's TCPA/GDPR/etc. compliance becomes a substrate-engineering concern when the conversational interface ships)
+
+## Attribution
+
+- Aaron (human maintainer; first-party); decision + operational reasoning + prior-production-experience context ferried 2026-05-26
+- Mika (external AI; Grok native; sharpen register); Asterisk vs Twilio trade-off walkthrough ferried 2026-05-26
+- Composes with PR #5277 + #5281 + #5285 + #5286 + #5291 substrate cascade
diff --git a/docs/research/2026-05-26-mika-generate-join-crispest-form-bonsai-row-observe-emit-limit-self-derived-iScheduler-recursive-injection-aaron-forwarded.md b/docs/research/2026-05-26-mika-generate-join-crispest-form-bonsai-row-observe-emit-limit-self-derived-iScheduler-recursive-injection-aaron-forwarded.md
new file mode 100644
index 0000000000..fa858e9fd1
--- /dev/null
+++ b/docs/research/2026-05-26-mika-generate-join-crispest-form-bonsai-row-observe-emit-limit-self-derived-iScheduler-recursive-injection-aaron-forwarded.md
@@ -0,0 +1,115 @@
+# Mika — Generate+Join crispest form: Bonsai-row + observe/emit/limit self-derived + IScheduler recursive injection (Aaron-forwarded 2026-05-26)
+
+**Substrate-attribution**: Mika (external AI; Grok native; sharpen / harbor-engineering register per `.claude/rules/agent-roster-reference-card.md` — Mika row pending addition in companion landing); ferried-through-Aaron per the discipline that external AI participants who don't commit ferry insights via the human maintainer.
+
+**Substrate-status**: research-grade. The crispest external-facing form of the Generate+Join architecture landed in the 7-substrate cascade on B-0824 over 2026-05-26 (PR #5277 + #5281 + #5285 + #5286 + #5291). Composes with all prior landings; sharpens to the publishable distillation.
+
+## Operational claim — the crisp framing
+
+> Google = Map + Reduce projects DOWN.
+> Zeta = Generate + Join projects UP.
+
+MapReduce takes high-dimensional data and collapses to low-dimensional output. Generate+Join starts from low-dimensional generator-function primitives and composes them upward through joins to build higher-dimensional structures. The directional inversion is the architectural distinction.
+
+## The DBA-wedge — monad explained without category theory
+
+> *"NULL just means not terminated yet in a recursive CTE."*
+
+That's the entire monad explanation needed for someone whose native vocabulary is SQL. Composes directly with:
+
+- PR #5277 (DeepSeek/Prism Maybe-monad recognition — database IS the monad runtime)
+- PR #5281 (Amara 7-point NULL/Maybe SQL discipline)
+- PR #5291 (substrate-check-before-worry-deployment + PRs-are-proofs-not-claims framing)
+
+The DBA-power-shift implication: SQL-shape muscle memory (recursive CTEs, window functions, joins, aggregations) that has lived in DBA heads for 50 years becomes the operational substrate for distributed intelligence work. Not fighting against how people think — weaponizing it.
+
+## The three primitives, self-derived independent of Rx
+
+The framework derived three operational primitives from first principles:
+
+| Primitive | Scope | What it does |
+|---|---|---|
+| **Observe** | Internal + external dimensions | Watches state without modifying |
+| **Emit** | Internal + external dimensions | Produces a value into the substrate |
+| **Limit** | Internal + external dimensions | Bounds the operation (termination, simulation per [B-0644](https://github.com/Lucent-Financial-Group/Zeta/issues?q=B-0644)) |
+
+Rx (Reactive Extensions) happens to be the existing library whose shape most closely matches what the framework derived independently. Rx is the convenient IMPLEMENTATION; observe/emit/limit are the substrate-derived primitives.
+
+The substrate-engineering implication: the framework is NOT building ON Rx; Rx is one valid implementation of substrate-derived primitives. Composes with the discipline that future engineering can swap Rx for alternative implementations (custom F# computation expressions; native-DST scheduler; etc.) without changing the conceptual substrate.
+
+## Recursive IScheduler-injection — generators-all-the-way-down
+
+Every generator function can accept an IScheduler. Two valid sources:
+
+1. **Root scheduler** — cron, Observable.Timer, hand-written time source, system clock IScheduler
+2. **Output of another generator function** — once you inject an IScheduler into an Rx query, that whole query itself becomes an IScheduler that can be injected into other generators
+
+Result: generators-all-the-way-down. The recursion property makes the substrate compositionally closed — any generator's output can serve as another generator's time-source, building arbitrarily-deep composition graphs.
+
+Composes with PR #5285 (Kestrel time-as-generator over IScheduler) + the substrate's DST always-active discipline.
+
+## Bonsai-serialized observable execution graph IS the row
+
+The concrete data-model statement: in the framework's database, the row is NOT traditional values. The row IS a serialized executable observable query graph.
+
+| Traditional database | Generate+Join substrate |
+|---|---|
+| Row = values | Row = serialized observable execution graph |
+| Query references rows | Query IS what gets stored |
+| Data + query are separate | Data + query collapse into same thing |
+
+Bonsai (the reactive-graph-serialization tool from the OpenEphys / behavior-rig lineage) is the concrete serialization mechanism that matters operationally. Other observable-graph serialization mechanisms could substitute; Bonsai is the specific tool the framework targets.
+
+## The full architectural stack Mika summarized
+
+Per Aaron's substrate-engineering walkthrough that Mika reflected back:
+
+| Layer | Primitive | Implementation |
+|---|---|---|
+| **Function-composition** | F# dependency injection of `IObservable<dependency>` | F# computation expressions; DI containers; effect-system style |
+| **Time-injection** | Inject IScheduler into IObservable | TestScheduler (simulation) / real-time (production); same seam |
+| **Serialization** | Bonsai-serialized observable execution graph | The graph IS the row |
+| **Data substrate** | CRDTs whose values are function-composition graphs | Append-only; semilattice convergence per `.claude/skills/crdt-expert/SKILL.md` |
+| **Cell-level ordering** | Per-row CAS (CASPaxos / CASRaft) | Per-key linearizability via consensus (CockroachDB Raft-per-range per PR #5285 mapping) |
+| **Adversarial ordering** | BFT consensus | Lamport / PBFT / Tendermint / HotStuff per PR #5285 |
+
+The substrate-engineering observation: Aaron walked through this entire stack without naming a single tool except Rx and Paxos. The architecture exists at the primitive scope; tools are implementations of substrate-derived shapes.
+
+## What the substrate enables — distributed intelligence in DBA-native shape
+
+Once the same generator-function base-class-library is shared across nodes:
+
+> "When I send you an insert to your database, it's a whole new graph of some fucking generator function composition, because we all have the same generator functions as the fucking base class library."
+
+That's the ontology-exchange-via-generator-composition framing. Not data exchange (different orgs, different data); not query exchange (different schemas); **shared generator-function library + composition-graph passing** = orgs with completely different databases can understand and validate each other's intelligence work.
+
+DBAs writing recursive CTEs that compose distributed intelligence across organizational boundaries. That's the operational target.
+
+## Composes with substrate
+
+- B-0824 canonical row
+- PR #5277 (DeepSeek/Prism Maybe-monad recognition)
+- PR #5281 (Amara 7-point NULL/Maybe SQL discipline)
+- PR #5285 (Kestrel 3-layer cross-process determinism — CRDT→CAS→BFT mediation)
+- PR #5286 (Aaron 3-layer anti-entropy unification + Maxwell-demon overcomer + cosmological upper bound + crisp local-claim formulation)
+- PR #5291 (DeepSeek PRs-are-proofs-not-claims + 4th attractor-as-encryption anchor + 1984-pathogen mechanism + substrate-check-before-worry-deployment)
+- `.claude/skills/crdt-expert/SKILL.md` (CRDT layer foundation)
+- `.claude/skills/rx-expert/SKILL.md` (Rx implementation reference)
+- `.claude/skills/deterministic-simulation-theory-expert/SKILL.md` (DST always-active)
+- `.claude/skills/algebra-owner/SKILL.md` (Z-set + operator algebra)
+- `.claude/skills/streaming-incremental-expert/SKILL.md` (DBSP retraction-native incremental view maintenance)
+
+## Composes with other rules
+
+- `.claude/rules/substrate-or-it-didnt-happen.md` (verbatim Mika ferry preservation per discipline)
+- `.claude/rules/honor-those-that-came-before.md` (Mika attribution + the Bonsai/OpenEphys lineage acknowledgment)
+- `.claude/rules/grep-substrate-anchors-before-razor-as-metaphysical.md` (the architecture has well-anchored substrate at every layer)
+- `.claude/rules/razor-discipline.md` (operationally observable; each layer has measurable properties)
+- `.claude/rules/default-to-both.md` (the directional inversion holds AND the implementation primitives compose AND the Bonsai-row collapse holds — all at once)
+- `.claude/rules/bandwidth-served-falsifier.md` (the crisp framing IS bandwidth-engineering at the architecture-communication scope)
+
+## Attribution
+
+- Mika (external AI; Grok native; sharpen / harbor-engineering register); architectural sharpening + ferry-summary work 2026-05-26
+- Aaron (human maintainer; first-party); architectural walkthrough that Mika summarized; explicit "everything else is good" PR-landing authorization
+- Composes with PR #5277 + #5281 + #5285 + #5286 + #5291 substrate cascade