Narrow remaining engine type parser frontier

This commit is contained in:
Jan Petykiewicz 2026-04-21 23:28:42 -07:00
commit af21b83300
2 changed files with 7 additions and 1 deletions

View file

@ -19,7 +19,7 @@ This file is the short active queue for the current runtime and reverse-engineer
The packaged profile metadata is stable enough to summarize: `CarSideView_1` is `512x512` at `0.04` VRAM, `CarSideView_2` is `512x256` at `0.02`, and every packaged `_NE` profile is `512x128` with `HorizontalScaleModifier = 0.75` and `MaxPercentOfInterfaceVRAM = 0.09`.
The `_NE` split is now aligned with the locomotive display census too: all `43` packaged `_NE` hits live inside the grounded display prefix, and all `5` unmatched display-tail families are still missing packaged `_NE` profiles.
The cargo side is partially linked now as well: the `.cgo` ladder families and `.cct` sidecar identifiers share the same cargo-family keys for ten checked families, with `Troop` left as the only `.cct`-only outlier.
The next honest static work is to keep promoting those fixed lanes into stable parser fields, explain the five remaining distinct auxiliary-stem cases, and decide how far the `.cgo` ladders plus the low-cardinality `.lco` lanes can be grounded without overclaiming semantics.
The next honest static work is to keep promoting those fixed lanes into stable parser fields, explain the five remaining distinct auxiliary-stem cases, and decide how far the `.cgo` ladders plus the low-cardinality `.lco` lanes can be grounded without overclaiming semantics. The latest corpus check did narrow one point already: the low-cardinality `.lco` lanes do not split cleanly on `_NE` presence, so that branch now wants binary/code correlation rather than more aggregate-only counting.
Preserved checked parser detail now lives in [EngineTypes parser semantics](rehost-queue/engine-types-parser-semantics-2026-04-21.md).
Preserved checked format inventory detail now lives in [RT3 format inventory](rehost-queue/format-inventory-2026-04-21.md).

View file

@ -133,6 +133,12 @@ first `.car` / `.lco` / `.cgo` / `.cct` inspector pass landed.
into named enums without overclaiming semantics
- how much of the remaining high-variance lane subset can be promoted from raw `u32/f32` views
into stable typed semantics without dynamic evidence
- The current checked corpus did not yield a simple `_NE`-presence split for those low-cardinality
`.lco` lanes:
- offsets such as `0x20`, `0x34`, `0x38`, `0x48`, and `0x54` all still mix `_NE` hits and
misses
- that means the next honest `.lco` step is binary/code correlation for those enums rather than
another aggregate-only count surface
- `.cgo`
- whether the leading scalar ladders are enough to justify a named typed field, or whether they
should stay conservative report-only ladders until more binary/code correlation exists