rrt/docs/rehost-queue.md

# Rehost Queue

Working rule:

- Do not stop after commits.
- After each commit, check this queue and continue.
- Only stop if the queue is empty, the remaining work cannot be advanced by any further non-hook
  work without guessing, or you need approval.
- Before any final response, state which stop condition is true. If none is true, continue.

## Next

- Treat the periodic-company trace as the main shellless simulation frontier now that the
  infrastructure footer-bit residue is layout/presentation-owned. The checked-in
  `runtime inspect-periodic-company-service-trace <save.gms>` report now exposes concrete branch
  owners instead of generic blockers:
  - `industry_acquisition_side_branch` carries
    `0x004019e0 -> 0x004014b0` with the city-connection sibling `0x00406050`
  - `city_connection_announcement` carries
    `0x004019e0 -> 0x00406050` plus peer helpers
    `0x00420030 / 0x00420280 / 0x0047efe0`
  - `linked_transit_roster_maintenance` carries
    `0x004019e0 -> 0x00409720 -> 0x004093d0 / 0x00407bd0 -> 0x00408f70 -> 0x00409950`
  - the linked-transit timing seam is now grounded save-side too:
    `[company+0x0d3e]` is the shorter peer-cache refresh counter,
    `[company+0x0d3a]` is the heavier autoroute site-score refresh counter, and
    the route-anchor tuple `[company+0x0d35] / [company+0x7664/+0x7668/+0x766c]` remains save-native
  - the train-side follow-ons are bounded too:
    `0x00408280 / 0x00408380` are the ranked-site chooser and staged autoroute-entry builder above
    the rebuilt site caches, and `0x00409770 / 0x00409830 / 0x00409950` are the append/add/balance
    strip above that
  - the chooser-local cache words are bounded too:
    `[site+0x5c1]` is a live occupancy/count lane reset by `0x00481910` and adjusted by
    `0x004819b0`, with counts sourced from current-site-id resolver `0x004a9340`; meanwhile
    `[site+0x5c5]` is a world-counter age lane stamped at `0x004aee2b`
  - the per-company cache root is bounded too:
    `[site+0x5bd]` is allocated by `0x00407780` as a 0x20-entry table of 0x1a-byte per-company
    cache cells and freed by `0x004077e0`
  - the per-company cache-cell layout is bounded too:
    bytes `+0x00/+0x01` gate participation, dwords `+0x02/+0x06/+0x0a` hold peer count, peer
    pointer, and peer-cache refresh stamp, and floats `+0x0e/+0x12/+0x16` are the
    weighted/raw/final score lanes
  - the persisted-vs-live split is tighter now too:
    the minimal save-backed identity set is `[site+0x276]`, `[site+0x04]`, `[site+0x2a4]`,
    `[site+0x2a8]`, `[peer+0x04/+0x08]`, `[company+0x0d35/+0x0d56/+0x7664/+0x7668/+0x766c]`,
    and world calendar lanes `[world+0x15/+0x0d]`, while the actual cache contents at
    `[site+0x5bd]`, `[site+0x5c1/+0x5c5]`, and `[site+0x0e/+0x12/+0x16]` are live rebuilt scratch
    lanes under `0x004093d0 / 0x00407bd0 / 0x00481910 / 0x004819b0 / 0x004aee2b`
  - the upstream live-table owners are tighter now too:
    active-company refresh owner `0x00429c10` walks the live company roster and re-enters
    `0x004093d0`; candidate table root `0x0062ba8c` is world-load owned by
    `0x0041f4e0 -> 0x0041ede0 -> 0x0041e970`; and route-entry tracker compatibility / chooser
    helpers `0x004a6360 / 0x004a6630` already sit under owner-notify refresh `0x00494fb0`
  - the placed-structure replay strip is tighter now too:
    `0x00444690 -> 0x004133b0 -> 0x0040ee10 -> 0x0040edf6 -> 0x00480710` already republishes
    anchor-side linked-peer ids, route-entry anchors, and world-cell owner chains, and later
    runtime path `0x004160aa -> 0x0040ee10` re-enters the same family outside bring-up
  - the subtype-`4` follow-on is tighter now too:
    `0x0040eba0` already republishes `[site+0x2a4]` through `0x004814c0 / 0x00481480` plus
    world-cell chain helpers `0x0042c9f0 / 0x0042c9a0`, so self-id replay is no longer the open
    linked-transit blocker
  - the owner-company branch is tighter now too:
    direct inspection of `0x0040ea96..0x0040eb65` shows that it consumes `[site+0x276]` and
    branches through owner/company helpers, but does not itself rehydrate `[site+0x276]`
  - that makes the next linked-transit question narrower:
    identify which earlier restore or service owner feeds `[site+0x276]` and the live linked-peer
    rows before replay continuation `0x0040e360..0x0040edf6`, beyond the already-grounded
    `0x00480710` anchor-side refresh, before `0x004093d0 / 0x00407bd0 / 0x004a6630`, because the
    candidate table, route-entry-tracker owners, replay-strip framing, subtype-`4` self-id replay,
    bounded train-side strip
    `0x00409770 / 0x00409830 / 0x00409950`, and cache-cell semantics are no longer the blocker
- Make the next static/rehost slice the near-city industry acquisition owner seam under
  `0x004014b0`, not another generic infrastructure pass. The concrete questions are:
  - which minimum persisted peer-site fields on the already-grounded `0x006cec20` placed-structure
    collection feed near-city unowned-industry candidates
  - which placed-structure, city-or-region, and company linkage survives save/load strongly enough
    to drive the proximity scan
  - whether the acquisition branch can be rehosted as a shellless sibling beside the already
    grounded annual-finance helper
  - the save-side `0x36b1/0x36b2/0x36b3` triplet seam is now also loaded into the checked-in
    save-slice model as first-class `placed_structure_collection` context, carrying stem pairs plus
    grounded footer/policy status lanes instead of remaining inspection-only evidence
  - the separate `0x38a5/0x38a6/0x38a7` side-buffer seam is now also loaded into the save-slice
    model as first-class `placed_structure_dynamic_side_buffer_summary` context, carrying the
    grounded owner-shared dword, compact-prefix summaries, name-pair summaries, and overlap counts
    against the triplet corpus instead of remaining trace-only evidence
  - the save-side `0x55f1/0x55f2/0x55f3` region triplet seam is now also loaded into the
    save-slice model as first-class `region_collection` context, carrying region names, the
    grounded policy lanes, reserved-policy dwords, and embedded profile rows instead of leaving
    region triplets inspection-only
  - the save-side fixed-row run candidate family is now also the next save-slice seam to keep
    first-class once grounded, because it is the closest save-native candidate family to the
    still-missing cached tri-lane inputs behind `[site+0x310/+0x338/+0x360]`
  - cross-save fixed-row comparison is tighter now too:
    `runtime compare-region-fixed-row-runs p.gms q.gms` shows shared shape-family matches even
    though the best raw `rows_offset` drifts between saves, so the tri-lane-adjacent row family
    should be treated as a stable shape-family seam rather than a fixed-offset seam
  - the periodic-company trace now carries that save-native seam directly too:
    it exposes the current top tri-lane-adjacent fixed-row shape-family candidates with row-count,
    stride, rows-offset, and probable-density-lane hints, so the tri-lane frontier is now
    structured as “save shape-family candidates present, fixed offset ruled down” instead of only
    a prose note
  - the `0x5dc1/0x5dc2` serializer bundle is tighter now too:
    atlas-backed recovery bounds `0x0040c980 -> 0x0045b560` as emitting the derived payload over
    `[site+0x23e/+0x242/+0x246/+0x24e/+0x252]`, so the remaining restore-owner question should
    treat that persisted selector/child/runtime bundle as one seam rather than only
    `[site+0x23e/+0x242]`
  - the loader-side counterpart narrows the minimum shellless identity subset too:
    `0x0045c150` restores `[owner+0x23e/+0x242]`, clears the transient roots, and then hands off
    to `0x0045c310 / 0x0045b5f0 / 0x0045b6f0` to rebuild the primary child handle plus the larger
    ambient/animation/light/random-sound family, so current shellless planning can keep the
    minimum persisted subset at cached ids `[site+0x3cc/+0x3d0]`, restored name-pair
    `[owner+0x23e/+0x242]`, and the post-secondary discriminator byte while treating
    `[owner+0x246/+0x24e/+0x252]` as part of the broader saved bundle that still flows through the
    rebuild side
  - the periodic-company trace now surfaces the strongest non-transport owner-company candidate
    family directly too:
    ordinary loaded runtime-effect lane
    `0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20` above the non-direct
    `0x4e99/0x4e9a/0x4e9b` bundle, with the remaining gap narrowed to the control-lane mapping
    from loaded rows into trigger kind `8` and then into the placed-structure mutation opcodes
- Direct disassembly now narrows that acquisition strip further:
  - `0x004014b0` scans the live placed-structure collection at `0x0062b26c`
  - `0x0041f6e0 -> 0x0042b2d0` is the center-cell token gate over the current region
  - `0x0047de00 -> 0x0040c990` is the linked-region status branch reused from the city-connection
    helper strip
  - `0x004801a0` is the route-anchor reachability gate for one candidate site through
    `0x00401860 -> 0x0048e3c0`
  - the company-side half of that gate is now explicit too: `0x00401860` validates or rebuilds the
    cached linked-transit route-anchor entry id `[company+0x0d35]` from the live route-entry
    collection using fallback count lanes `[company+0x7664/+0x7668/+0x766c]`
  - those four company lanes are now threaded into save-native company market state, so the
    route-anchor side of the acquisition gate is no longer just a trace-only blocker
  - `0x0040d360` is the subtype-`4` predicate over the current placed-structure subject's
    candidate byte `[candidate+0x32]`
  - `0x0040d540` scores site/company proximity with pending-bonus context
  - `0x0040cac0` samples the cached site tri-lane at `[site+0x310/+0x338/+0x360]`
  - `0x00405920` walks same-company linked site peers above the live placed-structure / peer-site
    collection seam
  - `0x00420030 / 0x00420280` is the boolean/selector peer-site pair over `0x006cec20`, combining
    `0x0042b2d0`, the optional company filter through `0x0047efe0`, the station-or-transit gate
    `0x0047fd50`, and the status branch `0x0047de00 -> 0x0040c990`
  - `0x0047efe0` and `0x0047fd50` both consume `[site+0x04]` as the live backing-record selector
  - `0x00480210` writes linked-peer row `[peer+0x04]` from the anchor-site id argument
  - `0x0040f6d0 -> 0x00481390` writes the anchor-site linked peer id back into `[site+0x2a8]`
  - `0x0047dda0` consumes `[peer+0x08]` as the linked route-entry anchor id
  - `0x0041f7e0 / 0x0041f810 / 0x0041f850` already ground `[site+0x2a4]` as the record's own
    placed-structure id lane beneath the peer-chain helpers
  - `0x0040d210` is the owner-side placed-structure resolver from `[site+0x276]` through
    `0x0062be10`
  - `0x00480710 -> 0x0048abc0 / 0x00493cf0` is the linked-site refresh and route-entry rebind or
    synthesis strip above that anchor lane
  - the same `0x00480710` replay strip now also republishes the concrete world-cell owner chains:
    `0x0042bbf0 / 0x0042bbb0` remove or prepend the current site in the owner chain rooted at
    `[cell+0xd4]`, while `0x0042c9f0 / 0x0042c9a0` remove or prepend it in the linked-site chain
    rooted at `[cell+0xd6]`
  - late world bring-up `0x00444690` is the current caller of
    `0x004133b0 placed_structure_collection_refresh_local_runtime_records_and_position_scalars`
  - `0x004133b0` drains queued site ids through `0x0040e450` and then sweeps all live sites
    through `0x0040ee10`
  - `0x0040ee10` reaches `0x0040edf6 -> 0x00480710` for linked-peer refresh and then the later
    `0x0040e360` follow-on
  - `0x004160aa` is a separate non-bring-up runtime caller of `0x0040ee10`
  - the direct `0x36b1` per-record callbacks serialize base scalar triplets
    `[this+0x206/+0x20a/+0x20e]` plus the subordinate payload callback strip, and the
    `0x4a9d/0x4a3a/0x4a3b` side-buffer owner only persists route-entry lists, three byte arrays,
    five proximity buckets, and the sampled-cell list
  - `0x004269b0` consumes the chosen site's own placed-structure id lane `[site+0x2a4]`
