Skip to content

Commit eb58758

Browse files
committed
docs(substrate): the spine is the COMPILED ClassView, not SurrealQL (§1.5)
Operator correction (2026-06-29): the facet "versions" are useless because one compiled ClassView recombines all the carvings while sinking into OGAR and getting COMPILED into the binary — NOT parsed from SurrealQL (slow even with JIT). Captures the load-bearing architecture so future sessions invest in the spine, not the membrane: - New §1.5 — the compiled ClassView spine: a. recombines the facet layout (6×(1:2) / 4×(1:2:3) / 3×(1:2:3:4)) — no hardcoded V1/V2/V3 facet "versions"; one compiled reader subsumes them. b. sub-range hierarchy mapping (e.g. 1..3 of 12) + NESTED ClassViews stacked into compiled CONSTRUCTORS (composition of compiled readers, not a runtime interpreter). c. lazy + lazy-lock-reused materialization of the 32×GUID SoA (build once on first touch; the key prerenders nodes with zero value-decode). + why compiled beats parsed, and where SurrealQL sits (storage membrane, never the hot path — ADR-022/023). - §1 pull-back reframed: modes are NOT co-equal — (a) compiled ClassView = spine/hot-path; (b) SurrealQL emit = storage-membrane adapter. - §6 re-prioritised: the compiled ClassView spine is THE priority; #136 Stage A (array<record>) and the od-ontology fork-deletion are membrane work, secondary. Tier-byte arithmetic of each carving to be pinned against FacetCascade before coding — not guessed. Co-Authored-By: Claude <noreply@anthropic.com>
1 parent f93aae4 commit eb58758

1 file changed

Lines changed: 99 additions & 13 deletions

File tree

docs/OGAR-TRANSPILE-SUBSTRATE.md

Lines changed: 99 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -64,9 +64,82 @@ for everything" falls out of the codebook, not out of per-app reimplementation.
6464
reference emitter; per-language emitters (`ogar-emit-rust`, …) follow the
6565
same `CompiledClass → String` seam.
6666

67-
The two modes are not rivals: (a) is the live "pull a class and render it"
68-
path; (b) is the "materialise the class as source for a build target" path.
69-
Both consume the same `CompiledClass`.
67+
These two modes are **not co-equal** (a correction to an earlier framing).
68+
Mode (a), the **compiled `ClassView`**, is the **spine / hot path**: it sinks
69+
into OGAR and is **compiled into the binary** — no parse, no serialization in
70+
the hot path (ADR-022/023). Mode (b), SurrealQL emit, is a **storage-membrane
71+
adapter** (DDL for the SurrealDB boundary); **parsing SurrealQL back is slow —
72+
even JIT'd it loses to compiled code**, so it is never the hot path. See
73+
§1.5 — it is the load-bearing idea of the whole substrate.
74+
75+
---
76+
77+
## 1.5 The spine is the COMPILED `ClassView` (not SurrealQL)
78+
79+
> **Operator, 2026-06-29.** *"The [facet] versions are useless because the
80+
> ClassView can do recombinations of all of them while sinking into OGAR and
81+
> getting COMPILED into binary, and NOT parsed from SurrealQL — which even with
82+
> JIT will be slow."*
83+
84+
This is the heart of the power. A `ClassView` is not a parser and not a fixed
85+
record format — it is a **compiled, flexible, composable reader** over the
86+
facet, baked into the binary. Three properties:
87+
88+
### a. One ClassView *recombines* the facet layout — no "versions"
89+
90+
The 16-byte facet's tier payload is not locked to a single carving. The
91+
ClassView reads it as whichever hierarchical cascade fits the class, by
92+
recombination:
93+
94+
```
95+
6× (1:2) 6 tiers, each a 1:2 hierarchy
96+
4× (1:2:3) 4 tiers, each a 1:2:3 hierarchy
97+
3× (1:2:3:4) 3 tiers, each a 1:2:3:4 hierarchy
98+
```
99+
100+
(the same `3×4`-vs-`4×3` family the GUID canon debates, generalised to the
101+
ClassView's reading). So there is **no need for hardcoded facet "versions"
102+
(V1/V2/V3)** — one compiled ClassView subsumes all the carvings. Hardcoding a
103+
format per version is the thing to *delete*; the ClassView is the flexible
104+
reader that makes versions unnecessary.
105+
106+
### b. Sub-range mapping + nested ClassViews stacked into constructors
107+
108+
The carving need not be uniform. With `6×(1:2)` over 12 fields it is sometimes
109+
more efficient to **map a sub-range — e.g. `1..3` of the 12 — as its own
110+
hierarchy**, and to **stack *nested* ClassViews into constructors** rather than
111+
read one flat layout. A ClassView composes sub-ClassViews; the composition is
112+
built by **constructors compiled into the binary** (the `emit_rust` direction),
113+
never re-derived by parsing a DDL string. Nesting = composition of compiled
114+
readers, not a runtime interpreter.
115+
116+
### c. Lazy, reused materialization of the `32×GUID` SoA
117+
118+
The nested ClassView constructors run **before materializing the `32×`(hex)
119+
GUID struct-of-arrays**, and the SoA is materialized **lazily and lazy-lock
120+
reused** (`LazyLock`-style: build once on first touch, share thereafter). The
121+
key prerenders nodes with zero value-decode (canon: "THE GUID IS THE KEY OF
122+
KEY-VALUE"); the compiled ClassView lays them out from keys alone, and the
123+
heavier value-SoA is only built when actually needed, then cached.
124+
125+
### Why this is the power (and where SurrealQL sits)
126+
127+
- **Compiled beats parsed.** The business logic is a `ClassView` compiled into
128+
the consumer's binary — branch-predictable, inlinable, zero-parse. A
129+
SurrealQL DDL round-trip (`ogar-adapter-surrealql`) is a *storage-membrane*
130+
adapter for the SurrealDB boundary; **even a JIT over SurrealQL loses to
131+
compiled code**, so it is never on the hot path.
132+
- **Consequence for this repo's roadmap:** the SurrealQL emit/parse work
133+
(#136 Stage A, and the od-ontology Stage B/C fork-deletion) is *membrane*
134+
work — correct for the storage boundary, but **not the spine**. The spine
135+
investment is the compiled, nested, lazy `ClassView` over the GUID SoA. When
136+
the two compete for attention, the compiled ClassView wins.
137+
138+
> **Status:** the recombination *principle* + the nested-constructor + lazy-SoA
139+
> architecture are operator-specified here as the durable design. The exact
140+
> tier-byte arithmetic of each carving (`6×(1:2)` / `4×(1:2:3)` / `3×(1:2:3:4)`
141+
> over the facet's 12 tier-bytes) is the implementation detail to pin against
142+
> `lance_graph_contract::facet::FacetCascade` before coding — not guessed.
70143
71144
---
72145

@@ -237,16 +310,29 @@ correct because of the `relation_kind` predicate (ruff#35): `target` +
237310
`account.move → struct AccountMove { name: OgScalar, partner_id:
238311
ToOne<ResPartner>, line_ids: ToMany<AccountMoveLine> }`.
239312

240-
**Next (the transpiler direction):**
241-
1. **Pull-back emit, breadth + depth**`emit_csharp` / `emit_python`
242-
targets on the same `&CompiledClass -> String` seam; refine `OgScalar`
243-
to mapped concrete types once the `field_type` capture lands (ruff
244-
follow-up); extract the family into dedicated `ogar-emit-<lang>` crates
245-
mirroring `ogar-adapter-surrealql`. The runtime wrapper-contract mode
246-
(lance-graph-contract for Rust) is the C#/Python sibling.
247-
2. **Thin the consumer**`odoo-rs` collapses to a `compile_graph::<OdooPort>`
248-
caller + the `od-posting` GoBD adapter (the 15%).
249-
3. **Scale** — run the `odoo_blueprint` 404 entities through `compile_graph`;
313+
- **`ogar-adapter-surrealql` `array<record>`** — to-many associations
314+
(`HasMany`/`HasAndBelongsToMany`) emit as `array<record<comodel>>` (OGAR #136,
315+
#2 Stage A). **Membrane work** (the SurrealDB storage boundary) — *not* the
316+
spine (§1.5).
317+
318+
**Next (priority order — spine first, per §1.5):**
319+
1. **The compiled `ClassView` spine (THE priority)** — the flexible,
320+
*nested*, lazy reader: facet-layout recombination (`6×(1:2)` / `4×(1:2:3)` /
321+
`3×(1:2:3:4)`), sub-range hierarchy mapping, nested ClassViews stacked into
322+
compiled constructors, and lazy + lazy-lock-reused materialization of the
323+
`32×GUID` SoA. Pin the per-carving tier-byte arithmetic against
324+
`FacetCascade` first (don't guess). This subsumes hardcoded facet
325+
"versions". The `emit_rust` codegen leg is the start; this is the depth.
326+
2. **Pull-back breadth**`emit_csharp` / `emit_python` on the same
327+
`&CompiledClass -> String` seam; refine `OgScalar` once the `field_type`
328+
capture lands (ruff follow-up). Runtime wrapper-contract is the C#/Python
329+
sibling of `lance-graph-contract`.
330+
3. **Thin the consumer (membrane)**`odoo-rs``compile_graph::<OdooPort>`
331+
caller + `od-posting` GoBD adapter; delete the native SurrealQL emit fork
332+
(W3.3, **CI-gated** — od-ontology pulls surrealdb). Recommended path: keep
333+
the corpus input, delete only the native emit, route emit through the shared
334+
`ogar-adapter-surrealql`. This is *membrane* — secondary to (1).
335+
4. **Scale**`odoo_blueprint`'s 404 entities through `compile_graph`;
250336
over-cap god-models (`≥ 256` members) branch via the SoC lint
251337
(`ruff_spo_address::soc`), never widen.
252338

0 commit comments

Comments
 (0)