Section 13: Shared Representation Evidence and Backend Layout Plans

Intelligence Reconnaissance

Queries run 2026-07-14:

• scripts/intel-query.sh plan-status repr-opt --human — 13 sections, 7 open; graph-local plan state is available.
• scripts/intel-query.sh symbols EnumLayoutInfo --repo ori --human — found the live type in ori_repr.
• scripts/intel-query.sh symbols ExecutableProgram --repo ori --human — returned no symbol, confirming graph lag for the newer artifact.
• scripts/intel-query.sh symbol-plans CompiledLayoutPlan --repo ori --human — found references across VM, enum, backend-boundary, native-backend, and repr work.

Results summary (≤500 chars) [ori]: The graph confirms live EnumLayoutInfo and cross-plan demand for CompiledLayoutPlan, but misses the newer ExecutableProgram; verify every owner in live source before migration [ori:compiler/ori_repr/src/layout/enum_layout_info.rs].

Purpose

The implemented Sections 01-07 proved that Ori can centralize representation decisions, but the current artifact mixes two different kinds of knowledge:

• backend-neutral evidence: triviality, ranges, exact-width proofs, field identity, public/FFI constraints, niche eligibility, and audit provenance;
• native physical decisions: byte size/alignment, field byte offsets, fat-pointer shape, native RC header policy, and LLVM-facing ABI behavior.

That mixture worked while LLVM was the only executable backend. It is neither a clean contract for the VM nor a safe basis for adding ori_backend: letting LLVM and ori_backend independently classify the same compiled layout and ABI would create a silent-miscompilation seam.

This section performs a behavior-preserving split, then uses the shared evidence to test VM-native layouts against real Ori programs while extracting one backend-neutral compiled target plan for both compiled backends. The evaluator remains an independent canonical-IR executor and joins the other paths at ExecutionOutcome; it does not consume a physical plan.

WASM is direct compiled output from ori_backend, not a VM host.

plans/enum-layout-ssot is the concrete enum migration under this section. The live baseline already stores native-shaped EnumLayoutInfo in ReprPlan; its GEP-oriented indices, ABI size, i64-slot packing, representative-variant offsets, and runtime-ABI boolean are migration inputs, not the final shared contract.

Architectural Contract

The production shape is immutable evidence plus two deliberate physical branches:

ExecutableProgram
  ReprPlan proof/eligibility + typed AIMS carriers
        |
        +--> VmLayoutPlan (ori_vm, explicit VM encoding options)
        |
        +--> TargetSpec (ori_target, backend-neutral target/ABI identity)
                 |
                 v
            CompiledLayoutPlan (ori_repr)
              /                 \
             v                   v
       ori_llvm adapter      ori_backend BIR/MIR
       LLVM IR/object/AOT    x86-64/aarch64/riscv64/s390x/WASM

Names are illustrative until the types land. The ownership constraints are normative.

ReprPlan: shared evidence

It may contain:

• canonical type and stable storage-site identities;
• semantic field index/name and #repr/visibility/FFI constraints;
• transitive triviality plus stable references to AIMS-owned ValueSemanticsId/ExecutableDropPlanId facts; the representation artifact does not own or reconstruct logical drop obligations;
• signed integer range and smallest proved-safe storage width;
• exact-f32 eligibility while preserving semantic f64 arithmetic;
• enum tag cardinality, invalid-bit/niche candidates, and proof provenance;
• per-construction/per-mutation-site collection element ranges and completeness state;
• audit trail explaining why a candidate is allowed or forced canonical.

It may not contain:

• LLVM types, contexts, calling conventions, attributes, sret, native target triples, or target DataLayout results;
• native byte offsets/alignment/header offsets unless represented as a target-independent constraint rather than a chosen layout;
• VM opcodes, packed register indices, frame offsets, heap handles, or interpreter dispatch choices;
• a parallel escape/locality/thread/sharing analysis owned by AIMS;
• callbacks into a backend or mutable process/session state.