- That leaves the acquisition blocker set tighter than before:
  - peer-site and linked-site replay seams are grounded enough for planning
  - the live owner-company meaning of `[site+0x276]` is already grounded through `0x0047efe0`,
    with the direct owner-side resolver bounded at `0x0040d210`
  - `[site+0x2a4]` is already grounded as the record's own placed-structure id lane through the
    peer-chain helpers `0x0041f7e0 / 0x0041f810 / 0x0041f850`, and constructor-side `0x00480210`
    already seeds that lane for new linked-site rows
  - direct disassembly now also shows `0x004269b0` resolving one chosen site id through live
    placed-structure collection `0x0062b26c` before mutating `[site+0x276]`, so the
    `[site+0x2a4]` self-id lane is reconstructible from collection identity rather than needing a
    separate serializer-owned projection
  - the subtype byte consumed as `[candidate+0x32] == 4` is already bounded under the
    aux-candidate load/stem-policy chain
    `0x004131f0 -> 0x00412fb0 -> 0x004120b0 -> 0x00412ab0`
  - remaining non-hook gaps are the save or replay projection of `[site+0x276]` and the cached
    tri-lane `[site+0x310/+0x338/+0x360]`
  - the checked-in periodic-company trace now exposes those gaps as structured statuses instead of
    only prose:
    - site owner-company lane = `live_meaning_grounded_projection_missing`
    - site self-id lane = `live_meaning_grounded_reconstructible_from_collection_identity`
    - site cached tri-lane = `delta_reader_grounded_projection_missing`
    - candidate subtype lane = `cached_candidate_id_bridge_grounded_via_stream_load`
    - backing-record selector bridge = `stream_load_callback_grounded_via_0x40ce60`
  - the same trace now also carries three explicit projection hypotheses for the next pass:
    - `site_owner_replay_from_post_load_refresh_self_id_reconstructible`
    - `site_cached_tri_lane_payload_or_restore_owner`
    - `cached_source_candidate_id_to_subtype_projection`
  - the first of those is now bounded more tightly:
    `0x004133b0 -> 0x0040e450 / 0x0040ee10` rebuilds cloned local-runtime records and local
    position/scalar triplets, but direct constructor and caller recovery now shows the
    owner-company lane also living under the create-side allocator/finalize family
    `0x004134d0 -> 0x0040f6d0 -> 0x0040ef10`, plus data-driven loader callers
    `0x0046f073 / 0x004707ff -> 0x0040ef10`
  - the checked-in replay strip is narrower than before now:
    direct local inspection now splits it more precisely:
    `0x0040ee10` itself only reads cached source lane `[site+0x3cc]` in the checked range, and
    the bounded `0x00480710` neighborhood is working from `[site+0x04]`, `[site+0x08]`, and
    `[site+0x3cc]`; but the broader immediate continuation `0x0040e360..0x0040edf6` still
    consumes `[site+0x2a8]`, `[site+0x2a4]`, and `[site+0x276]` around
    `0x0040d230 / 0x0040d1f0 / 0x00480710 / 0x00426b10 / 0x00455860`, so the replay family is
    narrowed rather than ruled out for owner-company rehydration; in the checked range those
    `[site+0x276]` uses are still reads/queries rather than a direct rehydrating store
  - the create-side owner family is grounded too now:
    `0x004134d0` allocates a new row through `0x00518900`, `0x0040f6d0` seeds `[site+0x2a4]`,
    copied name bytes, `[site+0x276]`, `[site+0x3d4/+0x3d5]`, and cleared local caches, and the
    shared finalize helper `0x0040ef10` has both create-side callers `0x00403ef3 / 0x00404489`
    and data-driven loader callers `0x0046f073 / 0x004707ff`
  - one persisted tuple path is grounded too now:
    the data-driven loader callers `0x0046f073 / 0x004707ff` push tuple fields
    `[+0x00/+0x04/+0x0c]` into `0x0040ef10`, and inside that helper arg3 becomes `ebx` and then
    `[site+0x276]` at `0x0040f5d4`
  - that tuple path is classified further now too:
    the checked-in atlas ties `0x004707ff` to multiplayer transport selector-`0x13` body
    `0x004706b0`, which attempts the placed-structure apply path through
    `0x004197e0 / 0x004134d0 / 0x0040eba0 / 0x0052eb90 / 0x0040ef10`
  - the neighboring batch builder is classified too:
    `0x00472b40` is the multiplayer transport selector-`0x72` counted live-world apply path, and
    its inner builders `0x00472bef / 0x00472d03` reach `0x004134d0` from counted transport
    records rather than ordinary save-load restore
  - one surviving non-transport `0x004134d0` caller is bounded away from persisted restore too:
    `0x00422bb4` pushes one live `0x0062b2fc` record plus local args and literal flags `1/0`
    into `0x004134d0`, then returns the created row id through an out-param instead of feeding
    the tuple-backed finalize path
  - the remaining `0x00508fd1 / 0x005098eb` family is bounded away too:
    it caches the created site id in `[this+0x7c]`, re-enters `0x0040eba0` with immediate coords,
    and later calls `0x0040ef10` with a hard zero third arg, so it reads as another live
    controller path rather than the missing persisted owner seam
  - the adjacent `0x00473c20` family is bounded away too:
    it drains queued site ids and coordinate pairs from scratch band `0x006ce808..0x006ce988`,
    re-enters `0x0040eba0` at `0x00473c98`, and clears each queued id slot, so it is a local
    post-create refresh path rather than a persisted replay owner
  - the remaining direct `[site+0x276]` store census is bounded away too:
    `0x0042128d` is broad zero-init in the `0x00421430` constructor neighborhood,
    `0x00422305` computes a live score/category lane before publishing event `0x7`,
    `0x004269c9/0x00426a2a` are acquisition commit/clear helpers, and
    `0x004282a9/0x004300d6` are bulk owner-transfer writes
  - the paired tagged triplet serializer is bounded away too:
    `0x00413440` is the save-side `0x36b1/0x36b2/0x36b3` serializer, dispatches each live record
    through vtable slot `+0x44`, and keeps that seam on the already-grounded triplet payload
    rather than the missing `[site+0x276]` replay owner
  - the ordinary bring-up strip is narrower too:
    `0x00444690 -> 0x004133b0` is still the checked ordinary restore-side replay owner above live
    placed structures, but it only drains queued local-runtime ids through `0x0040e450` and then
    sweeps live rows through `0x0040ee10`; after that, bring-up proceeds into later route-entry,
    grid, and tagged refresh owners rather than re-entering the constructor/finalize family
    `0x004134d0 / 0x0040f6d0 / 0x0040ef10`
  - the ordinary restore staging order is explicit now too:
    world bring-up calls the tagged `0x36b1/0x36b2/0x36b3` stream-load owner `0x00413280` at
    `0x00444467`, refreshes the placed-structure dynamic side buffers through `0x00481210` at
    `0x004444d8`, and only later enters the queued local-runtime replay owner
    `0x00444690 -> 0x004133b0 -> 0x0040ee10`
  - the broader load-side stream owner is separate too:
    `0x00413280` is the actual tagged `0x36b1/0x36b2/0x36b3` stream-load owner, dispatching
    per-entry vtable slot `+0x40`; current local recovery still only grounds that seam through the
    cached-source bridge `0x0040ce60 -> 0x0040cd70 / 0x0045c150`, not through a direct
    `[site+0x276]` republisher
  - the grouped-opcode family is narrower rather than fully ruled down:
    `0x00431b20` is still only reached through scenario runtime-effect service
    `0x004323a0 -> 0x00432f40` via direct call `0x00432317`, but that service loop is itself
    called from world bring-up at `0x00444d92` with trigger kind `8` under shell-profile latch
    `[0x006cec7c+0x97]`; so `0x0061039c` currently reads as a startup-time live runtime-effect
    application lane rather than an ordinary tagged restore owner
  - that `kind 8` branch is ordinary in one important way now too:
    restore-side loader `0x00433130` repopulates the live event collection `0x0062be18` from packed
    chunk family `0x4e21/0x4e22`, and the event-detail editor strip
    `0x004d90ba..0x004d91ed` writes trigger field `[event+0x7ef]` across the full `0x00..0x0a`
    range through controls `0x4e98..0x4ea2`, including kind `8` at `0x004d91b3`; so the remaining
    startup compact-effect question is no longer whether kind `8` is a special synthetic class, but
    which loaded kind-`8` rows in `0x0062be18` can actually reach the placed-structure mutation
    opcode families under `0x00431b20`
  - the event-detail editor family tightens that one step further too:
    selected-event control root `0x4e84` and refresh strip `0x004db02a / 0x004db1b8..0x004db309`
    mirror current trigger field `[event+0x7ef]` back into those same `0x4e98..0x4ea2` controls,
    while editor-side builder `0x004db9e5..0x004db9f1` allocates an ordinary runtime-effect row
    into `0x0062be18` through `0x00432ea0`; so the remaining startup compact-effect question is no
    longer whether kind `8` lives on a separate editor/build class either, but which loaded
    kind-`8` rows actually carry the mutation-capable compact payloads
  - bundle-side inspection now grounds the startup collection itself:
    sampled maps such as `War Effort.gmp`, `British Isles.gmp`, `Germany.gmp`, and
    `Texas Tea.gmp` expose non-direct `0x4e99/0x4e9a/0x4e9b` runtime-event collections, and the
    compact `0x526f/0x4eb8/0x4eb9` row family is now decoded into actual condition/grouped row
    summaries rather than opaque slices
  - the rehosted collection summary now makes the remaining control-lane gap explicit too:
    it reports `records_with_trigger_kind`, `records_missing_trigger_kind`,
    `nondirect_compact_record_count`, `nondirect_compact_records_missing_trigger_kind`, and
    `control_lane_notes`; real `War Effort.gmp` output currently shows `24/24` compact non-direct
    rows still missing decoded trigger kind, which narrows the next owner question to the
    non-row-body control lane rather than the compact row framing itself
  - the same probe now narrows the candidate runtime-effect set too:
    it reports which decoded records already carry grouped opcodes in the grounded
    `0x00431b20` dispatch strip; real `War Effort.gmp` currently narrows that to record indexes
    `[1, 9, 12, 13, 14, 15, 16, 17, 22]`, all through opcode `4`, with descriptor labels
    `Game Variable 1`, `Company Variable 1..4`, and `Player Variable 1`, so the next pass can
    focus on that smaller subset instead of the full 24-row compact collection while avoiding the
    earlier overclaim that opcode `4` alone already proves a placed-structure mutation row
  - the sampled-map framing split is narrower now too:
    targeted real-map inspections of `Texas Tea.gmp`, `British Isles.gmp`, and `Germany.gmp`
    still show their entire event-runtime collections as nondirect compact
    `0x4e99/0x4e9a/0x4e9b` rows with `records_with_trigger_kind = 0`, even when grouped rows
    already reach the grounded `0x00431b20` dispatch strip. That means the direct full-record
    `0x4e21/0x4e22` parser path is not currently bridging `[event+0x7ef]` for the ordinary
    mutation-capable rows in those sampled maps.
  - the widened compact-cluster probe now makes that same gap first-class too:
    `runtime inspect-compact-event-dispatch-cluster <map-or-dir>` now reports all dispatch-strip
    descriptor occurrences, their `trigger_kind`, payload family, and the aggregated
    `dispatch_descriptor_occurrence_counts` / `dispatch_descriptor_map_counts` summaries instead of
    only unknown descriptor ids. On `Texas Tea.gmp`, the widened report now shows
    `548 Add Building Port01`, `8 Economic Status`, and `43 Company Variable 1` all arriving on
    `real_packed_nondirect_compact_v1` rows with `trigger_kind = null`, while the count summary
    reports `Company Variable 1 = 4` occurrences and the other two once each, so the next pass can
    work from a checked scalable probe rather than ad hoc `inspect-smp` scrapes.
  - the scalable summary sibling is grounded too:
    `runtime inspect-compact-event-dispatch-cluster-counts <map-or-dir>` reuses the same analysis
    but emits only the corpus-level count fields, so the next broader map-install pass no longer
    needs to wade through every occurrence payload just to compare descriptor or trigger-kind
    coverage.
  - the per-record trigger gate is explicit now too:
    direct disassembly of `0x004323a0` shows the service returns before dispatch unless
    one-shot latch `[event+0x81f]` is clear, mode byte `[event+0x7ef]` matches the selected
    trigger-kind argument from `0x00432f40`, and the compact chain root `[event+0x00]` is
    nonzero. The kind-`8` side path at `0x00432ca1..0x00432cb0` only calls `0x00438710` on
    already-live records carrying `[event+0x7ef] == 8`. So the remaining ordinary bundle question
    is no longer “does the service loop itself bypass the per-record trigger byte?”; it is which
    later owner, if any, materializes or retags `[event+0x7ef]` for the nondirect compact rows.
  - the post-load retagger is narrower than that missing owner too:
    direct disassembly of `0x00442c30` (called from `0x00443a50` at `0x00444b50`) shows a
    hardcoded scenario-name patch table over already-live records in `0x0062be18/0x0062bae0`.
    The checked cases mostly tweak modifier bytes `[event+0x7f9/+0x7fa]` or nested payload scalars
    on records that already carry concrete kinds such as `7` (`Open Aus`, `The American`), `6`
    (`Test connections`), `5` (`Win - Gold`), and `1` (`Win - Silver` / `Win - Bronze`). So the
    remaining trigger-kind frontier is no longer “maybe the name sweep bulk-materializes null
    kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes
    `[event+0x7ef]` itself or a still-later owner does.
  - two explicit trigger-kind materializations are now grounded inside that retagger:
    the `SP - GOLD` branch at `0x00443526` rewrites `[event+0x7ef]` from `1 -> 5` on live
    runtime-event id `1` when `[world+0x66de]` is set and the checked root payload is kind `7`
    with subtype byte `5`, while the `Labor` branch at `0x00443601` rewrites `[event+0x7ef]`
    from `0 -> 2` on live runtime-event id `0x0d` when the same scenario flag is set and the
    checked `0x3c -> 0x3d` child payload pair carries the matching negative scalar sentinel.
  - cross-map probing now gives a better static-analysis lead too:
    `British Isles.gmp` shows no current `0x00431b20` dispatch-strip rows, `Germany.gmp` stays on
    `Game Variable 1` plus `Company Variable 3..4`, while `Texas Tea.gmp` adds `Economic Status`
    and one still-unlabeled grouped descriptor id `548`; that makes descriptor `548` plus the
    `opcode 8` branch on record `7` the next concrete non-hook analysis target above the compact
    runtime-event loader
  - the checked-in function map now sharpens that `Texas Tea.gmp` branch too:
    opcode `0x08` in the grounded `0x00431b20` dispatch strip lands on
    `0x00426d60 company_deactivate_and_clear_chairman_share_links`, so the open question is
    whether grouped descriptor id `548` is the missing compact-event label for that destructive
    company-clear path or a neighboring unmapped id-space entry in the same branch family
  - the broader installed-map sweep narrows that question further:
    across all `41` bundled `.gmp` files in the current `rt3_105/maps` install, grouped descriptor
    id `548` currently appears only once, in `Texas Tea.gmp` record `7`, with `opcode 8`,
    `scalar 0`, standalone condition tuple `(7, subtype 0)`, and compact signature family
    `nondirect-ge1e-h0001-0007-0000-6d00-0200-p0000-0000-0000-ffff`
  - the same wider sweep also rules out the simplest alias theory:
    the ordinary checked-in `Deactivate Company` descriptor `13` does appear in real map bundles,
    but only on `opcode 1` with scalar `1` in `British Isles.gmp`, `Chicago to New York.gmp`,
    `East Coast, USA.gmp`, `Japan Trembles.gmp`, and `State of Germany.gmp`; it does not appear on
    the `opcode 8` deactivation branch, so grouped descriptor id `548` is not just the obvious
    compact stand-in for ordinary descriptor `13`
  - that compact opcode-`8` cluster is now grounded as an artifact-boundary problem rather than a
    mysterious compact-only id family:
    direct binary inspection of the `0x00610398` EventEffects table shows the contiguous table does
    not stop at row `519`; it continues cleanly through row `613`, with the extractor-side
    sequential descriptor invariant still holding. The checked-in extractor and semantic catalog now
    cover the full `614`-row export instead of the old truncated `520`-row slice
  - that closes the earlier unlabeled cluster:
    grouped descriptor ids `521`, `526`, `528`, `548`, and `563` are now recovered as
    `Add Building FarmGrain`, `Add Building Furniture Factory`, `Add Building Logging Camp`,
    `Add Building Port01`, and `Add Building Warehouse05` respectively. The checked-in
    `event-effects-building-bindings.json` now carries the full descriptor-side candidate bridge
    across all `111` add-building rows (`503..613`) through the direct `descriptor_id - 503`
    mapping in `0x00430270`, while concrete candidate names remain grounded only for the stable
    RT3 1.05 live-catalog run `0..66` exposed by `0x0041ede0` and the checked candidate-table
    corpus
  - the earlier `label_id - 2000` bridge for `548` and `563` is now known to be a false lead:
    those numeric collisions hit the special-condition label table
    (`Disable Building Stations`, `Completely Disable Money-Related Things`), but the extended
    EventEffects table proves the actual grouped descriptors are add-building slots, not
    special-condition verbs
  - the compact opcode-`8` frontier therefore shifts:
    direct disassembly of `0x00430270` now shows that the add-building consumer does not branch on
    grouped opcode at all for descriptor strip `503..613`; it consumes the descriptor-derived
    candidate id, placement count byte `0x11`, center words `0x12/0x14`, and radius word `0x16`,
    clamps that radius to at least `1`, and retries randomized placements up to `200` times.
    The next static-analysis pass should therefore target the remaining span-field meaning and
    shell-owned placement-flow ownership on that strip, not more missing-label recovery: the
    descriptor-side candidate bridge is now checked in across `503..613`, and the honest remaining
    boundary is the missing non-hook name catalog for candidate ids `67..110`
  - the new offline `BuildingTypes` source report sharpens that missing name-catalog boundary too:
    `runtime inspect-building-type-sources rt3_wineprefix/drive_c/rt3/Data/BuildingTypes artifacts/exports/rt3-1.06/event-effects-building-bindings.json`
    now reports `77` `.bca` files, `200` `.bty` files, and `208` canonical asset stems. Against
    the checked-in named add-building bindings it finds exactly `43` shared canonical stems,
    `24` binding-only stems (`Port00..11` and `Warehouse00..11`), and `165` broader asset-only
    stems. The numbered live `Port00..11` and `Warehouse00..11` names therefore collapse to
    generic asset stems `Port` and `Warehouse` on disk, so the `BuildingTypes` directory is now
    grounded as a wider offline source catalog, but not yet as a direct second live candidate-name
    owner for descriptor-side ids `67..110`
  - the local-runtime builder strip now reinforces that same boundary:
    direct disassembly of `0x00418be0` shows the broader placed-structure rebuild lane resolving
    its caller-supplied stem only through `0x00416e20 indexed_collection_resolve_live_entry_id_by_stem_string`
    against the current live candidate collection, then projecting runtime scratch through
    `0x00416ec0` and `0x00418610`. So the broader `BuildingTypes` asset pool is not yet a proven
    alternate live owner for descriptor-side add-building candidate ids; current non-hook evidence
    still routes stem resolution back through the live candidate collection that tops out at the
    contiguous named run `0..66`
  - the shipped-map compact-dispatch corpus is narrower than the descriptor strip too:
    `runtime inspect-compact-event-dispatch-cluster-counts rt3_wineprefix/drive_c/rt3_105/maps`
    scans all `41` bundled maps and finds add-building dispatch occurrences only for descriptors
    `506`, `507`, `521`, `526`, `528`, `548`, and `563`. No bundled-map dispatch rows currently
    exercise descriptor ids `570..613`, so the back half of the widened add-building strip is now
    bounded as descriptor-grounded but latent in the shipped compact-event corpus
  - the concrete owner strip above that bundle is grounded now too:
    `0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`,
    calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load
    family rather than behind an unknown blob writer
  - those non-direct rows still carry stable structural family ids in the inspection notes:
    the row probe emits `compact signature family = nondirect-...` keys alongside decoded grouped
    descriptors, so repeated compact families can still be compared across maps without scraping
    raw bytes
  - that moves the startup compact-effect blocker again:
    the remaining question is no longer compact row framing, but which serialized/live rows in this
    now-decoded non-direct bundle correlate to loaded trigger-kind `8` rows and which of those can
    reach the placed-structure mutation opcodes under `0x00431b20`
  - the `[site+0x27a]` companion lane is grounded now too:
    it is a live signed scalar accumulator rather than a second owner-identity seam, with zero-init
    at `0x0042125d` and `0x0040f793`, accumulation at `0x0040dfec` and `0x00426ad8`, direct set on
    acquisition commit at `0x004269e4`, and negated clear at `0x00426a44..0x00426a90`
  - the remaining owner-company question is therefore narrower than “find any replay seam”:
    identify which non-transport persisted source family outside the currently bounded direct
    allocator/finalize/store families, the save-side `0x00413440` serializer, the load-side
    `0x00413280` cached-source bridge, the checked ordinary replay strip
    `0x00444690 -> 0x004133b0 -> 0x0040ee10`, and the already-bounded loaded runtime-effect lane
    `0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20` feed the tuple or companion
    restore calls that are sufficient to repopulate `[site+0x276]` for shellless acquisition; the
    remaining runtime-effect subquestion is now which loaded kind-`8` rows can carry the
    placed-structure mutation opcodes rather than whether kind `8` is synthetic
  - the ordinary restore-vs-finalize split is tighter now too:
    direct disassembly shows `0x00413280` stream-loading `0x36b1/0x36b2/0x36b3` through per-entry
    vtable slot `+0x40`, and `0x00444690` simply enters `0x004133b0` before continuing into later
    grid/world refresh owners; neither ordinary bring-up owner re-enters
    `0x004134d0 / 0x0040f6d0 / 0x0040ef10` for already-restored rows. The positive
    `[site+0x276]` store at `0x0040f5d4` therefore remains grounded only on explicit tuple/create
    paths, so the next non-hook pass should look for a non-transport persisted tuple family or a
    later ordinary restore owner rather than another generic replay scan.
  - the loaded runtime-effect lane is narrower now too:
    real map inspections already show decoded `0x00431b20` grouped-descriptor content inside the
    ordinary non-direct bundle without any recovered trigger-kind metadata in the current surface:
    `Texas Tea.gmp` reports `Add Building Port01`, `Alternate USA.gmp` reports
    `Add Building FarmGrain` and `Add Building Logging Camp`, and `War Effort.gmp` reports only
    variable bands, while all three currently summarize `trigger_kinds_present = []` and
    `records_with_trigger_kind = 0`. That means the next non-hook pass on this branch is no longer
    “do ordinary loaded rows reach `0x00431b20`?”; it is “where is trigger-kind represented or
    bypassed for those already-decoded ordinary compact rows?”
  - the adjacent control-lane inheritance path is narrower now too:
    direct disassembly shows `0x0042db20` loading only the linked `0x1e`/`0x28` row bodies from
    `0x4e9a`, while the separate deep-copy helper `0x0042e050` copies text bands plus the full
    `[event+0x7ee..0x7fa]` block. Current caller census shows that deep-copy seam reached from the
    event-editor duplication path at `0x004dba23`, not from the ordinary `0x00433130` restore
    strip. So the next non-hook question is not “maybe load inherits trigger kind through
    0x0042e050”; it is which other ordinary owner, if any, seeds `[event+0x7ef]` for these
    already-decoded non-direct rows.
  - the first non-editor positive control-lane writer is bounded away from restore too:
    direct disassembly now shows `0x00430b50` allocating a fresh live runtime-effect row through
    `0x00432ea0 -> 0x0042d5a0`, zero-initializing the full `[event+0x7ee..0x7fa]` block, then
    seeding `[event+0x7ef]` to `2` or `3` plus adjacent control bytes. That builder is reached
    from the `0x004323a0` follow-on service strip at `0x0043232e`, not from `0x00433130` restore.
    So the remaining ordinary-owner question is narrower again: neither deep-copy inheritance nor
    the first positive control-lane builder currently belongs to the non-direct `0x4e9a` load path.
  - the remaining non-editor control-lane mutators are bounded away from restore too:
    direct disassembly of `0x00443200..0x004436e3` shows a name-driven live retagger sweep over
    the already-materialized event collection `0x0062be18`, matching text bands through
    `0x005a57cf` against scenario strings such as `New Beginnings`, `Chicago to New York`,
    `The American`, and `Labor`, then mutating `[event+0x7ef/+0x7f9/+0x7fa]` on those live
    records. That is now a grounded post-load live-maintenance seam, not the missing ordinary
    `0x4e9a` control-lane owner.
  - the positive-path caller census is effectively boxed in now too:
    direct `0x0040ef10` callers are the create-side pair `0x00403ef3 / 0x00404489`, the transport
    tuple pair `0x0046f073 / 0x004707ff`, and the already-ruled-down live controller
    `0x005098eb`; direct `0x004134d0` callers are the create-side pair `0x00403ed5 / 0x0040446b`,
    the transport-side pair `0x0046efbf / 0x0047074b`, the counted transport builders
    `0x00472bef / 0x00472d03`, plus live/controller callers `0x00422bb4` and `0x00508fd1`.
    That means the still-missing owner seam is no longer “find another obvious constructor/finalize
    caller”; it is specifically a non-transport persisted tuple family or a later ordinary restore
    owner outside this boxed caller set.
  - the second is narrower in the same way:
    the checked-in `0x36b1/0x36b2/0x36b3` triplet seam and the
    `0x4a9d/0x4a3a/0x4a3b` side-buffer seam still do not serialize `[site+0x310/+0x338/+0x360]`
    directly, so the known save seams are ruled down even though a later restore family is still open
  - the dynamic side-buffer load seam is ruled down too:
    `0x00481430 -> 0x0047d8e0` repopulates the route-entry list, three byte arrays, five
    proximity buckets, and the trailing scratch band from stream, but still does not claim the
    cached tri-lane
  - the tri-lane now has one real runtime accumulator too:
    direct local binary inspection shows `0x0040c9a0` folding `[site+0x310/+0x338/+0x360]` into
    `[site+0x2b4/+0x2b8/+0x2bc]`, mirroring the nine-dword side array rooted at `[site+0x2e4]`,
    and then clearing the tri-lane
  - caller census keeps that tri-lane role narrow:
    `0x0040c9a0` only appears under the broad live-collection sweep
    `0x0040a3a1..0x0040a4d3`, while `0x0040cac0` stays under weighted scoring or evaluation
    families such as `0x0040fcc0..0x0040fe28` and `0x00422c62..0x00422d3c`
  - direct local binary inspection now rules out the old “no live writer” hypothesis too:
    `0x0040d4aa/0x0040d4b0` add into `[site+0x310]`,
    `0x0041114a7/0x004111572` add into `[site+0x310]`,
    `0x0041114b7/0x004111582` add into `[site+0x338]`, and
    `0x0041118aa/0x0041118f4` add into `[site+0x360]`
  - the writer family is now bounded one level higher:
    `0x0040d450` is a small owner-company-aware producer over `[site+0x276]`,
    `0x00455810/0x00455800/0x0044ad60`, and `0x00436590` ids `0x66/0x68`, while
    `0x00410b30..0x004118f4` is a broader candidate-processing loop walking `0xbc`-stride rows,
    gating them through `0x00412560`, and then accumulating both stack temporaries and direct
    writes into `[site+0x310/+0x338/+0x360]`
  - `0x00412560` is now bounded as the shared candidate/admissibility gate above that loop:
    it checks candidate-row fields `+0x20/+0x22/+0x24/+0x28/+0x2c/+0x44`, world date/flags via
    `0x006cec78`, and the candidate table `0x0062ba8c`
  - the cached source/candidate bridge is now grounded on stream load too:
    direct local binary inspection shows `0x00413280` dispatching per-entry vtable slot `+0x40`
    on the `0x005c8c50` specialization table, that slot resolving to `0x0040ce60`, and
    `0x0040ce60` immediately re-entering `0x0040cd70` plus `0x0045c150`
  - the third hypothesis is now a cached source/candidate bridge question, not just a raw
    `[site+0x04]` selector question:
    `0x0040cd70` seeds `[site+0x3cc/+0x3d0]` from `0x62b2fc / 0x62b268`,
    `0x0040cee0` resolves cached candidate id `[site+0x3d0]` back into the live candidate pool,
    and `0x004138f0` already counts live placed structures by that cached candidate id
  - the checked-in consumer side is tighter too:
    `0x0040dc40` already consumes live owner company `[site+0x276]`, company stat-family
    `0x2329/0x0d`, candidate field `[candidate+0x22]`, and the projected-cell validation strip
    `0x00417840 -> 0x004197e0`, then commits the linked-site mutation through
    `0x0040d1f0 / 0x00480710 / 0x0045b160 / 0x0045b9b0 / 0x00418be0 / 0x0040cd70`
  - the periodic-company trace now carries the tri-lane live-service family as structured fields,
    not just prose:
    - site cached tri-lane status =
      `live_writer_family_grounded_semantics_and_persisted_inputs_missing`
    - tri-lane live service status =
      `candidate_gate_and_live_writer_family_grounded_exact_formula_and_persisted_inputs_missing`
    - tri-lane live owners include:
      `0x0040d450`, `0x00410b30..0x004118f4`, `0x00412560`, `0x0040c9a0`,
      and the downstream `0x0040fcc0..0x0040fe28 / 0x00422c62..0x00422d3c` consumers
    - tri-lane gate fields include:
      candidate-row fields `+0x20/+0x22/+0x24/+0x28/+0x2c/+0x44`,
      world date/flags via `0x006cec78`,
      candidate table `0x0062ba8c`,
      and caller-provided subject vtable slot `+0x80` plus owner-present flag `[site+0x246]`
    - tri-lane writer roles are now split explicitly between:
      one owner-company-aware local scorer `0x0040d450`,
      the broader `0x00410b30..0x004118f4` candidate loop,
      and the later `0x0040c9a0` accumulator/reset
    - direct caller families are now split explicitly too:
      `0x0040fb70` is the small wrapper into `0x00412560`,
      `0x004b4052 / 0x004b46ec` are collection-wide `0x0040fb70` census callers over
      `0x0062b26c`,
      `0x00401633` is an acquisition-adjacent `0x0040d540` caller that immediately feeds company
      stat-family `0x2329/0x0d`,
      `0x0044b81a` is an owner-company-aware `0x0040d540` caller that also reaches
      `0x0040cb70` and news/event id `0x65`,
      and `0x004b70f5 / 0x004b7979` are broader sibling `0x0040d540` callers routing through
      `0x004337a0` and downstream `0x00540120 / 0x00518140`
    - formula input lanes are now structured too:
      `0x00412560` uses candidate-row time window `+0x20/+0x22`,
      owner/absence booleans `+0x24/+0x28`,
      list count `+0x2c`,
      and membership list `+0x44`,
      while the wider `0x00410b30..0x004118f4` loop consumes candidate-row
      `+0x18/+0x1c/+0x2a/+0x2c/+0x44`,
      subject latch `[site+0x78c]`,
      personality byte `[site+0x391]`,
      world lanes `[world+0x0d]`, `[world+0x4afb]`, `[world+0x4caa]`,
      owner-company scalar `[company+0x0d5d]`,
      and the local cache bands `[site+0x2e8]`, `[site+0x310]`, `[site+0x338]`, `[site+0x360]`
  - the direct writer census now narrows the remaining owner-company question too:
    grounded `[site+0x276]` writes cluster under create-side and live mutation families such as
    `0x004269b0 / 0x00426a10`, the create-side `0x0040ef10 / 0x0040f6d0` strip, and the bulk
    reassignment families `0x00426dce..0x00426ea1` and `0x00430040..0x004300d6`, not under the
    known `0x00444690 -> 0x004133b0 -> 0x0040ee10` replay strip
  - the same write side is now grounded one level higher too:
    direct local control-flow reconstruction shows those families hanging under the grouped opcode
    dispatcher `0x00431b20` over `0x0061039c`, with opcodes `0x04..0x07` dispatching to
    `0x00430040`, opcodes `0x08/0x10..0x13` dispatching to `0x00426d60`, and opcodes
    `0x0d/0x16` dispatching to `0x0042fc90`
  - `0x0042fc90` itself is now ruled onto the live mutation side too:
    it iterates the live placed-structure collection `0x0062b26c`, filters rows through
    `0x0040c990`, optional owner-company match `[site+0x276]`, and row vtable slot `+0x70`,
    which keeps that branch on the live application side rather than replay
  - the focused save-side triplet probe is now available directly too:
    `runtime inspect-save-placed-structure-triplets <save.gms>` dumps the grounded
    `0x36b1/0x55f1/0x55f2/0x55f3` rows without the wider periodic trace wrapper
  - real-save output from that focused probe rules the checked-in triplet seam down further:
    on grounded `p.gms`, all 2026 rows keep policy trailing word `0x0101`, the profile side is
    dominated by companion byte `0x00` with status `unset` (`1885` rows) plus farm-growth buckets
    (`138` rows), and the only nonzero companion-byte residue is `3` `TextileMill` rows
  - the create-side family is grounded separately too:
    city-connection direct placement already reaches
    `0x00402cb0 -> 0x00403ed5/0x0040446b -> 0x004134d0 -> 0x0040ef10`
    as the shared constructor/finalize strip for newly created site rows
  - so the acquisition blocker is no longer “is there any real consumer family above these
    lanes?”, “how do new placed structures finalize?”, “is `[site+0x2a4]` still missing?”, or
    “does the tri-lane even have live writers?”; it is now specifically the persisted inputs and
    exact shellless service semantics above the grounded live tri-lane scorer family, plus the
    save-native or replay owner that populates `[site+0x276]` for already-restored rows before
    shellless acquisition runs
  - direct disassembly now shows the generic base constructor `0x0052edf0` clearing base state
    through `0x0052ecd0` and then writing `[this+0x04]` from caller arg `1`
  - `0x00455b70` is the concrete placed-structure specialization constructor feeding
    `0x0052edf0`, with arg `3` as the primary selector and arg `1` as fallback
  - `0x00455c62` is the direct in-body call from that specialization constructor into
    `0x0052edf0`
  - `0x00456100` is a local wrapper that duplicates its first incoming arg across the
    selector/fallback bundle before calling `0x00455b70`
  - `0x00456072` is a fixed `0x55f2` callback that forwards three local dwords plus unit scalars
    into `0x00455b70`
  - `0x0045c36e / 0x0045da65 / 0x0045e0fc` are concrete callers of `0x00456100`, repeatedly
    allocating `0x23a` rows, forwarding stack-backed buffers, and using the same default scalar
    lanes
  - the `0x00456100 -> 0x00455b70` wrapper mapping is now grounded far enough to say the sampled
    selector-source lanes are `[owner+0x23e]` at `0x0045c36e`, literal zero at `0x0045da65`, and
    `[ebp+0x08]` at `0x0045e0fc`
  - direct disassembly now shows `0x0045c150` as a save-backed loader for `[owner+0x23e/+0x242]`:
    it zeroes those fields, runs the shared tagged loader `0x00455fc0`, reads tagged payload
    `0x5dc1`, and copies the two recovered lanes into `[owner+0x23e/+0x242]` before
    `0x0045c310 -> 0x0045c36e` later feeds `[owner+0x23e]` into `0x00456100`
  - the local linked-site helper neighborhood now reaches that same owner strip directly:
    `0x0040ceab` calls `0x0045c150`, and `0x0040d1a1` jumps straight into `0x0045c310`
  - `0x00485819` is one typed placed-structure caller of `0x0052edf0` through the generic
    three-arg wrapper `0x00530640`
  - `0x00490a79` is one chooser-side caller of `0x00455b70`, feeding literal selector
    `0x005cfd74` with fallback seed `0x005c87a8`
  - the periodic-company trace now also surfaces the save-side `0x5dc1` payload/status summaries
    already parsed from the `0x36b1` triplet seam; on grounded `p.gms` the payload dword lane is
    almost entirely unique while the status kind stays `unset`, and the dominant adjacent payload
    delta is `0x00000780` across `1908` steps; grounded `q.gms` shows the same dominant adjacent
    delta `0x00000780` across `1868` steps
  - the same trace now also promotes the one-byte `0x5dc1` post-secondary discriminator explicitly:
    grounded
    `p.gms` shows dominant companion byte `0x00` on `2023` rows with only `3` `0x01` rows, and
    grounded `q.gms` shows dominant companion byte `0x00` on `2043` rows with only `14` `0x01`
    rows; the old “pre-footer padding” hypothesis is now better understood as a separate
    post-secondary discriminator byte after the repeated secondary payload string, not as the
    `[owner+0x242]` field itself
  So the next owner question is no longer “what does the acquisition branch do?” or “which post-
  load owner replays linked-site refresh?” but “which concrete `0x00455b70` caller family applies
  to the live site rows, and which persisted lane becomes the selector bundle that ultimately
  seeds `[site+0x04]`?” The current strongest restore-family hypothesis is now the save-backed
  `0x0045c150 -> 0x0045c310 -> 0x0045c36e -> 0x00456100 -> 0x00455b70` strip.
