Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.

Material metadata in the main executable image

The BW original-game trace identifies a 168-byte texture wrapper at 0x01463200 and a 60-byte material pass at 0x0145DC74 that the allocation-only material copier refuses. These are image-resident metadata, not observed heap allocations. BW still fails the complete material-batch gate; all 99 baseline files restore and custody releases at 2026-11-08 18:25:20 UTC. Its complete 4,913-file archive, metadata and rollback members verify and fullfsync externally.

source_memory::ImageMetadata now represents independently qualified physical storage in the process-lifetime main executable image. The private adapter requires the actual x86 main module, valid PE image bounds, committed MEM_IMAGE pages with the matching allocation base and readable, non-executable page protection. It excludes the known allocator pool before registration as well as all registered pools and observed heap roots. An allocation coverage refusal cannot fall through to image storage. The default registry remains heap-only.

Image metadata tokens do not replace the separate exact 48-byte ImageSource constructor binding. A wrapper and its embedded source header can share physical image storage, while source incarnation, creation and physical ownership remain independent requirements. Metadata tokens cannot be used as source-constructor tickets or allocator backing regions. No public API or native ABI changes.

Material passes, stream data, cache masks, shader reference indirections, texture wrappers and descriptor flags carry their original typed storage token through producer preparation and consumer recapture. Inline parameter records inherit the containing stream's token. The consumer rechecks storage identity, copied bytes, source generations, physical owners and the unchanged strict revocation fence. A changed mapping, stale constructor, forged or mixed storage token, changed bytes or interrupted read clears the snapshot and refuses execution.

JW passes 12,217 Windows x86 checks and the same local ASan/UBSan checks, including the existing 10,185-check physical-owner baseline. These are storage/graph tests; they grant no callback, sequence, drawing or complete-framework authority. Actual Windows image-page qualification is also covered by the resource adapter fixture. Fresh resource and combined-candidate verification and native game acceptance remain separate requirements.

JX's 23 resource groups and JY's fresh 78-group combined gate pass. Original BX progresses to nonempty preparation, then aborts on a heap-only owner-receipt parser: the old formatter supplies no image storage identity. That run remains failed; its zero-heap entries are never reinterpreted as valid image evidence. The supervisor restores all 99 files and releases custody. Its exception also prevents final log/snapshot publication; progress tails retain partial diagnostics.

Version 2 owner entries now include storage kind, domain, serial, module bounds and the original storage range. Heap entries require a heap identity and zero module fields; image entries require a module identity and zero heap identity. Both validate the descriptor flag's four-byte bounds. Copy and retirement must match every field, including format version. Legacy entries retain their strict heap requirement. KA passes 10,561 production-body checks with a controlled image descriptor; ten Windows parser groups verify its actual emitted copy and retirement against the parameter snapshots. These are component receipts, not native campaign acceptance. The new KC candidate must pass its own fresh gate and native run.