AIMS carriers: shared memory facts

AIMS remains the sole owner of Locality, Uniqueness, access/consumption/cardinality, sharing provenance, and thread-escape decisions. It freezes every downstream-required result into typed post-AIMS instructions or an immutable site-keyed table in ExecutableProgram.

ori_repr, ori_vm, and compiled backends may project those facts; they may not recompute them.

Physical plans: interpreter-private versus shared compiled

ori_target::TargetSpec owns canonical target identity, data model, endianness, pointer width, calling-convention rules, and WASM ABI identity without importing LLVM or ori_backend. ori_repr::CompiledLayoutPlan owns target byte layout, field offsets, enum encoding, compiled calling-ABI classification, native/runtime header shapes, and backend-neutral runtime declaration classifications.

LLVM and ori_backend map that same plan to their own IR and emission details; they do not recompute it. VmLayoutPlan separately owns register representation, frame-local storage, safe heap-object schemas, collection backing stores, and opcode specialization.

Both physical branches fail closed on a missing fact and provide an explicit canonical layout entry when an optimization is declined.

An optimization proof does not mandate one physical choice. For example, a proof that a value fits in i8 permits the VM to store it in one byte while still doing arithmetic in an i64 word; LLVM may use i8 storage plus extensions; a measured backend may decline the narrow form.

The proof and the cost decision are different data.

13.1 Fact and Consumer Census

• Query the intelligence graph first, then verify live source for every ReprPlan, MachineRepr, StructRepr, EnumRepr, RcStrategy, TypeInfoStore, ExecutableProgram, and VM register/heap consumer.
• Use plans/enum-layout-ssot as the enum census: account for the existing EnumLayoutInfo, every LLVM hardcoded enum access, every VM enum operation, and every future ori_backend consumer before changing the owner.
• Classify every field/query as one of: semantic constraint, soundness proof, AIMS-owned fact, target-independent layout kernel input/output, native-only physical layout, VM-only physical layout, audit/debug data.
• Record every fallback or on-the-fly recomputation. Production migration must replace each with either an explicit canonical plan entry or a typed failure; no backend-local proof fallback remains.
• Verify the artifact construction order. Range analysis may inspect pre-AIMS functions, but logical lifetime, OwnerBound, OwnershipObservationFacts, and cleanup facts are frozen only after AIMS. VM/compiled storage and ownership mechanisms are selected only after composing those facts with neutral representation evidence; stale pre-AIMS or pre-plan data cannot be presented as final truth.
• Pin the evaluator branch and normalized ExecutionOutcome join in an architecture test so repr refactoring cannot turn eval into a dead-end or force it through backend layouts.

13.2 Backend-Neutral ReprPlan

• Introduce stable type, value, field, allocation, and collection-storage-site keys. A type-only key is permitted only for a fact that is sound for every instance and storage site of that type.
• Split the current MachineRepr data into proof/eligibility records and physical layout records. Preserve existing public query behavior through a short migration adapter; delete the adapter after all native consumers move.
• Split current enum data into EnumReprEvidence, VmEnumLayout, and CompiledEnumLayout. Replace representative-variant offsets with total stable (variant, semantic_field) mappings, typed runtime/FFI constraints, and checked arithmetic.
• Move byte size, alignment, optimized memory order, byte offset, native fat-pointer layout, and native RC-header decisions out of shared evidence.
• Retain semantic field identity and an optional backend-neutral ordering constraint. A shared pure compiled-layout kernel is allowed only when both compiled backends use the identical algorithm over explicit policy data; the VM consumes the proof surface through its own physical layout policy.
• Replace the EscapeInfo placeholder, escapes() fallback, and MachineRepr::StackPromoted authority with typed AIMS carriers. Do not add a repr -> arc feedback edge.
• Make ExecutableProgram::validate verify completeness, key stability, canonical fallbacks, and agreement between post-AIMS instructions and referenced AIMS facts.
• Add deterministic equality/hash/fingerprint coverage before any persistent bytecode/JIT cache treats representation evidence as a cache key.