- Make the next static/rehost slice the peer-site rebuild seam above persistence, not another save
  scan:
  - treat `0x00444690 -> 0x004133b0 -> 0x0040e450 / 0x0040ee10 -> 0x0040edf6 -> 0x00480710` as
    the checked-in bring-up replay path for existing saves
  - treat `0x004160aa -> 0x0040ee10` as the checked-in recurring runtime maintenance entry into the
    same linked-peer refresh strip
  - treat `0x0052edf0` as the checked-in field owner for `[site+0x04]`
  - treat `0x00455b70` as the checked-in specialization constructor that maps selector/fallback
    bundle lanes into that field owner
  - distinguish which `0x00455b70` caller family actually seeds the live site rows before
    `0x00420030 / 0x00420280 / 0x0047efe0 / 0x0047fd50` consume the resulting selector, with the
    current first target being the save-backed
    `0x0045c150 -> 0x0045c310 -> 0x0045c36e -> 0x00456100` family
  - use the structured periodic-company trace selector fields now checked into
    `inspect-periodic-company-service-trace`: owner strip
    `0x0045c150 -> 0x0045c310 -> 0x0045c36e -> 0x00456100 -> 0x00455b70`, persisted tag
    `0x5dc1`, selector lane `[owner+0x23e]`, class-identity status
    `grounded_direct_local_helper_strip`, and helper linkage
    `0x0040ceab -> 0x0045c150` / `0x0040d1a1 -> 0x0045c310` /
    `0x0040cd70 seeds [site+0x3cc/+0x3d0] from 0x62b2fc / 0x62b268`
  - use the new `0x5dc1` payload/status summary in the same trace as negative evidence too:
    the current `profile_payload_dword` lane behaves like a save-invariant monotone ladder
    (`dominant adjacent delta 0x780` on both `p.gms` and `q.gms`) rather than a compact selector
    family, so the next peer-site slice should treat that raw dword as a likely allocator/offset
    lane until a stronger selector interpretation appears
  - use the new `0x5dc1` post-secondary-byte summary in the same trace as positive evidence:
    that byte is overwhelmingly `0x00` with a tiny `0x01` residue on both grounded saves, so the
    next peer-site slice should treat it as a real typed discriminator after the restored
    `[owner+0x23e]` / `[owner+0x242]` payload strings and ask which later `0x004014b0` /
    `0x00406050` predicates actually consume it
  - use the new nonzero-companion name-pair summary in the same trace as a narrower acquisition
    clue too: grounded `p.gms` exposes only `TextileMill/TextileMill x3`, while grounded `q.gms`
    exposes `TextileMill x9`, `Toolndie x2`, and singleton `Brewery`, `MeatPackingPlant`, and
    `MunitionsFactory` rows, so the next peer-site slice should treat nonzero post-secondary-byte
    rows as a likely industry-like subset rather than a generic placed-structure mode split
  - keep the already-grounded `0x0047fd50` class gate separate from that byte: direct disassembly
    now says `0x0047fd50` resolves the linked peer through `[site+0x04]`, reads candidate class
    byte `[candidate+0x8c]`, and returns true only for `0/1/2` while rejecting `3/4` and above,
    so the next slice should not conflate the post-secondary byte with the existing
    station-or-transit gate
  - treat the peer-site selector seam itself as grounded enough for planning purposes
  - use the new structured restore/runtime field split in the same trace:
    restore subset
    `[site+0x3cc/+0x3d0]` plus `0x5dc1`-backed `[owner+0x23e/+0x242]`,
    and runtime subset
    `[site+0x04]`, `[site+0x2a8]`, `[peer+0x08]`
  - use the new structured reconstruction status in the same trace:
    `restore_subset_and_bring_up_reconstruct_runtime_subset`
  - treat the runtime subset as reconstructible from the restore subset plus the already-grounded
    bring-up path for planning purposes
  - use the new structured acquisition input families in the same trace:
    region subset
    `[region+0x276]`, region vtable `+0x80` byte-`0x32`, `[region+0x3d5]`,
    `[region+0x310/+0x338/+0x360]`, `[region+0x2a4]`;
    peer subset
    center-cell token gate, `[site+0x04]`, `[site+0x2a8]`, `[peer+0x08]`, linked-region status;
    company subset
    stat-family reader `0x2329/0x0d`, chairman byte `[profile+0x291]`, company byte `[company+0x5b]`
    plus indexed lane `[company+0x67 + 12*0x0042a0e0()]`, and the company-root argument passed into
    `0x0040d540 / 0x00455f60`
  - use the new shellless-readiness split in the same trace:
    runtime-backed families
    peer-site restore subset plus bring-up reconstruction, company stat-family `0x2329/0x0d`,
    chairman byte `[profile+0x291]`, and save-native company/chairman identity;
    remaining owner gaps
    `[region+0x276]`, `[region+0x2a4]`, `[region+0x310/+0x338/+0x360]`, and the stable region
    class/type discriminator consumed through `0x0040d360`
  - use the new per-lane region status split in the same trace:
    `[region+0x276]` already has a grounded runtime producer at `0x00422100` and is now only an
    ordinary-save restore gap;
    `[region+0x2a4]` currently has no region-class runtime writer in the binary scan and now looks
    payload/restore-owned;
    `[region+0x310/+0x338/+0x360]` has an exact raw delta reader at `0x0040cac0` and likewise no
    direct region-class runtime writer in the current binary scan, so it now also looks
    payload/restore-owned;
    `0x0040d360` is now exact as `[owner_vtable+0x80+0x32] == 4`, so the remaining gap there is
    only the save-native projection of that byte
  - make the next periodic-company slice about the smaller shellless-simulation question instead:
    which later save payload or restore owner rehydrates the remaining region-side `0x004014b0`
    inputs `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]` once the peer/company inputs are
    treated as grounded and `[region+0x276]` is treated as a producer-known ordinary-save restore
    gap
