@@ -29,6 +29,39 @@ failure were caught and fixed without compounding drift.
 
 **Closes:** the 11-class cross-axis gap. **Next:** odoo-rs alignment_pin
 tighten + pin bump to OGAR main (5089c1e8 → 597ecb12 family).
+## 2026-06-24 — E-HOMOGENEOUS-FACET-IS-CLASSVIEW-NOT-VARIANT — the §8 homogeneous facet is a `classid → ClassView` reading, NEVER a new `ValueSchema` enum variant
+
+**Status:** FINDING (caught by Codex P2 on PR #610, verified against canon).
+
+The thesis §8.1 + the SoA value-tenant migration plan v1 originally framed the
+homogeneous-facet value as a *new additive* `ValueSchema::Homogeneous` variant
+"alongside" the existing tenants, sold as layout-preserving + no-version-bump.
+**That contradicts a locked guardrail.** Adding a `ValueSchema` enum case is a
+*contract-surface* addition even when the byte layout is untouched, and the
+canon forbids a plan/thesis from minting one:
+
+- `core-first-transcode-doctrine.md:72` — "`classid → ClassView` … **No new
+  layer, no new `ValueSchema` variant.**"
+- `genetic-research-substrate-integration-v1.md:14-16` — the #496 §0
+  anti-invention guardrail + the **#500 no-new-variant contract test**:
+  rows ride `Full` / `Compressed`; specialisation is via `classid → ClassView`
+  mint, not a variant.
+- `ocr-canonical-soa-integration-v1.md:93-102` — "do **NOT** add a 5th
+  `ValueSchema::Ocr` … the rule that holds is **no new enum variant from a
+  plan**."
+
+**Corrected framing (both docs fixed in the same PR):** the homogeneous facet is
+a **ClassView reading that interprets the value bytes of an existing preset** —
+the `ValueSchema` enum AND the 16/16/480 layout both stay untouched, no
+`ENVELOPE_LAYOUT_VERSION` bump, no #500 violation. IF a dedicated preset is ever
+judged necessary, that is an **operator decision lifting #496/#500** with the
+contract test updated in the same change — never a free additive a thesis
+assumes. **Lesson:** "layout-preserving" ≠ "contract-surface-preserving"; an
+enum-variant add is the latter even when the bytes don't move. The default for
+any new value shape is a ClassView reading over `Full`/`Compressed`, not a new
+`ValueSchema` case. (Same PR also softened the §8.3 "no adapter" claim — the
+per-port codebook lookup still mediates; only the bespoke A→B *translation*
+boundary disappears — and tagged a bare markdown fence per CodeRabbit.)
 
 ## 2026-06-23 — E-OGAR-API-EDIT-PULL-FIRST — API-based file edits MUST pull-then-splice; uploading pre-edited local files regresses upstream main
 
 
@@ -191,23 +191,34 @@ it is graded `[H]` where it reuses shipped structure and `[S]` where it bets on
 unbuilt tooling. **Nothing here is canon yet** — it is the north-star's far end,
 written down so the rungs point somewhere.
 
-### 8.1 The homogeneous facet `[H]` — layout-preserving, not layout-breaking
+### 8.1 The homogeneous facet `[H]` — a ClassView reading, NOT a new contract variant
 
 Carve the 480-byte value as **N × 16-byte facets**, each facet itself a
 `(part_of:is_a)` cascade in the §2-Structure algebra:
 
-```
+```text
 facet (16 B) = facet_classid(4) | 6 × (8:8 part_of:is_a tile, 2 B each = 12)
-value (480 B) = up to 30 homogeneous facets        ← ValueSchema::Homogeneous
+value (480 B) = up to 30 homogeneous facets    ← read by classid → ClassView
 ```
 
-The key insight is **compatibility, not replacement**: this is a new
-`ValueSchema::Homogeneous` variant *alongside* the existing `ValueTenant` SoA
-columns — the 16/16/480 split (`canonical_node.rs`) is **untouched**, so it is
-layout-preserving and needs no `ENVELOPE_LAYOUT_VERSION` bump (contrast a *key*
-re-carve, which is canon-level and separate). The value's facets are read by
-the *same* prefix-and-table arithmetic as the path tiers (§2), so "read the
-value" becomes the same operation as "route the key."
+**Guardrail (do not misread this as a free additive).** The canon forbids a
+plan or thesis from minting a `ValueSchema` enum variant: the #496 §0
+anti-invention guardrail + the **#500 no-new-variant contract test**, and
+`core-first-transcode-doctrine.md` ("`classid → ClassView` … **no new layer,
+no new `ValueSchema` variant**"). The genetics and OCR plans both ride the
+existing `Full` / `Compressed` presets and specialise via `classid → ClassView`
+mint — *not* a new variant. So the homogeneous facet is **a ClassView reading
+that interprets the value bytes of an existing preset**, never a
+`ValueSchema::Homogeneous` enum case. Both the 16/16/480 layout
+(`canonical_node.rs`) **and** the `ValueSchema` enum stay untouched; no
+`ENVELOPE_LAYOUT_VERSION` bump, no contract-surface addition. The value's
+facets are read by the *same* prefix-and-table arithmetic as the path tiers
+(§2), so "read the value" becomes the same operation as "route the key."
+
+**If** a dedicated variant is ever judged necessary (a leaner homogeneous
+preset the existing ones can't express), that is an explicit **operator
+decision lifting the #496/#500 guardrail** — with the contract test updated in
+the same change — never an additive a thesis assumes for free.
 
 **The conflation trap, named up front (`[H]` gate):** not every facet is a
 `part_of:is_a` mereology/taxonomy pair. Scalars (a susceptance, a price, a
@@ -246,10 +257,11 @@ GATED` in spirit: same prefix, two semantics, must never silently diverge).
 ### 8.3 LEGO across domains `[S]` — EdgeBlock click via shared codebook
 
 If two programs (an ERP, a OCR pipeline) mint nodes against the *same* OGAR
