Promote Tier2 row and trailer crossover matrix

This commit is contained in:
Jan Petykiewicz 2026-04-21 18:33:13 -07:00
commit 08819c19a4
6 changed files with 139 additions and 11 deletions

View file

@ -18,6 +18,11 @@ samples:
- `numbered_port_warehouse_trailer_family_map_counts`
- `0x00000001 -> 28`
- `0x00000000 -> 9`
- `row_pair_and_numbered_trailer_family_map_counts`
- `35/43 :: 0x00000001 -> 25`
- `35/43 :: 0x00000000 -> 5`
- `10/18 :: 0x00000000 -> 4`
- `10/18 :: 0x00000001 -> 3`
## Off-Row Carrier Maps
@ -34,6 +39,17 @@ The earlier `10/18` family is narrow and fully enumerated in the checked export:
Everything else in the current probe-bearing corpus keeps the `35/43` `Port00` / `Warehouse00`
pair while still preserving the fixed numbered runs at `45..55` and `56..66`.
## Crossover Reading
The new crossover field keeps the row-family and trailer-family interaction explicit too:
- the dominant family is still the ordinary `35/43 :: 0x00000001` case on `25` maps
- the off-row `10/18` family stays mixed, splitting `4` maps on trailer `0x00000000` and `3`
maps on trailer `0x00000001`
- the ordinary `35/43` family is mixed too, with a smaller `5`-map `0x00000000` subset
So the row shift and numbered trailer split do not collapse to one underlying map family.
## Immediate Reading
This keeps the Tier-2 frontier narrower than a generic “candidate table varies by scenario” claim:
@ -41,6 +57,7 @@ This keeps the Tier-2 frontier narrower than a generic “candidate table varies
- the `Port01..11` / `Warehouse01..11` numbered families are structurally fixed across all `37`
probe-bearing maps
- only the `00` pair moves, and it does so in one small `7`-map family
- the numbered trailer split is independent of the row-pair split, so the next owner question is
still the earlier seed or projection seam that feeds nonzero `[candidate+0xba/+0xbb]` into
`0x00412d70`, not the mere existence of the stable named rows themselves
- the numbered trailer split stays mixed across both row-pair families instead of collapsing to
the off-row subset, so the next owner question is still the earlier seed or projection seam
that feeds nonzero `[candidate+0xba/+0xbb]` into `0x00412d70`, not the mere existence of the
stable named rows themselves