- Use the higher-layer probes as the standard entry point for the current blocked frontier instead
  of generic save scans:
  `runtime inspect-periodic-company-service-trace <save.gms>`,
  `runtime inspect-region-service-trace <save.gms>`, and
  `runtime inspect-infrastructure-asset-trace <save.gms>`.
- Follow the new higher-layer probe outputs instead of another blind save scan:
  `runtime inspect-infrastructure-asset-trace <save.gms>` now shows that the `0x38a5`
  infrastructure-asset seam is grounded and the old alias hypothesis is disproved on `q.gms`, so
  the next placed-structure slice should target the consumer mapping above that seam rather than
  more collection discovery; the same trace now also carries atlas-backed candidate consumers
  (`0x0048a1e0`, `0x0048dd50`, `0x00490a3c`, `0x004559d0`, `0x00455870`, `0x00455930`,
  `0x00448a70/0x00493660/0x0048b660`, `0x004133b0`) plus bridge/tunnel/track-cap name-family
  counts, so the next pass can start at those concrete owners instead of the whole
  placed-structure family.
- Rehost or bound the next concrete `Infrastructure` consumer above `0x38a5` instead of treating
  “consumer mapping missing” as a stop: start with the checked-in candidate strip
  `0x0048a1e0`, `0x0048dd50`, `0x00490a3c`, `0x004559d0`, `0x00455870`, `0x00455930`,
  `0x00448a70/0x00493660/0x0048b660`, `0x004133b0`, and narrow that list to the first true
  shellless owner that consumes the side-buffer seam. The infrastructure trace now ranks the
  current best hypothesis as the child attach/rebuild strip
  (`0x0048a1e0`, `0x0048dd50`, `0x00490a3c`), with the serializer/load companions next and the
  route/local-runtime follow-on family explicitly secondary.
