Skip to content

CausalEdge64: LE-contract byte-straddle (inference mantissa) + the witness/edge u64 name-collision zoo #609

Description

@AdaWorldAPI

Summary

Two related problems around CausalEdge64 and the family of 64-bit "witness/edge" words. (A) is a concrete LE-layout mismatch fixed now; (B) is the consolidation that this issue tracks for later (clean route — not done in the same change).

(A) — IMMEDIATE: the SPO CausalEdge64 inference/mantissa field straddles a byte boundary (breaks the LE byte-sliceable contract)

causal-edge/src/layout.rs (v2) and causal-edge/src/edge.rs (v1 consts) both place the inference field starting at bit 46:

  • v1 (feature off): inference = 3-bit unsigned, bits 46-48
  • v2 (causal-edge-v2-layout): inference_mantissa = 4-bit signed i4, bits 46-49

Byte 6 of the LE u64 begins at bit 48, so in both versions the field crosses the byte-5/6 boundary (v1: 46,47 | 48 — v2: 46,47 | 48,49). Every other group in the canonical stack (the NodeGuid groups, the SoaEnvelope ColumnDescriptor byte-ranges, S/P/O/freq/conf = whole bytes) is byte-aligned and byte-sliceable; a straddling field can't be read by a clean LE byte access, so to_le_bytes does not keep the field's bits together the way the SoA columnar contract assumes. W (bits 53-58) straddles byte 6/7 the same way.

Fix being applied now (separate change): reorganize the high 24 bits of the v2 layout so every field is byte-aligned — target byte5: CAUSAL·DIR·TRUTH, byte6: INFER(mantissa)·PLAST, byte7: W — with the mandatory I-LEGACY-API-FEATURE-GATED field-isolation matrix test and a layout-version bump. (CI must validate; can't compile in the authoring sandbox.)

(B) — TRACK: "witness/edge u64" name-collision zoo (consolidation, do NOT rush)

Grounded inventory (extends docs/TYPE_DUPLICATION_MAP.md §13):

u64 type location layout byte-clean?
CausalEdge64 (SPO) causal-edge/src/edge.rs S8·P8·O8 · NARS freq/conf · Pearl-2³ · inference mantissa · plast · W/truth/spare no (mantissa + W straddle)
CausalEdge64 (8-channel) thinking-engine/src/layered.rs 8 × i8 channels (BECOMES/CAUSES/…/CONTRADICTS) yes
EpisodicEdges64 lance-graph-contract/src/episodic_edges.rs (exported) 4 × u16 [family nibble : local] — explicitly "NOT a lens over one CausalEdge64" yes
EpisodicWitness64 lance-graph-contract/src/soa_view.rs NOT a code symbol — queued design ("AriGraph living in the mailbox SoA view") n/a
ReasoningWitness64 lance-graph-contract/src/splat.rs u64 identity fingerprint (splat/EWA domain) n/a
WitnessTable<64> lance-graph-contract/src/witness_table.rs 64-entry table, resolves CausalEdge64 W-slot n/a
ndarray hpc::causal_diff::CausalEdge64 twin + InferenceRow mirror ndarray bit-compat producer mirrors

Why it's dangerous: same/adjacent names, different semantics, all flowing through thinking-engine → p64 → Bus/Resonance/StreamDto → cognitive-shader-driver and the planner styles. Conflations leak into new prose/code (e.g. reaching for the non-symbol EpisodicWitness64 and blurring it into CausalEdge64). Guards already exist (episodic_edges.rs header; TYPE_DUPLICATION_MAP §13) but aren't enforced everywhere.

Drift origin (documented): lance-graph-planner/src/cache/convergence.rs:18-22 started the unification (#[allow(unused_imports)], "intended for hot-path convergence wiring") and never finished; the 8-channel variant was reinvented locally in thinking-engine instead of imported from causal-edge.

Proposed consolidation (later, gated)

  1. Qualify/rename the thinking-engine 8-channel variant (e.g. CascadeEdge64) so CausalEdge64 means exactly the SPO word.
  2. Finish or delete the dead convergence.rs wiring.
  3. Either promote EpisodicWitness64 to a real symbol composed of CausalEdge64 W-slot + WitnessTable + EpisodicEdges64, or retire the name.
  4. Extend TYPE_DUPLICATION_MAP §13 into the full table above.

Refs: docs/TYPE_DUPLICATION_MAP.md §13, I-LEGACY-API-FEATURE-GATED (CLAUDE.md), Sprint-10 causaledge64-mailbox-rename-soa-v1.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions