Reconcile canonical_node.rs node layout with OGAR canon (key16+value496; EdgeBlock superseded) — F-5 operator/panel decision

[claude]

Tracking the F-5 canon-vs-code divergence flagged in
OGAR/docs/NODEGUID-CANON-AUDIT.md (§F-5), surfaced again while landing the
facet RFCs (ruff #32, OGAR #130) and the facet_schema PR (#619).

Divergence

• lance-graph code (crates/lance-graph-contract/src/canonical_node.rs):
  NodeRow = key(16) | edges(16: 12+4 EdgeBlock) | value(480).
• OGAR canon (OGAR/CLAUDE.md:51-52): a node is key(16) + value(496) —
  no separate EdgeBlock.
• NODEGUID-CANON-AUDIT.md F-5 records the 12+4 EdgeBlock as
  superseded (operator, 2026-06-23: "don't use 12-4, that's the old
  taxonomy before family nodes" — relations ARE the addressing: shared family
  prefix = local edge, GUID reference = cross edge), and states explicitly:
  "a genuine canon-vs-operator divergence to resolve at the lance-graph level…
  not something to change unilaterally."

Why an issue, not a PR

Per F-5 this is operator/panel-gated. The facet_schema work (#619)
deliberately touched only the 16-byte key and left the node layout alone.
This issue is the decision record so the next lance-graph session reconciles
canonical_node.rs against the family-node supersession rather than anyone
doing it unilaterally.

Decision needed

1. Drop the separate EdgeBlock, move to key(16) | value(496); OR keep
   16+16+480 and update the OGAR canon instead.
2. If dropping: re-home the 12 in-family + 4 out-of-family adjacency as
   family-prefix addressing + GUID-reference tenants (per F-5), and update the
   const _ size asserts + downstream consumers (MailboxSoA, SymbiontBoard).

cc the §6 soa-value-tenant-migration panel — this intersects the value-slab
work. Tracked downstream as medcare-rs board TD-MEDCARE-25.

---

Generated by Claude Code

[claude]

Resolution (operator, 2026-06-28) — the first GUID already does both

Correcting the earlier "block 0 = location, block 1 = relationships" split:
the first 16-byte GUID already encodes location AND relationships. The
facet_classid(4) | 6×(part_of:is_a) cascade is the relationship structure
(part_of = containment/mereology, is_a = taxonomy) and is simultaneously
prefix-routable for location (a containment / type query is a longest-common-
prefix on the chains). One GUID is a content-addressed key that is both
positional and relational.

The belief that you "need a second block for relationships" underestimates the
first GUID. The second 16-byte block is not the relationship home — it is
optional capacity that just adds more (a second relational plane / extra
edges / deeper cascade), selected per classid schema:

• OGAR 16+496 (no second block) is already fully relational — the one GUID
  carries the relationships.
• canonical_node 16+16+480 simply adds more with block 1; it does not
  "enable" relationships that 16+496 lacks.

So there is no divergence to resolve: the EdgeBlock is additive headroom,
not a required slot, and 16+496 is not relationship-deficient. Suggest closing
as design-ratified.

---

Generated by Claude Code