- For that top-ranked infrastructure strip, treat the next pass as three exact owner questions
  rather than a general “map the consumer” task: whether the `0x38a5` compact-prefix/name-pair
  groups feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only a
  later route/local-runtime refresh lane; which child fields or grouped rows absorb the
  side-buffer payload before `0x00448a70/0x00493660/0x0048b660` become relevant; and, now that the
  direct route-entry bridge helpers over `[this+0x206/+0x20a/+0x20e]` are grounded, which later
  route/local-runtime owner still carries the remaining mixed exact classes once cached
  primary-child slot `[this+0x248]` is demoted to child-list cache/cleanup state.
- Targeted disassembly now tightens that strip further: `0x0048a1e0` clones the first child through
  `0x0052e880/0x0052e720`, destroys the prior child, seeds a literal `Infrastructure` child
  through `0x00455b70` with payload seed `0x005c87a8`, and republishes the two sampled bands
  through `0x0052e8b0/0x00530720` after attaching through `0x005395d0`; the non-clone branch
  attaches through `0x0053a5d0`. So the next unknown is no longer whether this strip owns the
  child/rebuild seam, but which `0x38a5` compact-prefix groups drive the clone-vs-payload choice.
- The outer rebuild owner is tighter now too: `0x0048dcf0` reads a child count plus optional
  primary-child ordinal from the tagged stream through `0x00531150`, zeroes `[this+0x08]`,
  dispatches each fresh child through `0x00455a50 -> vtable slot +0x40`, culls ordinals above `5`,
  and restores cached primary-child slot `[this+0x248]` from the saved ordinal. That means the
  child/rebuild loop is consuming an already-materialized child stream rather than parsing the
  `0x38a5` compact-prefix seam directly.
- The upstream handoff is grounded now too: `0x00493be0` is the tagged collection load owner over
  `0x38a5/0x38a6/0x38a7`, and it feeds each live infrastructure record straight into
  `0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. So the
  remaining infrastructure question is no longer whether `0x38a5` reaches the child-stream restore
  path at all. Direct disassembly now also shows `0x00518140` resolving a non-direct live entry by
  tombstone bitset and then returning the first dword of a `12`-byte row from `[collection+0x3c]`,
  while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating, and
  `0x00493be0` itself now reads as an ordinal-to-live-id-to-payload-pointer walk through
  `0x00518380(ordinal, 0)` then `0x00518140(live_id)`. So the next infrastructure question is no
  longer “which row owns the payload pointer?”. Direct disassembly of `0x005181f0/0x00518260` now
  also treats those `12`-byte rows as a live-entry directory with
  `(payload pointer, previous live id, next live id)`, so the next infrastructure question is only
  how those payload streams align with the embedded `0x55f1` name-pair groups and compact-prefix
  regimes, and which tagged values inside each payload stream become the child count, optional
  primary-child ordinal, and per-child callback sequence that `0x0048dcf0` consumes. Direct
  disassembly now also shows the shared child payload callback `0x00455fc0` opening
  `0x55f1 -> 0x55f2 -> 0x55f3`, parsing three `0x55f1` strings through `0x00531380`, seeding the
  child through `0x00455b70`, and then dispatching slot `+0x48`; the widened save-side probe
  currently sees `0` third `0x55f1` strings on grounded `q.gms`. That now looks less like a probe
  failure and more like an ordinary fallback path, because direct disassembly of `0x00455b70`
  stores the three payload strings into `[this+0x206/+0x20a/+0x20e]`, defaulting the second lane
  through a fixed literal when absent and defaulting the third lane back to the first string when
  absent. So the next pass should stay focused on payload-stream grouping and tagged value roles,
  not on rediscovering a missing third-string encoding.
- The child loader identity is tighter now too: local `.rdata` at `0x005cfd00` proves the
  `Infrastructure` child vtable uses the shared tagged callback strip directly, with
  `+0x40 = 0x00455fc0`, `+0x44 = 0x004559d0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`.
  Direct disassembly of `0x004559d0` then shows the concrete write-side chain for the child
  payload: write `0x55f1`, serialize string lanes `[this+0x206/+0x20a/+0x20e]`, write `0x55f2`,
  dispatch slot `+0x4c`, run `0x0052ec50`, and close `0x55f3`. So the remaining infrastructure
  frontier is no longer “which slot does `0x00455a40` jump to?”; it is which chooser/seed values
  reach those string lanes and the trailing footer path.
- That source side is narrower now too: direct disassembly shows the paired chooser siblings
  calling `0x00490960` directly beside `0x0048a340/0x0048f4c0/0x00490200`, and `0x00490960`
  copies selector fields into the child object (`[this+0x219]`, `[this+0x251]`, bit `0x20` in
  `[this+0x24c]`, and `[this+0x226]`), allocates a fresh `0x23a` `Infrastructure` child, seeds it
  through `0x00455b70` with caller-supplied stem input plus fixed literal `Infrastructure` at
  `0x005cfd74`, attaches it through `0x005395d0`, seeds position lanes through
  `0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The remaining
  problem is no longer “where do the child payload lanes come from?” but “which chooser branches
  feed `0x00490960` which caller stem and selector tuple for each grounded save-side class?”.
- One direct branch is grounded now too: the repeated chooser calls at
  `0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
  `0x005cb138 = BallastCapDT_Cap.3dp`, which means they bypass the selector-copy block at
  `0x004909e2` and go straight into fresh child allocation/seeding. So the remaining source-side
  mapping problem is no longer generic BallastCap coverage; it is the other constructor branches,
  especially the ones with mode `< 4` that actually populate the selector-byte copy block.
- The broader mode family is grounded now too. A wider static callsite sweep shows:
  - mode `0x0b` with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`
  - mode `0x03` with `OverpassST_section.3dp`
  - mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks
  - mode `0x01` with decoded bridge table stems plus zero-stem fallbacks

  The current grounded `q.gms` name corpus now also maps directly onto most of those families:
  `BridgeSTWood_Section.3dp -> mode 0x01`, `TunnelSTBrick_* -> mode 0x02`,
  `BallastCapST_Cap.3dp -> mode 0x0a`, and `TrackCapST_Cap.3dp -> mode 0x0b`, with only
  `Overpass` still static-only in the current save corpus.

  So the remaining infrastructure question is no longer “what does `0x00490960` build?” or even
  “which family is this name row?” but “how do the surviving compact-prefix regimes subdivide
  those already-mapped families, especially inside bridge mode `0x01` and track-cap mode `0x0b`?”.
- The direct route-side bridge is grounded now too: `0x0048e140/0x0048e160/0x0048e180` simply
  resolve `[this+0x206/+0x20a/+0x20e]` through live route collection `0x006cfca8`, and
  `0x0048e1a0` compares those resolved peers against `[this+0x202]`. The neighboring
  `0x0048ed30` path is now also narrower: it only tears down child list `[this+0x08]`, clearing
  cached primary-child slot `[this+0x248]` when needed, so `[this+0x248]` is no longer the first
  route bridge to chase.
- The later route/local-runtime follow-on family is tighter now too: `0x00448a70` is a
  world-overlay helper over `[world+0x15e1/+0x162d]`, `0x00493660` is a counter-plus-companion-
  region follow-on keyed by `[child+0x218]`, `[child+0x226]`, `[child+0x44]`, and `0x0048dcb0`,
  `0x0048b660` is a presentation-color/style owner over `[child+0x216/+0x218/+0x226/+0x44]` and
  bit `0x40` in `[child+0x201]`, and `0x0048e2c0/0x0048e330/0x0048e3c0` now read as flag / route-
  tracker / region-test helpers rather than hidden payload decoders. So the next infrastructure
  slice should stay focused on the remaining mixed exact compact-prefix classes and earlier
  child-stream semantics, not on rediscovering the already-bounded presentation owners.
- The new probe correlation now makes that residual even more concrete: on grounded `q.gms`, the
  dominant mixed `0x0001/0xff` class splits as `bridge:62 / track_cap:21 / tunnel:19`, while the
  pure `0x0002/0xff` class is all bridge and the pure `0x0055/0x00` class is all ballast-cap.
  So the next infrastructure slice should focus on subdividing the mixed one-child `0x0001/0xff`
  class rather than revisiting the already-grounded pure classes.