13.3 Shared Compiled Layout and Backend Adapters

• Extract canonical target identity and pure data-model/ABI descriptors from the current LLVM-owned target surface into ori_target; keep target-machine handles, object writers, linkers, and sysroot discovery out of the shared crate.
• Build CompiledLayoutPlan in ori_repr from &ExecutableProgram plus explicit TargetSpec. Include stable per-type/per-site layouts and one compiled FunctionAbi/runtime-call classification with no LLVM values or BIR/MIR nodes.
• Make CompiledEnumLayout the only selected compiled enum encoding and field map. LLVM TagAccess and the ori_backend adapter translate semantic enum operations through it; neither adapter matches encodings to reconstruct layout.
• Migrate every LLVM consumer of sizes, alignments, offsets, enum encoding, ABI, RC header strategy, and collection layout to a thin adapter over CompiledLayoutPlan.
• Amend plans/native-backend architecture, BIR translation, runtime ABI, and fast-isel contracts so ori_backend consumes the identical TargetSpec and CompiledLayoutPlan; duplicate field layout or ABI classification is a blocking seam defect.
• Treat wasm32 as a normal compiled TargetSpec: ori_backend emits a complete WebAssembly module and WASM ABI/glue from the compiled plan. No VmLayoutPlan, bytecode, or evaluator mode participates in WASM code generation.
• Preserve the exact shipped LLVM IR and runtime ABI before enabling any new representation. Compare pre-split versus post-split debug and release IR structurally and execute both AOT paths.
• Keep #repr("c"), FFI canonical widths, public/cross-module surfaces, and target-specific ABI decisions in the shared compiled plan and fail closed; concrete backends may only map those decisions to their own IR/emission forms.
• Delete TypeInfoStore or ReprPlan fallback computations once all consumers use the plan; a compatibility fallback cannot survive section close.
• Add a non-host target FileCheck matrix plus cross-backend layout/ABI equality fixtures for x86-64, aarch64, riscv64, s390x, and WASM.

13.4 VM Layout Prototypes

Prototype against the real ori_vm and broad benchmark/parity corpus. Every experiment reports wall time, executed steps, bytecode bytes, frame/register bytes, heap live/peak/allocated bytes, allocation count, final live bytes, and whole-process RSS.

Results with fallback or parity mismatch are invalid.

Live VM baseline — 2026-07-14

• The generation-safe value arena has already removed the old per-register aggregate and iterator arrays. A frame now owns tagged registers plus simultaneous-move scratch; aggregate and iterator identities live in one traced/reclaimed session arena. Preserve this completed baseline and its escape, stale-handle, nested-call, unwind, and final-zero pins.
• The remaining frame cost is one 16-byte tagged VmValue for every logical register plus whole-register-file fill/reset. Typed integer and boolean operations still extract and check the tag at execution. The current physical-plan scaffold retains one lane per logical register and does not execute.
• Arena entries remain general-purpose: aggregate entries reserve four tagged fields and a general variant even for narrow shapes, while lists/builders use Vec<VmValue>. Retain/release still discovers child shape through runtime value-kind dispatch.
• ExecutableProgram carries ReprPlan, but VM lowering currently derives only coarse Int / Bool / String / Other classes from type tags. No VM layout experiment may claim shared-representation evidence until it consumes a validated backend-neutral proof carrier rather than recreating facts from the type pool.

Candidate A: verified untagged word slots

• Store statically typed registers as safe u64 words; opcodes and verified register metadata define interpretation. Use from_bits/checked handle decoding, never transmute or raw aliasing.
• Specialize RC/drop/call operations during bytecode compilation so generic execution does not need a runtime value tag to rediscover a register’s type.
• Preserve the completed arena centralization, then replace general arena payload padding with verified schema-packed aggregate/iterator entries; do not recreate per-register side arrays.
• Prove malformed bytecode cannot reinterpret a word under the wrong class, access an absent side slot, or forge an unchecked heap handle.