-concept codebook, their `EdgeBlock` slots are **directly clickable**: an
-out-of-family edge from domain A's node resolves, by `canonical_concept_id`,
-into domain B's node — no adapter, no serialization, because both speak the one
-codebook. "Compile on OGAR classes and do LEGO with class shapes" becomes:
+concept codebook, their `EdgeBlock` slots are **conceptually clickable through
+the shared codebook**: an out-of-family edge from domain A's node resolves, by
+`canonical_concept_id`, into domain B's node — the per-port codebook lookup
+still mediates, but the extra *translation* boundary (a bespoke A→B adapter, a
+serialization hop) disappears, because both already speak the one codebook. "Compile on OGAR classes and do LEGO with class shapes" becomes:
 **compile = SPO manifest → ClassView**; **run = SoA under `UnifiedStep` /
 semiring** (§2-Composition). `[S]` — this is the OGAR core-first doctrine's
 end state, explicitly CONJECTURE until `PROBE-OGAR-ADAPTER-UNICHARSET` is green.
 
@@ -43,11 +43,14 @@ The canonical node is `key(16) | edges(16) | value(480)` = 512 B
 (`canonical_node.rs`, operator-LOCKED, RESERVE-DON'T-RECLAIM). A **value
 tenant** is a typed claim on some of those 480 value bytes — the `ValueSchema`
 says how the slab is carved, a `ValueTenant` is one carve. The §8 strong form
-(`substrate-unification-thesis.md`) proposes an *additive* `ValueSchema::
-Homogeneous` (N × 16-byte `(part_of:is_a)` facets) **alongside** the existing
-tenants. The migration question for each existing tenant is therefore:
-**KEEP as-is / homogenize to a facet / PQ-code it / deprecate** — and whether
-that move is layout-preserving.
+(`substrate-unification-thesis.md`) reads the homogeneous facet as a
+`classid → ClassView` *interpretation over an existing preset* (`Full` /
+`Compressed`) — **not** a new `ValueSchema` enum variant (the #496 §0
+anti-invention guardrail + the #500 no-new-variant contract test forbid a plan
+from minting one; see §3). The migration question for each existing tenant is
+therefore: **KEEP as-is / homogenize via a ClassView facet reading / PQ-code it
+/ deprecate** — and whether that move stays within the existing presets or
+requires an operator-lifted guardrail.
 
 ---
 
@@ -106,12 +109,21 @@ The harvest must Read, fully, in this order:
 For each tenant the harvest touches, hold these in mind — they are the
 acceptance criteria the §6 panels will check:
 
-- **Layout class.** Is the proposed move *layout-preserving* (a new
-  `ValueSchema` variant alongside; offsets unchanged) or *layout-breaking* (the
-  480 bytes re-carved)? Breaking ⇒ canon-level ⇒ needs `ENVELOPE_LAYOUT_VERSION`
-  bump **and** the operator's nod. The 16/16/480 split and the `const _` asserts
-  do not move without that. (RESERVE-DON'T-RECLAIM: a zeroed/unused region is
-  *not consulted*, never *compacted away*.)
+- **Contract-surface class (the #500 guardrail).** A plan may **NOT** mint a
+  `ValueSchema` enum variant — that is a contract-surface addition against the
+  #496 §0 anti-invention guardrail, enforced by the **#500 no-new-variant
+  contract test** (`core-first-transcode-doctrine.md`: "`classid → ClassView`
+  … no new `ValueSchema` variant"; the genetics + OCR plans both ride `Full` /
+  `Compressed` and specialise via `classid → ClassView` mint). So the default
+  move is a **ClassView reading over an existing preset**, offsets and enum both
+  unchanged. A genuinely new preset is an **operator decision lifting #496/#500**
+  (with the contract test updated in the same change), never a plan default.
+- **Layout class.** Even within the existing enum, is the byte carve
+  *preserving* (offsets unchanged) or *breaking* (the 480 bytes re-carved)?
+  Breaking ⇒ canon-level ⇒ needs `ENVELOPE_LAYOUT_VERSION` bump **and** the
+  operator's nod. The 16/16/480 split and the `const _` asserts do not move
+  without that. (RESERVE-DON'T-RECLAIM: a zeroed/unused region is *not
+  consulted*, never *compacted away*.)
 - **`I-LEGACY-API-FEATURE-GATED`.** The same accessor name must never mean two
   things under two feature flags. Any v1 accessor over bytes a v2 layout
   reclaims ⇒ route through the canonical mapping OR feature-gate to a documented
@@ -168,10 +180,14 @@ hidden. Silent truncation reads as "covered everything" when it didn't.
 
 Direction, fixed; specifics, deferred to the filled inventory:
 
-1. **Additive contract first.** Land `ValueSchema::Homogeneous` + a
-   `FacetCascade` type (`facet_classid(4) | 6×(8:8)=12` = 16 B) as a *new
-   variant alongside* `ValueTenant` — layout-preserving, no version bump. Behind
-   a feature flag. Field-isolation matrix tests from day one.
+1. **ClassView reading first (no new contract variant).** Land the
+   `FacetCascade` *reading* (`facet_classid(4) | 6×(8:8)=12` = 16 B) as a
+   `classid → ClassView` interpretation over an existing preset (`Full` /
+   `Compressed`) — the `ValueSchema` enum and the 16/16/480 layout both
+   untouched, no version bump, no #500 violation. Behind a feature flag.
+   Field-isolation matrix tests from day one. (A dedicated `ValueSchema` preset
+   is out of scope for this plan — it is an operator-lifted #496/#500 decision,
+   filed separately if the existing presets prove insufficient.)
 2. **Per-tenant, in migration_class order:**
    - `homogenize-to-facet` tenants (those that already ARE `part_of:is_a`) move
      first — lowest risk, prototype is `cascade_key` V3.