- The sibling `0x00490200` is tighter now too: it reads the seeded lanes
  `[this+0x206/+0x20a/+0x20e]` back through the live route collection at `0x006cfca8`, compares
  them against the current owner using `[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a
  route/link comparator layered above the same child payload lanes that `0x004559d0` later
  serializes. So the next infrastructure pass should treat `0x00490960` as the source owner and
  `0x00490200` as a consumer of the same seeded lanes, not as separate unexplained seams.
- The smaller helper `0x00490a3c` is narrower now too: it allocates one literal `Infrastructure`
  child, seeds it through `0x00455b70` with caller-provided stem input, attaches it through
  `0x005395d0`, seeds position lanes through `0x00539530/0x0053a5b0`, and optionally caches it as
  the primary child. So the next concrete infrastructure question is which upstream owner
  maps the direct `0x38a5` rows into the child count, primary-child ordinal, and per-child payload
  callbacks consumed by `0x0048dcf0`, and which restored child fields still retain those embedded
  name-pair semantics before route/local-runtime follow-ons take over.
- The save-side `0x38a5` probe is now tighter at the payload-envelope level too: grounded
  `q.gms` shows all `138` embedded `0x55f1` rows already live inside complete
  `0x55f1 -> 0x55f2 -> 0x55f3` envelopes before the next name row, every embedded `0x55f2` chunk
  is the fixed `0x1a` bytes that `0x00455fc0` expects, and the dominant embedded `0x55f3`
  payload-to-next-name span is the short `0x06`-byte form across `72` rows. So the next
  infrastructure pass should stop asking whether the shared tagged callback sequence is present at
  all and instead decode the short `0x55f3` payload role and its relation to the compact-prefix
  regimes and primary-child restore path.
- That short trailing lane is tighter now too: direct disassembly of `0x0052ebd0/0x0052ec50`
  shows the post-`+0x48` helper pair loading and serializing two single-byte lanes that fold into
  bits `0x20` and `0x40` of `[this+0x20]`, and the save-side probe now shows the dominant
  `0x06`-byte rows all carrying the same grounded flag pair `0x00/0x00` on `q.gms`. So the next
  concrete infrastructure question is no longer “is there a short trailing flag lane?”; it is how
  the compact-prefix regimes and those flag-byte pairs feed the child-count / primary-child restore
  state above `0x0048dcf0`.
- The fixed `0x55f2` lane is tighter now too: direct disassembly of `0x00455870/0x00455930` shows
  the `+0x48/+0x4c` strip loading and serializing six `u32` lanes from the fixed `0x1a` chunk,
  forwarding them through `0x00530720` and `0x0052e8b0`. Grounded `q.gms` probes now show every
  embedded `0x55f2` row using the same trailing word `0x0101` while those six dword lanes vary by
  asset row. So the next infrastructure question is no longer whether `0x55f2` is a fixed-format
  child lane; it is which of those two dword triplets correspond to child-count / primary-child
  restore state and which only seed published anchor or position bands.
- That split is tighter now too: direct disassembly of `0x00530720/0x0052e8b0` shows the first
  fixed `0x55f2` triplet landing in `[this+0x1e2/+0x1e6/+0x1ea]` and the second in
  `[this+0x4b/+0x4f/+0x53]`, with the companion setter also forcing bit `0x02`. So the next
  infrastructure question is no longer whether the fixed `0x55f2` row hides the child count or
  primary-child ordinal at all; those outer-header values now have to live outside the fixed row,
  most likely in the surrounding payload-stream header or compact-prefix regime above
  `0x0048dcf0`.
- The outer prelude itself is tighter now too: direct disassembly of `0x0048dcf0` shows it reading
  one `u16` child count through `0x00531150`, zeroing `[this+0x08]`, and conditionally reading one
  saved primary-child byte before the per-child callback loop runs. Grounded `q.gms` bytes now also
  show the first `0x38a6` record starting immediately after the shared owner-local dword with
  `child_count = 1`, `saved_primary_child_byte = 0xff`, and the first child `0x55f1` opening at
  offset `+0x3`. So the next infrastructure question is no longer “what kind of values are we
  looking for above the fixed rows?”; it is the narrower partitioning problem of how the observed
  `0x55f3`-to-next-`0x55f1` gaps divide between the two `0x52ebd0` flag bytes and the next
  record’s `u16 + byte` prelude.
- The widened prelude correlation closes part of that partitioning too: grounded `q.gms` rows with
  a `0x03` post-profile gap now collapse cleanly to the next-record prelude pattern
  `0x0001 / 0xff` across `17/17` rows, while the zero-length class is a separate grounded outlier
  with dominant pattern `0x0055 / 0x00` across `18/18` rows and the `0x06` class remains the only
  large mixed frontier. So the next infrastructure slice should focus on classifying the mixed
  `0x06` rows, not on rediscovering the already-grounded pure-prelude `0x03` rows.
- That `0x06` class is now narrower too: grounded `q.gms` shows the dominant short-span class as
  `BridgeSTWood_Section.3dp / Infrastructure` with compact prefix `0xff000000 / 0x0001 / 0xff`
  across `62/72` rows and dominant prelude candidate `0x0001 / 0xff` across `63/72` rows. So the
  next infrastructure slice should stop treating the `0x06` class as uniformly ambiguous and focus
  on the smaller outlier families inside that class, especially the zero-like `BallastCap`-style
  rows and any remaining non-`0x0001 / 0xff` prelude candidates.
- The exact compact-prefix classes are explicit across the whole prelude now too:
  `0xff0000ff / 0x0002 / 0xff` is a pure bridge class, `0xff000000 / {0x0001,0x0002} / 0xff`
  are pure bridge classes, `0xf3010100 / 0x0055 / 0x00` is a pure `BallastCap` class, and
  `0x0005d368 / 0x0001 / 0xff` is a pure one-row `TrackCap` class.
- That sharpens the remaining infrastructure unknowns considerably: the only mixed exact
  compact-prefix classes left on grounded `q.gms` are `0x000055f3 / 0x0001 / 0xff` and
  `0xff0000ff / 0x0001 / 0xff`.
- The current `0x000055f3 / 0x0001 / 0xff` class is tunnel-dominant:
  `TunnelSTBrick_Section.3dp / Infrastructure:13`, `TunnelSTBrick_Cap.3dp / Infrastructure:4`,
  `TrackCapST_Cap.3dp / Infrastructure:0` in the exact-prefix correlation, with all `17` rows
  staying on prior profile span `0x03`.
- The current `0xff0000ff / 0x0001 / 0xff` class is `TrackCap`-dominant but still carries `4`
  tunnel rows:
  `TrackCapST_Cap.3dp / Infrastructure:18`,
  `TunnelSTBrick_Cap.3dp / Infrastructure:2`,
  `TunnelSTBrick_Section.3dp / Infrastructure:2`.
  Its rows are spread across many spans rather than one dominant restore span.
- Cross-save `q.gms` / `p.gms` traces sharpen that split further without changing it:
  `0x000055f3 / 0x0001 / 0xff` stays on prelude `0x0001 / 0xff`, fixed short-flag pair
  `0x01 / 0x00`, and fixed prior profile span `0x03` in both saves, while
  `0xff0000ff / 0x0001 / 0xff` stays on prelude `0x0001 / 0xff`, fixed short-flag pair
  `0x00 / 0x00`, and widely scattered prior profile spans in both saves.
- Direct consumers of those footer bits are grounded now too: `0x00528d90` only admits the child
  when the explicit caller override is set, the surrounding global override byte
  `[owner+0x3692]` is set, or bit `0x20` in `[child+0x20]` is set; the sibling loop
  `0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
  set.
- That footer-bit consumer strip is tied to a broader higher-layer owner family now too:
  `0x005295f0..0x005297b7` repopulates candidate cells through `0x00533ba0`, walks candidate
  child lists through `0x00556ef0/0x00556f00`, and honors the same controller mode byte
  `[owner+0x3692]` that the atlas already places under the world-window presentation dispatcher.
- The neighboring helpers tighten that owner family further: atlas-backed `0x00533ba0` is the
  nearby-presentation cell-table helper under the layout/presenter strip, direct disassembly shows
  `0x00548da0` walking layout list root `[layout+0x2593]`, and direct disassembly of `0x0054bab0`
  mutates layout slots `[layout+0x2637/+0x263b/+0x2643]`.
- That means the remaining infrastructure question is no longer both footer bytes. It is
  specifically why the stable `0x000055f3 / 0x0001 / 0xff` tunnel family sets the first footer
  byte / bit-`0x20` admission gate while the sparse `0xff0000ff / 0x0001 / 0xff` outlier class
  clears it, inside that layout/presentation owner family rather than at the serializer layer.
- Source-side constructor analysis is narrower now too. `0x00490960` takes:
  - mode at stack arg 1
  - stem at stack arg 2
  - args 3/4 into `0x539530`
  - arg 5 into `0x53a5b0`
  - arg 10 as the primary-child cache gate for `[this+0x248]`
  - args 7/8/9 into the selector-copy block for `[this+0x219]`, `[this+0x251]`, and bit `0x20`
    in `[this+0x24c]` when `mode < 4`
- That already separates the remaining mixed classes:
  - fixed `TrackCap` mode `0x0b` callers at `0x0048ed01/0x0048ed20` push arg7/arg8/arg9 as
    `-1 / -1 / 0` and bypass selector-copy entirely because `mode >= 4`
  - tunnel mode `0x02` callers at
    `0x004a17eb / 0x004a1995 / 0x004a1b44 / 0x004a1b7d / 0x004a1b95`
    necessarily flow through selector-copy because `mode < 4`, with arg8 fixed at `1`, arg9
    fixed at `0`, and only arg7 varying through a branch-local one-bit register
- So the next infrastructure slice should stop treating the remaining frontier as a generic
  “mixed 0x06/outlier” problem and instead target the owning constructor/restore semantics for
  those two exact mixed compact-prefix classes, especially how tunnel arg7 and the fixed
  `TrackCap` no-selector bundle both still collapse into the observed mixed save-side prefixes.
- The candidate-pattern classes are now explicit across the whole stream too: `0x0055 / 0x00`
  is a pure `BallastCapST_Cap.3dp / Infrastructure` class across `18` rows, always preceded by a
  zero-length prior profile span, while `0x0002 / 0xff` is a pure
  `BridgeSTWood_Section.3dp / Infrastructure` class across `18` rows with dominant prior profile
  span `0x06` (`10` rows). So the next infrastructure pass should split its owner questions:
  treat `0x0055 / 0x00` as a `BallastCap`-specific boundary artifact class, and treat
  `0x0002 / 0xff` as the grounded save-side bridge-specific two-child candidate class above
  `0x0048a1e0/0x0048dcf0`, with the remaining unknown narrowed to the upstream chooser that emits
  that class before the attach/rebuild path runs.
- That upstream chooser is grounded now too as paired siblings: direct disassembly shows
  `0x004a2c80` routing the `DT` family and `0x004a34e0` routing the `ST` family, with both
  repeatedly calling `0x0048a1e0`, branching on `[this+0x226]`, selector bytes
  `[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and lookup tables `0x621a44..0x621a9c`,
  then routing follow-on through `0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining
  infrastructure question is no longer “is there an upstream chooser?” but “how do the save-side
  classes select the `DT` versus `ST` chooser sibling, and then which lookup-table families inside
  that sibling map to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00`
  BallastCap class?”.
- Those lookup tables are decoded now too: `0x621a44/0x621a54` feed `BridgeST` caps/sections,
  `0x621a64` feeds `TunnelST` cap/section variants, `0x621a74/0x621a84` feed `BridgeDT`
  caps/sections, and `0x621a94` feeds `TunnelDT` variants, while fixed literals
  `0x5cb138/0x5cb150` are `BallastCapDT/ST` and `0x5cb168/0x5cb180` are `OverpassDT/ST`. So the
  remaining infrastructure question is no longer table discovery; it is the selector-byte mapping
  from `[this+0x219]/[this+0x251]/[this+0x252]` onto those decoded families and then onto the
  grounded `0x38a5` prefix classes.
- The top-level chooser meaning is grounded now too: within those paired DT/ST siblings,
  `[this+0x226]==1` routes the bridge families, `[this+0x226]==2` routes the tunnel families, and
  `[this+0x226]==3` routes the overpass/ballast family, while bit `0x20` in `[this+0x24c]`
  selects the cap-oriented side over the section-oriented side. So the remaining infrastructure
  selector problem is below that top-level split: the exact `[this+0x219]/[this+0x251]` values
  that choose the decoded family entries and how those values surface in the save-side `0x38a5`
  classes.
- Those material selectors are grounded now too: within the bridge branch, `[this+0x219]`
  selects `steel`, `stone`, `suspension`, or `wood`, with value `2` taking the special
  suspension-cap path through `[this+0x252]`; within the tunnel branch, `[this+0x251]` selects
  `brick` versus `concrete`, while bit `0x20` chooses cap versus section by switching between the
  base and `+0x8` table entry families. So the remaining infrastructure selector problem is no
  longer “what do these bytes mean?” but “how do those already-grounded selector values surface in
  the save-side `0x38a5` classes, especially the `0x0002 / 0xff` bridge class and the
  `0x0055 / 0x00` BallastCap class?”.
- The exact setter seam is grounded now too: direct disassembly of `0x0048a340` shows its dword
  argument writing `[this+0x226]`, its next two byte arguments writing `[this+0x219]` and
  `[this+0x251]`, and its final byte argument toggling bit `0x20` in `[this+0x24c]`. So the
  remaining infrastructure selector problem is no longer about hidden intermediate state; it is
  specifically how those already-grounded setter values are serialized or rebuilt into the
  save-side `0x38a5` prefix classes.
- One selector byte is partly grounded now too: when `[this+0x219]==2`, the chooser jump tables
  stop using the general bridge families and instead route `[this+0x252]` through fixed
  `BridgeDT/BridgeST` suspension-cap literals for `R10`, `L10`, `12`, `14`, `16`, and `18`.
  So the remaining infrastructure selector problem is mostly `[this+0x219]/[this+0x251]` family
  choice plus the exact save-side class mapping for the BallastCap branch.
- The current real-save corpus also narrows the active side further: grounded `q.gms`, `p.gms`,
  `g.gms`, and `nom.gms` only expose `ST`-family side-buffer names, while classic `rt3/` saves in
  this workspace currently expose no `0x38a5` side-buffer seam at all. So the save-driven part of
  the next infrastructure slice should assume it is exercising the `ST` chooser sibling directly,
  with `DT` still grounded statically but not yet exercised by the current save corpus.
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
  region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
  `0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded
  real saves: the remaining blocker is no longer a hidden trailing payload tail, but finding the
  separate save-owner seam for the pending bonus lane `[region+0x276]`, completion latch
  `[region+0x302]`, one-shot notice latch `[region+0x316]`, severity/source lane `[region+0x25e]`,
  and any stable region-id or class discriminator that can drive shellless city-connection
  service. The newly grounded queue-node probe for the atlas-backed kind-`7` notice records is a
  negative result on `q.gms`, `p.gms`, and `Autosave.gms`, so the next region pass should not
  assume that the transient `[world+0x66a6]` queue family is persisted in ordinary saves; the
  region trace now also carries the concrete queued/service owners (`0x00422100`, `0x004337c0`,
  `0x00437c00`, `0x004c7520`, `0x004358d0`, `0x00438710`, `0x00420030/0x00420280`,
  `0x0047efe0`) so the next pass can focus on the missing saved latches and stable region id/class
  rather than on rediscovering the outer service family.
- Rehost or bound the next concrete region owner above the missing latches instead of treating the
  absent persisted queue as a stop: start with the checked-in owner strip `0x00422100`,
  `0x004337c0`, `0x00437c00`, `0x004c7520`, `0x004358d0`, `0x00438710`,
  `0x00420030/0x00420280`, `0x0047efe0`, and reduce it to the first true save-owned or rebuild
  owner that can explain `[region+0x25e/+0x276/+0x302/+0x316]` plus a stable region id/class. The
  region trace now ranks the current best hypothesis as the pending bonus service owner
  (`0x004358d0`) plus the peer/linkage strip (`0x00420030/0x00420280`, `0x0047efe0`), with the
  transient producer/queue family explicitly secondary and the queued kind-`7` modal dispatch kept
  as shell-adjacent reference only.
