docs(doctrine): execution-model ladder v1→v2→v3 (two-tier compile + elixir-tissue)

Capture the operator's forward design extending the Core-First Transcode
Doctrine along the *execution model*, before it dilutes:

- v1 (shipped doctrine): thin classid-keyed adapters, bodies codegen'd at build.
- v2 two-tier compile: ONE Elixir-shaped adapter source, TWO backends —
  existing → compile-time (Askama→Jinja, defadapter! proc-macro, zero runtime
  cost); new → JIT (jitson/Cranelift). Lands on contract::jit
  (JitCompiler/JitTemplate/KernelHandle), already wired.
- v3 elixir-tissue over a fixed Core: DO-shaped business logic = replaceable
  tissue (BEAM hot-swap heritage) in an AST-DLL, persisted/served/hot-swapped
  via SurrealDB; Kanban orchestration reacts to Odoo shapes and dispatches it.
  Lands on contract::kanban (KanbanMove/StepDomain::Kanban), surreal_container
  (view/read=projection, write=commit), and E-SUBSTRATE-IS-THE-SCHEDULER.

The Core-first invariant is unchanged across all three rungs: a body that is
macro-monomorphised, Cranelift-JIT'd, or hot-swapped is STILL a thin adapter
targeting OGAR (classid/SoA/ClassView/UnifiedStep); a tissue adapter needing
state the Core can't hold is STILL a Core gap → EXTEND-CORE. Two new gating
probes (PROBE-COMPILE-TWO-TIER, PROBE-SURREAL-TISSUE-SWAP) floored by the v1
unicharset falsifier. EPIPHANIES E-TRANSCODE-EXEC-LADDER-1 prepended.

https://claude.ai/code/session_016b33swuXE23hKtqxsHu9p1

Author: claude

.claude/board/EPIPHANIES.md