Candidate B: typed register banks

• Prototype separate integer, float, reference/handle, and compact-boolean banks with bytecode operands already rewritten to bank-local indices.
• Measure the extra mapping/dispatch cost against cache density and zeroed-frame cost. Do not retain a logical-register lookup in the hot loop unless profiling shows it is competitive.
• Test mixed calls, parallel moves, branches, recursion, aggregates, collections, panics, and unwind cleanup; microbench-only results do not qualify.

Shared heap and collection experiments

• Define VM object schemas from ReprPlan plus AIMS facts: safe compact aggregates, site-complete typed list stores, packed booleans, inline short strings/lists where measured, and canonical fallback stores.
• Compare schema-packed aggregate entries with the live fixed four-field arena representation. Report arena entry bytes, internal payload waste, tracing work, allocation/reclamation slope, and whole-process RSS on heterogeneous variants, nesting, calls, recursion, panic, and unwind.
• Define VmEnumLayout from enum evidence plus explicit VM policy. Verify tags, variant-specific payload classes, heap handles, trace/drop schemas, and malformed-bytecode rejection without importing compiled offsets or LLVM aggregate indices.
• Keep semantic f64/i64 operations canonical even when object/collection storage narrows; widen on load and range-check/guard every store whose proof is not closed-world complete.
• Reject global per-type collection narrowing. A computed collect, mutation, imported producer, closure result, or unknown call widens the affected site unless its contribution is proven.
• Implement recursive/iterative retain and release of child handles before memory readings count as valid. Copy-on-write clones must fund every child reference; final live objects and bytes must be zero on success, panic, limit failure, and verifier rejection.
• Compare at least the frozen micro, medium, allocation-heavy, string, collection, graph, nested-control, combined-application, failure/unwind, and existing admitted Ori test corpus at multiple input scales.

13.5 Selection and Production Hardening

• Select a VM layout only from the corpus-wide speed/memory Pareto frontier. A speed win with a memory regression, or vice versa, needs an explicit rejected/retained rationale and cannot silently replace the baseline.
• Require the selected layout to preserve the bytecode VM floor: geometric-mean runtime at least 2× faster than pinned Python on admitted programs, no qualifying program below the declared floor without disposition, workload-attributable peak memory at most 0.5× Python, and unadjusted RSS no worse than Python.
• Keep pinned LuaJIT -joff time and memory as the strict-interpreter north star. Record gaps by workload family; do not optimize only the easiest comparator.
• Prove evaluator/VM/LLVM debug/release/AOT and admitted ori_backend target observable parity on optimized and canonical layouts, including stdout/effect order, panics, source attribution, RC/drop traces, and final memory state.
• Freeze the VM/JIT handoff: the future JIT tier is implemented by ori_backend and consumes the same ExecutableProgram, TargetSpec, and CompiledLayoutPlan as AOT. It does not compile from VM-private heap schemas, invent a second native layout, or rerun representation analysis. OSR/deoptimization state maps remain an explicit later design between VM state and compiled values.
• Remove experiment flags, duplicate layout definitions, fallback counters, and disposable harness code before promotion. Retained code must live in its final crate, pass implementation-hygiene review, and carry exhaustive negative pins.
• Update missions.md, repr.md, compiler.md, canon.md, and crate docs through the sanctioned sync/proposal path once the split is proven. The approved representation proposal already permits target/backend variation; documentation must stop describing ori_repr as LLVM-only.

Layer Coverage

Exit Criteria

The section closes only when the current LLVM-shaped MachineRepr is no longer the cross-executor contract; VmLayoutPlan and CompiledLayoutPlan consume one immutable proof surface; LLVM and ori_backend consume one compiled target layout and ABI classification; WASM is proven as direct compiled output; eval remains a live normalized-outcome executor; the production CLI corpus is parity- and leak-clean; and the chosen VM representation clears the speed and memory floors on representative combined applications, not merely isolated microbenchmarks.