- For that top-ranked region strip, treat the next pass as three exact owner questions too: which
  restore seam re-seeds `[region+0x25e]` and clears `[region+0x302/+0x316]` before the grounded
  `0x00422100 -> 0x004358d0` producer/consumer cycle runs again, which stable region id or class
  discriminator survives save/load strongly enough to drive `0x004358d0`, and how far the grounded city-connection peer/linkage helpers
  (`0x00420030/0x00420280`, `0x0047efe0`) can be reused directly before the transient queued-notice
  family matters again.
- Targeted disassembly now tightens that strip too: `0x004358d0` calls `0x00420030` twice plus
  `0x00420280`, then resolves the linked company through `0x0047efe0`, posts company stat slot `4`
  on success, and stamps `[region+0x302]` or `[region+0x316]` while clearing `[region+0x276]`.
  `0x00420030` itself now reads as the real peer gate over collection `0x006cec20`, combining
  `0x0042b2d0`, the optional company filter through `0x0047efe0`, the station-or-transit gate
  `0x0047fd50`, and the status branch `0x0047de00 -> 0x0040c990`; `0x00420280` is the same scan
  returning the first matching site id. So the remaining unknown is the persisted latch/id seam,
  not the live peer/service logic.
- The producer half is grounded now too: `0x00422100` filters for class-`0` regions with
  `[region+0x276]==0` and `[region+0x302]==0`, rejects already-connected pairs through
  `0x00420030(1,1,0,0)`, chooses one eligible candidate, buckets severity/source lane
  `[region+0x25e]` against the three checked thresholds, writes the resulting amount to
  `[region+0x276]`, and appends the kind-`7` queued notice through `0x004337c0`. That means the
  remaining region gap is now explicitly the upstream restore seam for `[region+0x25e]` and the
  completion/fallback latch clear, not either side of the producer/consumer service pair.
- The severity/source lane itself is narrower now too: `0x004cc930` is a selected-region editor
  helper that writes `[region+0x25a]` and `[region+0x25e]` together from one integer input, while
  `0x00438150` and `0x00442cc0` are fixed-region global reseed/clamp owners over collection
  `0x0062bae0` that adjust the same mirrored pair for hardcoded region ids. So the remaining
  region restore question is no longer “what does `[region+0x25e]` mean?” but “which load/reseed
  seam restores the mirrored severity pair before the producer runs?”
- Two more direct-hit writer bands are now explicitly ruled out too: `0x0043a5a0` is a separate
  constructor under vtable root `0x005ca078` that zeroes its own `[this+0x302/+0x316]` fields
  during local object setup, and `0x0045c460/0x0045c8xx` is a separate vtable-`0x005cb5e8` helper
  family whose `[this+0x316]` is a child-array pointer serialized through `0x61a9/0x61aa/0x61ab`.
  So those offset-collision classes should stay out of the remaining region restore search.
- The direct writer census is tighter now too: the other apparent `0x302/0x316` writer bands
  (`0x0043dd45`, `0x0043de19`, `0x0043e0a7`, `0x0043f5bc`) all hang off that same non-region
  `0x005ca078` family through helpers `0x0043af60` and `0x0043b030`. So the only grounded
  region-owned literal writes left are the constructor `0x00421200` plus the producer/consumer
  pair `0x00422100` and `0x004358d0`, which means the remaining region seam should now be treated
  as an indirect restore/rebuild path rather than another direct offset writer hunt.
- The later post-load per-region sweep is narrowed too: in the broader `0x00444887` restore strip,
  the follow-on loop at `0x00444b90` dispatches `0x00420560` over each live region, but that
  helper only zeroes and recomputes `[region+0x312]` from the embedded profile collection
  `[region+0x37f]/[region+0x383]` and lazily seeds the year-driven `[region+0x317/+0x31b]` band
  through `0x00420350`. It still does not touch `[region+0x276/+0x302/+0x316]`, so that whole
  follow-on branch should stay out of the remaining latch-restore search too.
- The checked-in constructor owner `0x00421200`
  `world_region_construct_entry_with_id_class_and_default_marker09_profile_seed` now also grounds
  the initialization side of this family: it clears `[region+0x276]`, `[region+0x302]`,
  `[region+0x316]`, and neighboring cached bands at construction time while seeding
  `[region+0x25a/+0x25e] = 100.0f` and `[region+0x31b] = 1.0f`. That means the remaining queue item
  is specifically post-construction restore or rebuild of the same latches, not their basic field
  identity.
- The next restore-side target is explicit now too: the checked-in function map already grounds
  `0x00421510` as the tagged region-collection load owner that dispatches each live region through
  vtable slot `+0x40`, and `0x0041f5c0` as the per-record load slot that reloads the tagged payload
  through `0x00455fc0` before rebuilding profile collection `[region+0x37f]`. So the next region
  pass should ask whether `[region+0x276/+0x302/+0x316]` are restored directly inside that payload
  load or rebuilt immediately after it, rather than treating “restore seam” as a generic unknown.