@@ -1,3 +1,27 @@
+## 2026-06-16 — E-TRANSCODE-EXEC-LADDER-1 — the Core-First transcode has a 3-rung execution ladder (codegen → two-tier compile → elixir-tissue over surreal/kanban/odoo), and rungs 2–3 land on already-shipped substrate
+
+**Status:** CONJECTURE (operator forward-design). v1 is the shipped doctrine; v2/v3 are gated on `PROBE-COMPILE-TWO-TIER` + `PROBE-SURREAL-TISSUE-SWAP` (both in `core-first-transcode-doctrine.md`), themselves floored by the v1 `PROBE-OGAR-ADAPTER-UNICHARSET`.
+**Confidence:** Medium — the substrate each rung lands on is shipped and cited (`contract::kanban`, `contract::jit`, `surreal_container`, `E-SUBSTRATE-IS-THE-SCHEDULER`); the two NEW edges (Odoo→kanban ingest, AST-DLL tissue hot-swap) are unbuilt.
+
+**Context.** The Core-First Transcode Doctrine (knowledge doc, captured this session) framed transcode v1: thin classid-keyed adapters target the OGAR Core, bodies codegen'd at build. The operator then extended it along the *execution model* — how a body is compiled and where it lives — across two more rungs.
+
+**The ladder.**
+- **v1 — Core-first codegen.** Bodies generated once at build, targeting `canonical_node` / `classid → ClassView` (#498).
+- **v2 — two-tier compile.** ONE Elixir-shaped adapter source, TWO backends: **existing → compile-time** (Askama→Jinja analogy: a `defadapter!` proc-macro monomorphises to Rust, zero runtime cost), **new → JIT** (jitson/Cranelift). Not greenfield: `contract::jit` already defines `JitCompiler::compile(JitTemplate) → KernelHandle`, compiled by ndarray jitson/Cranelift, cached by n8n-rs `CompiledStyleRegistry`.
+- **v3 — elixir-tissue over a fixed Core.** Core stays immutable; the DO-shaped business logic is **replaceable tissue** (BEAM hot-swap heritage — the deep reason Elixir is the right syntax to steal, not mere ergonomics) living in the **AST-DLL**, persisted + served + hot-swapped via SurrealDB's API; a **Kanban orchestration** reacts to **Odoo shapes** and dispatches the tissue. `contract::kanban`'s header already *names this seam verbatim*: planner emits `KanbanMove` → ractor drives the `KanbanColumn` → `surreal_container` projects the columns as the kanban view, carried as `UnifiedStep{step_type:"kanban.*"}` (`StepDomain::Kanban`). `E-SUBSTRATE-IS-THE-SCHEDULER` already has the substrate emit the schedule via surreal LIVE.
+
+**Why this matters.** The transcode's "holy grail" (Core-first thin adapters) was framed as a build-time codegen story. The execution-model ladder shows the SAME invariant survives JIT and hot-swap: whether a body is macro-monomorphised, Cranelift-JIT'd, or swapped from the SurrealDB AST-DLL, it is STILL a thin adapter targeting the OGAR Core, and a tissue adapter needing state the Core can't hold is STILL a Core gap → EXTEND-CORE. The execution model changes; the iron guard does not. And the two ambitious rungs are ~85% shipped substrate (kanban contract, jit contract, surreal_container, scheduler epiphany) + exactly two unbuilt edges.
+
+**The two unbuilt edges (the honest scope).**
+1. **Odoo→kanban ingest** — map Odoo model records / stage transitions / automated-action triggers into `UnifiedStep{step_type:"kanban.*"}` / `KanbanMove`. No bridge exists today (`AdaWorldAPI/odoo` is the Python ERP, local at `/home/user/odoo`).
+2. **AST-DLL tissue store + hot-swap over SurrealDB** — persist codegen'd/JIT'd DO adapter bodies in `surreal_container`, serve + hot-swap via the surreal API, gated by `kanban.rs`'s read-only-projection / commit ruling. Conceptually supported by the crate's `view`/`read`/`write` split; the swap-without-Core-rebuild parity is unprobed.
+
+**Lesson.** When an operator's forward vision arrives as "vN is X + Y + Z", the high-value move is to *locate each clause on shipped substrate before treating it as new work* — here three of the four load-bearing pieces (kanban seam, JIT tier, surreal projection) already existed and only needed naming + two ingest edges. Capturing the ladder (vs. only v1) prevents the v2/v3 framing from being re-derived next session, and the cited symbols make the "already shipped" claim checkable.
+
+**Cross-ref.** `core-first-transcode-doctrine.md` § "The execution-model ladder (v1 → v2 → v3)" (the canonical statement + the two new probes); `E-SUBSTRATE-IS-THE-SCHEDULER` (the v3 reactive tier this extends); `contract::kanban` / `contract::jit` / `surreal_container` (the shipped substrate); `tesseract-rs-ast-dll-codegen-v1` (the v1 codegen plan whose bodies become the v2/v3 tissue).
+
+---
+
 ## 2026-06-16 — E-UNBLOCK-CASCADE-1 — three independent fork/contract landings collapsed onto the same `MailboxSoaView` seam, closing four queued deliverables in one commit
 
 **Status:** FINDING.

.claude/knowledge/core-first-transcode-doctrine.md

@@ -71,6 +71,65 @@ wrong.** They are the two halves of one mechanism:
 - **`classid → ClassView`** = the "inheritance" — composition of the adapter set
   the manifest names. **No new layer, no new `ValueSchema` variant.**
 
+## The execution-model ladder (v1 → v2 → v3)
+
+The doctrine above is **v1**: a Core targeted by thin adapters, codegen'd once at
+build time. The operator's forward design (2026-06-16) extends it along the
+**execution model** — *how* the adapter body is compiled and *where it lives* —
+**without touching the Core-first invariant.** Each rung is **CONJECTURE**; the
+gating probes are below. The striking part: rungs 2–3 land on substrate that is
+already shipped, not greenfield.
+
+| Rung | What it adds | Already-shipped substrate it lands on | The new edge(s) |
+|---|---|---|---|
+| **v1 — Core-first codegen** | thin classid-keyed adapters target OGAR; bodies codegen'd at build | `canonical_node`; `classid → ClassView` (#498); `tesseract-rs-ast-dll-codegen-v1` | — (this doc) |
+| **v2 — two-tier compile** | ONE Elixir-shaped adapter source, TWO backends: **existing → compile-time** (Askama→Jinja: a proc-macro monomorphises to Rust, zero runtime cost); **new → JIT** (jitson/Cranelift) | `contract::jit` (`JitCompiler` / `JitTemplate` / `KernelHandle`); ndarray jitson/Cranelift; n8n-rs `CompiledStyleRegistry` | the `defadapter!` build-time macro (the Askama half); a JITSON lowering of the adapter shape (the JIT half) |
+| **v3 — elixir-tissue over a fixed Core** | Core stays immutable; the DO-shaped business logic is **replaceable tissue** (BEAM hot-swap heritage) living in the **AST-DLL**, persisted + served + hot-swapped via **SurrealDB's API**; a **Kanban orchestration** reacts to **Odoo shapes** and dispatches the tissue | `contract::kanban` (`KanbanMove` / `KanbanColumn` / `StepDomain::Kanban`); `surreal_container` (`view`/`read` = projection, `write` = commit); `E-SUBSTRATE-IS-THE-SCHEDULER` (substrate emits the schedule, surreal LIVE reactive) | an **Odoo→kanban ingest** (Odoo model/stage shapes → `UnifiedStep{step_type:"kanban.*"}`); the AST-DLL **tissue store + hot-swap** over `surreal_container` |
+
+**Why Elixir is the right syntax to steal (the deep reason, not just ergonomics).**
+Elixir/BEAM's defining property is **hot code swapping of a running system** —
+which is *exactly* "replaceable tissue on a fixed Core." Stealing the syntax
+(multi-clause heads → `match classid`; `|>` → method chain / `defadapter!`;
+`with` → `?`; behaviours → traits; `@spec` → types) buys the ergonomics; the
+architecture buys the swap. "Tissue" is the workspace's own word (`CLAUDE.md`:
+"AriGraph / episodic / SPO / CAM-PQ are thinking tissue — not storage"): the
+Core is the skeleton, the elixir-adapters are organs hot-swappable around it.
+
+**The Core-first invariant is unchanged across all three rungs.** Whether a body
+is build-time-monomorphised (v2 Askama), JIT'd (v2 Cranelift), or hot-swapped
+from the SurrealDB AST-DLL (v3), it is STILL a thin adapter that targets the OGAR
+Core (classid / SoA tenants / ClassView / `UnifiedStep`). A tissue adapter that
+needs state the Core can't hold is STILL a **Core gap → EXTEND-CORE**, never an
+adapter-state-leak. The execution model changes; the iron guard does not.
+
+### Probes that gate the new rungs
+
+```
+PROBE-COMPILE-TWO-TIER (P1, gates v2)
+  Hypothesis: one Elixir-shaped adapter source produces byte-identical behaviour
+              whether lowered by the build-time macro (defadapter!) or the JIT
+              (JITSON → Cranelift).
+  Pass:  macro-compiled and JIT-compiled adapter agree byte-for-byte on the
+         unicharset corpus (and both match the libtesseract oracle).
+  Fail:  divergence ⇒ the shape's semantics aren't backend-independent; fix the
+         shared lowering before shipping two backends.
+
+PROBE-SURREAL-TISSUE-SWAP (P2, gates v3 tissue layer)
+  Hypothesis: a DO adapter served from the surreal_container AST-DLL can be
+              hot-swapped (replace the body) WITHOUT rebuilding the Core, and the
+              post-swap invocation still hits byte-parity.
+  Pass:  swap body A→A' via the surreal API; ClassView dispatch picks up A';
+         Core (classid/SoA/ClassView) untouched; parity holds for both.
+  Fail:  the swap forces a Core change ⇒ the boundary isn't where v3 claims.
+
+(the Odoo→kanban ingest is the APPLICATION rung; gated on both probes above plus
+ a separate Odoo-shape → KanbanMove mapping spec, not yet written.)
+```
+
+All three rungs inherit the v1 falsifier (`PROBE-OGAR-ADAPTER-UNICHARSET`, below)
+as their floor: no execution-model elaboration matters until one leaf adapter
+hits byte-parity through a ClassView at all.
+
 ## Scope boundary (where it holds vs. where it must NOT be forced)
 
 - **Holds cleanly** for the *mechanical, data-shaped leaf* methods — unicharset
@@ -142,6 +201,11 @@ CONJECTURE. Do NOT scale the adapter approach across modules until it passes.
 - `AdaWorldAPI/ruff/.claude/plans/cpp-spo-probes-v1.md` — the harvester gating probes.
 - `lance_graph_contract::orchestration` — `OrchestrationBridge` / `UnifiedStep` (the adapter invocation surface).
 - `.claude/knowledge/frankenstein-checklist.md` — composition-failure / flattening guard.
+- `crates/lance-graph-contract/src/jit.rs` — `JitCompiler` / `JitTemplate` / `KernelHandle` (the v2 JIT tier; ndarray jitson/Cranelift compiles, n8n-rs caches).
+- `crates/lance-graph-contract/src/kanban.rs` — `KanbanMove` / `KanbanColumn` / `StepDomain::Kanban` (the v3 orchestration seam; planner emits, ractor drives, surreal projects).
+- `crates/surreal_container/` — the SurrealDB tier (`view`/`read` = projection, `write` = commit) that would host the v3 AST-DLL tissue store + hot-swap.
+- `.claude/board/EPIPHANIES.md` `E-SUBSTRATE-IS-THE-SCHEDULER` — substrate emits the schedule (surreal LIVE reactive); the v3 Odoo→kanban reaction extends it. `E-TRANSCODE-EXEC-LADDER-1` records this ladder.
+- `AdaWorldAPI/odoo` (`/home/user/odoo`) — the v3 shape source (Odoo model/stage shapes → `KanbanMove`).
 
 ## Provenance / credit