- Direct disassembly now closes that callback identity too: `0x0041f590/0x0041f5b0` prove the
  world-region vtable root is `0x005c9a28`, so the `0x00455fc0` dispatch at slot `+0x48` lands on
  `0x00455870` and the serializer sibling at `+0x4c` lands on `0x00455930`. Those two callbacks
  only restore and serialize two helper-local three-lane scalar bands: `0x00455870` reads six
  dwords through `0x00531150` and forwards them to `0x00530720 -> [helper+0x1e2/+0x1e6/+0x1ea]`
  and `0x0052e8b0 -> [helper+0x4b/+0x4f/+0x53]`, while `0x00455930` writes that same pair back
  through `0x00531030`; they still do not touch acquisition-side lanes
  `[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`, and they still do not touch
  `[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later
  owner that rebuilds those latches or the separate tagged body seam that persists them.
- The save-side region payload probe is wider now too: the checked-in `region_record_triplets`
  surface no longer stops at raw pre-name prefix bytes and now also emits structured prefix dword
  candidates per record, and the fixed `0x55f2` policy chunk now also carries structured reserved
  dword candidates instead of raw integers only. That gives the next region payload pass a direct
  way to compare both opaque payload bands against the remaining acquisition-side lane shapes
  instead of redoing raw hex inspection by hand.
- Grounded real-save output now narrows that new probe two steps further: on both `p.gms` and
  `q.gms`, every decoded region triplet currently still has `pre_name_prefix_len = 0`, an empty
  `pre_name_prefix_dword_candidates` vector, and `fixed 0x55f2 policy reserved dwords are nonzero
  on 0 of 145 decoded region records`. So the remaining acquisition-side payload target does not
  appear to live in either the pre-`0x55f1` prefix band or the fixed `0x55f2` reserved dword band
  on grounded ordinary saves. That shifts the next region payload-comparison pass onto later body
  seams, not back onto the prefix or fixed-policy chunk.
- The new fixed-row run candidate probe pushes that same payload search one seam later, but it is
  not grounded yet: on both `p.gms` and `q.gms` it finds high-signal counted runs keyed to the
  live region count `145` with fixed row stride `0x29` before the tagged `0x5209/0x520a/0x520b`
  region collection, yet the top candidate offset is not stable (`p.gms = 0xd13239`,
  `q.gms = 0xd2d7d7`). So the next region payload pass should compare candidate lane-shape
  fingerprints across saves rather than promoting any one absolute pre-header offset as the fixed
  restore seam.
- The new two-save `runtime compare-region-fixed-row-runs <left.gms> <right.gms>` report now does
  that comparison directly. Current result: `p.gms` vs `q.gms` has `0` exact shape overlaps, and
  the only coarse family overlaps are lower-ranked fully mixed candidates where every dword lane is
  still simultaneously small-nonzero and partially-zero. That means the fixed-row scan remains
  useful negative evidence, but it is still not honest to promote as the missing region restore
  seam; the next region pass should stay focused on later restore owners or a more selective row
  family discriminator above this mixed pre-header corpus.
- The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs
  `0x0052ebd0`, which reads two one-byte generic flags through `0x531150` into base object bytes
  `[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and
  `[this+0x3e]`, and then it opens `0x55f3` only for span accounting before returning. So the
  missing region latches are not hiding in the remainder of `0x00455fc0` either.
- The next restore-handoff strip is explicit now too: the region trace now carries a dedicated
  later-global-restore hypothesis for `0x00444887`, because that continuation is the first caller
  checkpoint above the ruled-down `0x00421510 -> 0x0041f5c0 -> 0x00455fc0` path. It immediately
  advances into `0x00487c20` territory refresh and `0x0040b5d0` support refresh, then later
  re-enters the per-region follow-on loop at `0x00444b90 -> 0x00420560`. Current disassembly keeps
  `0x00420560` on the profile/class-mix scalar side only: it recomputes `[region+0x312]` from the
  embedded profile collection and linked placed-structure class mix, then seeds the year-driven
  `[region+0x317/+0x31b]` band through `0x00420350`. So the next region pass should treat the
  broader `0x00444887` continuation as the live handoff seam when chasing
  `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`, not as just another generic restore note.
- That same continuation is slightly less symmetric now too: the atlas-backed territory side at
  `0x00487c20` currently restores only collection metadata/live ids and still uses no-op per-entry
  load/save callbacks `0x00487670/0x00487680`, so the next pass should bias more heavily toward
  support refresh `0x0040b5d0` or the later region-local rebuild than toward territory payload as
  the hidden source of `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`.
- The support side is less opaque now too: the same atlas already bounds `0x0040b5d0` above
  support collection `0x0062b244`, whose grounded live owners maintain goose-entry counters,
  neighboring world support lanes `[world+0x4c9a/+0x4c9e/+0x4ca6/+0x4caa]`, and selected
  support-entry state rather than an obvious per-region acquisition latch family. So the next pass
  should now bias even more toward the later region-local rebuild beneath the `0x00444887`
  continuation, while still keeping `0x0040b5d0` as a weaker adjacent prerequisite rather than
  treating it as the primary hidden owner.
- The next owner family is narrower now too: the checked-in shell-load subgraph and function map
  place `world_load_saved_runtime_state_bundle` `0x00446d40` directly ahead of the post-load
  generation pipeline `0x004384d0`, which is now the first explicit non-hook owner family above
  the ruled-down `0x00444887` continuation. The current grounded stage order is concrete enough to
  split the next static pass: `319` refreshes route entries, auxiliary route trackers, and then the
  placed-structure replay strip `0x004133b0`; `320` runs the region-owned building setup strip
  `0x00421c20 -> 0x004235c0`; and `321` runs the economy-seeding burst `0x00437b20` plus the
  cached region summary refresher `0x00423d30`. That means the next region closure pass should
  chase this `0x004384d0` handoff family directly instead of treating the remaining
  `[region+0x2a4]` / `[region+0x310/+0x338/+0x360]` gap as a generic continuation below
  `0x00444887`.
- The `319` lane is the strongest bridge inside that family: `0x004133b0` drains queued
  placed-structure ids through `0x0040e450`, sweeps every live site through `0x0040ee10`, and then
  reaches the already-grounded linked-site follow-on `0x00480710`. The `320` and `321` lanes are
  still explicit but weaker: `0x00421c20 -> 0x004235c0` stays on region-side demand balancing and
  structure placement, while `0x00437b20 -> 0x00423d30` only refreshes the cached category band
  `[region+0x27a/+0x27e/+0x282/+0x286]`. So the next non-hook region work should start from the
  post-load `319` placed-structure replay seam and only then revisit the narrower region-side
  `320/321` branches if the exact field bridge is still missing.
- The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
  0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
  region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment
  emitter over the world raster, and `0x0044c4b0` is the center-cell bit-`0x10` reseed pass. So
  the next region slice should stop revisiting those later owners and stay focused on the still-
  missing save-owned latch / severity / stable-id seam.
- The later class-`0` batch at `0x00438087` is narrowed now too: it walks live class-`0` regions
  through `0x0062bae0`, rescales the mirrored severity/source pair `[region+0x25a/+0x25e]` from
  the current value using world-side factors, clamps the result, and then hands the collection to
  `0x00421c20`; it still does not touch `[region+0x276/+0x302/+0x316]`.
- Its follow-on `0x00421c20` is bounded as a parameterized region-collection helper rather than a
  latch owner: it loops the same collection with caller-supplied scalar arguments, dispatches each
  record through `0x004235c0`, and does not write the pending/completion/one-shot lanes directly.
- The subsequent world follow-ons are narrower too: `0x00437b20` only stages a world-side reentry
  guard at `[world+0x46c38]`, iterates the live region collection through `0x00423d30`, and tails
  into `0x00434d40`, while `0x00437220` rebuilds broader world byte-set state around
  `[world+0x66be/+0x69db]` and other global collections. Those later branches should stay out of
  the remaining region latch-restore search too.
- The widened real-save region trace rules out one more false lead too: on grounded saves the
  `0x55f2` fixed-policy chunk keeps all three reserved dwords at `0x00000000` and the trailing word
  at invariant `0x0001`, so that fixed chunk is not currently carrying the missing latch or stable
  region id/class discriminator either.
- Reconstruct the save-side placed-structure collection body on top of the newly grounded
  `0x36b1/0x36b2/0x36b3` header seam so the blocked city-connection / linked-transit branch can
  stop depending on atlas-only placed-structure and local-runtime refresh notes, especially the
  semantics of the now-grounded compact `0x55f3` footer dword/status lane and the newly exposed
  separate tagged side-buffer seam candidates, especially the exact `0x38a5/0x38a6/0x38a7`
  family whose compact `6`-byte header pattern and embedded placed-structure-style `0x55f1`
  name rows now make it the grounded placed-structure dynamic side-buffer owner; the remaining
  blocker is semantic closure of the compact prefix regimes now summarized in real saves as seven
  stable patterns on `q.gms` and their relation to the embedded `0x55f1/0x55f2/0x55f3` row
  subset, especially now that the side-buffer name-pair corpus is proven disjoint from the
  grounded `0x36b1` triplet name-pair corpus on `q.gms`; the next pass should treat `0x38a5` as
  a separate infrastructure-asset owner seam, not a compact alias over the triplet records.
- Extend shellless clock advancement so more periodic-company service branches consume owned
  runtime time state directly instead of only the explicit periodic service command.
- Keep widening selected-year world-owner state only when a full owning reader/rebuild family is
  grounded strongly enough to avoid one-off leaf guesses.

## In Progress

- Widen shellless simulation from explicit service commands toward “advance the runtime clock and
  the simulation-owned services advance with it.”

## Queued

- Rehost additional periodic finance/service branches that still depend on frozen world restore
  fields instead of advanced runtime-owned time state.
- Reduce remaining company/chairman save-native gaps that still block standalone simulation
  quality, especially controller-kind closure and any deeper finance/state fields that still rely
  on conservative defaults.
- Rehost bounded live economy owner state beyond selector/catalog/override surfaces when a
  concrete non-shell-owned seam is grounded.
- Keep tightening shell-owned parity families only when that directly supports later rehosting.

## Blocked

- Full shell/dialog ownership remains intentionally out of scope.
- Any candidate slice that requires guessing rather than rehosting owning state or real
  reader/setter families stays blocked until a better owner seam is grounded.
- Missing owner seams or dispatch mappings are not by themselves a stop condition when a targeted
  static-mapping pass or a higher-layer rehosted trace/evaluator surface can still narrow them
  further without guessing.
- The city-connection announcement / linked-transit roster-maintenance branch is still blocked at
  the record-body level, not the collection-identity level: the runtime now has a corrected
  non-direct tagged region seam, a tagged train header-plus-directory seam, and a tagged
  placed-structure header seam, but it does not yet reconstruct the live region or
  placed-structure record bodies those service owners need.

## Recently Done

- `rrt-runtime` now exposes three higher-layer probe surfaces and matching CLI inspectors:
  `runtime inspect-periodic-company-service-trace <save.gms>`,
  `runtime inspect-region-service-trace <save.gms>`, and
  `runtime inspect-infrastructure-asset-trace <save.gms>`. These reports separate grounded outer
  owner inputs, runnable shellless branches, and explicit missing owner seams instead of leaving
  the current city-connection / linked-transit frontier as an opaque blocker.
- Those same probes now also sharpen the next queue choice on grounded real saves: the periodic
  company outer owner shows annual finance and route-preference override as grounded shellless
  branches while city-connection and linked-transit stay blocked on region/infrastructure owner
  seams; the region trace keeps the queued kind-`7` notice family on the transient side; and the
  infrastructure trace now makes the `0x38a5` consumer-mapping blocker first-class after
  disproving any alias to the `0x36b1` placed-structure triplet corpus.
- The infrastructure trace now also carries one small atlas-backed static-analysis layer above that
  seam: bridge/tunnel/track-cap name-family counts from the real side-buffer corpus plus concrete
  consumer candidates rooted at the `Infrastructure` child attach/rebuild/serializer helpers and
  the later route/local-runtime follow-on owners. That means the next `0x38a5` pass can be
  targeted static mapping instead of another generic scan.
- The same `0x38a5` probe now also exports payload-envelope summaries directly instead of only flat
  name rows: policy/profile tag presence, dominant embedded `0x55f2` and `0x55f3` span lengths,
  and sampled row boundaries. That means the next pass can decode the short embedded `0x55f3`
  payload lane on top of already grounded row boundaries instead of rediscovering the same
  envelopes again.
- That same probe now also exports the grounded short trailing flag-byte pair summary for the
  dominant `0x06`-byte rows, while the infrastructure trace carries the matching
  `0x0052ebd0/0x0052ec50` helper seam. That means the next pass can aim directly at how those
  flags combine with compact-prefix regimes and primary-child restore state instead of treating the
  short lane as anonymous payload.
- That same probe now also exports the fixed `0x55f2` six-dword policy samples and the grounded
  shared trailing word `0x0101` for all embedded rows, while the infrastructure trace carries the
  matching `0x00455870/0x00455930` helper seam. That means the next pass can focus on which of the
  two restored dword triplets actually bridge into child-count / primary-child state instead of
  rediscovering the fixed `0x55f2` row shape.
- The infrastructure trace now also carries the deeper `0x00530720/0x0052e8b0` bridge, so the next
  pass can focus on the outer payload-stream header and compact-prefix regimes instead of revisiting
  the fixed `0x55f2` six-dword row.
- That same trace now also ranks those consumers into explicit hypotheses, so the next
  infrastructure pass should start with the attach/rebuild strip instead of treating all
  candidate owners as equally likely.
- The region trace now also carries the corresponding atlas-backed candidate owner strip above the
  unresolved save latches, so the region frontier is now explicitly “missing persisted owner seam
  for `[region+0x25e/+0x276/+0x302/+0x316]` and stable region id/class,” not “unknown service
  family.”
- That same trace now also ranks those owners into explicit hypotheses, so the next region pass
  should start with the pending bonus service owner and peer/linkage strip rather than the queued
  modal family.
- Save inspection now splits the shared `0x5209/0x520a/0x520b` family correctly: the smaller
  direct `0x1d5` collection is the live train family and now exposes a live-entry directory rooted
  at metadata dword `16`, while the actual region family is the larger non-direct `Marker09`
  collection with live_id/count `0x96/0x91`; the tagged placed-structure header
  (`0x36b1/0x36b2/0x36b3`) remains grounded alongside them.
- That same corrected region seam now also exposes repeated `0x55f1/0x55f2/0x55f3` serialized
  record triplets with len-prefixed names plus fixed policy/profile chunk lengths, so the next
  city-connection pass can target the real record envelope instead of another blind scan.
- The fixed `0x55f2` row inside each region triplet is now decoded structurally as three leading
  `f32` lanes, three reserved `u32` lanes, and a trailing `u16` word, so the next save-region
  slice can focus on the larger `0x55f3` payload where the pending/completion/one-shot latches are
  most likely to live.
- The larger `0x55f3` payload now also exposes an embedded direct profile collection with grounded
  live-id/count headers, fixed `0x22`-byte rows, profile names, and trailing weight scalars, so
  the remaining region work is on the unresolved payload fields above that collection rather than
  on the profile subcollection itself.
- Grounded real saves now also show that the region-side `0x55f3` payload has zero trailing
  padding beyond that embedded profile collection, so the remaining region blocker has shifted
  from “find the hidden tail inside this payload” to “find the separate owner seam that backs the
  runtime latches the city-connection branch still reads.”
- Save inspection now also exports a generic low-tag unclassified collection scan over plausible
  indexed-collection headers, now through a lightweight CLI path that does not require full bundle
  inspection and now filters out candidates nested inside already-grounded company/chairman/train/
  region/placed-structure spans.
- That lightweight scan now also narrows the real save frontier to a much smaller stable candidate
  set across `p.gms`, `q.gms`, and `Autosave.gms`, with the exact `0x38a5/0x38a6/0x38a7` family
  standing out as the strongest current placed-structure dynamic side-buffer candidate.
- The `0x38a5/0x38a6/0x38a7` family now also has a first dedicated parser scaffold in
  `rrt-runtime`: its synthetic regression is grounded, its header shape is checked in, and the
  parser now expects a compact 6-byte prefix plus separator byte before an embedded
  placed-structure-style dual-name row rather than treating the family as anonymous residue.
- That exact `0x38a5/0x38a6/0x38a7` parser is now also wired through a lightweight CLI inspector
  and the normal save company/chairman analysis output, and grounded real saves now prove the
  same seam directly:
  `q.gms` exposes `live_record_count=3865`, prefix `0x0005d368/0x0001/0xff`, and first embedded
  names `TrackCapST_Cap.3dp` / `Infrastructure`; `p.gms` exposes the same structure with
  `live_record_count=2467`.
- That same direct `0x38a5` probe now also samples multiple embedded name rows with their
  preceding compact prefixes, showing that the seam is not a one-off wrapper: grounded `q.gms`
  samples include repeated `TunnelSTBrick_*` names under `Infrastructure` with compact leading
  dwords like `0x000055f3` and `0xff0000ff`, so the next pass can target the semantics of those
  compact prefix patterns instead of hunting the owner seam itself.
- The `0x38a5` probe now also summarizes all embedded compact prefix regimes instead of just the
  first few samples: grounded `q.gms` currently exposes seven stable pattern groups across 138
  embedded rows, with the dominant `0xff000000/0x0001/0xff` group carrying 62 bridge-section
  rows, the `0xff0000ff/0x0001/0xff` and `0xf3010100/0x0055/0x00` groups concentrating cap-like
  rows, and a smaller `0x000055f3/0x0001/0xff` group carrying 17 tunnel-section / cap rows whose
  leading dword matches the embedded placed-structure profile tag directly.
- The save-company/chairman analysis path now also compares that grounded `0x38a5` side-buffer
  name-pair corpus against the grounded `0x36b1` triplet name-pair corpus directly; on `q.gms`
  the overlap is currently zero (`0/138` decoded side-buffer rows and `0/5` unique side-buffer
  name pairs match the 56-triplet corpus), which shifts the remaining placed-structure work away
  from “prove these are aliases” toward “find how the separate infrastructure-asset owner seam is
  consumed by city-connection / linked-transit service.”
- Save inspection now also has a dedicated probe for the atlas-backed region queued-notice node
  shape (`payload seed 0x005c87a8`, kind `7`, zero promotion latch, region id, amount, `-1/-1`
  tails), plus a matching lightweight CLI inspector. Grounded `q.gms`, `p.gms`, and `Autosave.gms`
  all currently return `null`, which is useful negative evidence: the transient region notice
  queue is not obviously persisted in these ordinary saves.
- The placed-structure tagged save stream now also exposes repeated `0x55f1/0x55f2/0x55f3`
  triplets with dual name stems, a fixed five-`f32` policy row, and a compact `0x5dc1...0x5dc2`
  footer carrying one raw `u32` payload lane plus one live `i32` status lane, so the remaining
  placed-structure work is semantic closure of those owned fields rather than envelope discovery.
- That compact placed-structure `i32` footer status lane is now partially grounded as owned
  semantics too: observed non-farm families stay at `-1`, while farm families use nonnegative
  `0..11` buckets that are now exported as farm growth-stage indices instead of opaque raw status
  residue.
- Stepped calendar progression now also refreshes save-world owner time fields, including packed
  year, packed tuple words, absolute counter, and the derived selected-year gap scalar.
- Automatic year-rollover calendar stepping now invokes periodic-boundary service.
- Save-native world locomotive policy owner state now flows through runtime restore state,
  summaries, and keyed world-flag execution for the grounded `All Steam/Diesel/Electric Locos
  Avail.` descriptor strip plus the cached available-locomotive rating.
- The selected-year bucket ladder rooted in `0x00433bd0` is now checked in as a static artifact,
  and runtime restore state now derives both the selected-year bucket scalar and the
  `[world+0x0bde]` economic-tuning mirror from owner-family inputs instead of preserving stale
  load-time residue.
- That same selected-year owner family now also rebuilds the direct bucket trio
  `[world+0x65/+0x69/+0x6d]`, the complement trio `[world+0x71/+0x75/+0x79]`, and the scaled
  companion trio `[world+0x7d/+0x81/+0x85]` from the checked-in `0x00433bd0` artifact instead of
  preserving stale save-time residue.
- The save-native company direct-record seam now also carries the full outer periodic-company
  side-latch trio rooted at `0x0d17/0x0d18/0x0d56`, including the preferred-locomotive
  engine-type chooser byte beside the city-connection and linked-transit finance gates.
- That same side-latch trio now also has a runtime-owned service-state map and summary surface,
  so later periodic company-service work can stop reading those lanes directly from imported
  market/cache residue.
- The periodic-boundary owner now also clears the transient preferred-locomotive side latch every
  cycle and reseeds the finance latches from market state where present, while preserving
  side-latch-only company context when no market projection exists.
- The outer periodic-company seam now also has a first-class runtime reader:
  selected-company summaries and finance readers can resolve the base `[world+0x4c74]`
  route-preference byte, the effective electric-only override fed by `0x0d17`, and the matching
  `1.4x` versus `1.8x` route-quality multiplier through owned periodic-service state instead of
  leaving that bridge in atlas notes.
- That same periodic-company seam now also owns a first-class route-preference apply/restore
  mutation lane: runtime service state tracks the active and last electric override, beginning the
  override rewrites `[world+0x4c74]` to the effective route preference for the selected company
  service pass, and ending the override restores the base world byte instead of leaving the seam as
  a pure reader bridge.
- The same route-preference mutation seam now also carries explicit apply/restore service counters
  through runtime service state and summaries, so later periodic-company branches can assert that
  override activity happened even before the missing city-connection / linked-transit service
  owners are fully rehosted.
- Company cash, confiscation, and major governance effects now write through owner state instead of
  drifting from market/cache readers.
- Company credit rating, prime rate, book value per share, investor confidence, and management
  attitude now refresh from grounded owner-state readers.
- Annual finance service persists structured news events and grounded debt/share flow totals.