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]
  • the nearby selected-company and live-site helper strip is tighter now too: 0x004337a0 is the raw selected-company getter over [world+0x21], and the adjacent world-side helpers 0x00452d80 / 0x00452db0 / 0x00452fa0 are live selected-site or active service-state setters/dispatchers over [world+0x217d/+0x2181] gated by mode byte [world+0x2175], not restore-time republishers for [site+0x276]
  • the base placed-structure load callback is narrower now too: local .rdata at 0x005cb4c0 shows the shared base table, not the 0x005c8c50 specialization table, owns the 0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930 load-save quartet; direct disassembly of 0x0045c150 -> 0x00455fc0 shows that callback only reloads the generic 0x55f1/0x55f2/0x55f3 triplet/scalar bands and then re-enters the base triplet/scalar slots 0x00455870 / 0x00455930, so it does not repopulate [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 per-map summary now surfaces the add-building subset directly too: it reports add_building_dispatch_strip_record_indexes, add_building_dispatch_strip_descriptor_labels, and the matching add_building_dispatch_strip_records_with_trigger_kind / add_building_dispatch_strip_records_missing_trigger_kind counts, so inspected maps can now show whether Add Building rows are present and still null-trigger without a separate cluster pass
  • that add-building subset is structured one layer deeper now too: the per-map summary and the compact-dispatch cluster/counts reports both surface add-building signature families, condition-tuple families, and combined signature/condition clusters, so the remaining trigger-kind/source question can compare exact compact subfamilies instead of only raw descriptor hits
  • the first concrete add-building cluster split is now visible too: targeted map inspections show Texas Tea.gmp carrying a one-row Port01 cluster on signature family nondirect-ge1e-h0001-0007-0000-6d00-0200-p0000-0000-0000-ffff with condition family [7:0], while Alternate USA.gmp carries repeated three-row FarmGrain/Logging Camp clusters on nondirect-ge34-h0002-0007-0004-73|75|7b|85... with condition family [7:4,42:0]; that narrows the remaining trigger-kind/source question to a small set of compact subfamilies rather than a single undifferentiated add-building carrier
  • the first exclusivity pass is positive too: the widened cluster-counts report now surfaces, for each add-building signature/condition cluster, the descriptor keys that share it plus the non-add-building subset. Current targeted checks on Texas Tea.gmp and Alternate USA.gmp show those observed add-building clusters have empty non-add-building companions, which biases the next source/trigger-kind pass toward a distinct add-building compact subfamily rather than a generic dispatch carrier reused by variable-band rows
  • the descriptor-independent row-shape split is explicit now too: the same cluster-counts surface reports normalized add-building row shapes. Current targeted checks show Texas Tea.gmp on the one-row shape [0:8:0], while Alternate USA.gmp sits on the repeated three-row shape [0:8:-25,0:8:0,0:8:0]; that gives the next pass a simpler shape-level discriminator even when descriptor labels differ
  • the shipped-map corpus is checked in now too: artifacts/exports/rt3-1.05/add-building-compact-dispatch-corpus.json records the full six-map add-building carrier set in bundled RT3 1.05 maps: Alternate USA, Chicago to New York, Louisiana, Pacific Coastal, Rhodes Unfinished, and Texas Tea. Across that corpus the normalized row-shape totals are only four families: [0:8:-25,0:8:0,0:8:0] = 4, [0:8:0,0:8:0,0:8:0,0:8:0] = 1, [0:8:0,0:8:0,0:8:0] = 1, [0:8:0] = 4. The accompanying signature/condition cluster totals now show the add-building carrier set is broader than the first two sampled maps but still small enough to treat as a bounded compact subfamily frontier rather than a diffuse generic event carrier.
  • 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 same counts output now also carries an explicit add-building subset so the acquisition-side branch can compare Add Building records and their still-missing trigger-kind coverage without grepping the full occurrence dump.
  • the installed-map totals are grounded now too: current rt3_105/maps corpus gives 41 bundled maps, 38 maps with dispatch-strip rows, and 318 dispatch-strip records total, all on real_packed_nondirect_compact_v1 with dispatch_strip_records_with_trigger_kind = 0; the add-building subset inside that corpus is only 10 grouped occurrences across 7 recovered descriptor keys (Barracks, Bauxite Mine, FarmGrain, Furniture Factory, Logging Camp, Port01, Warehouse05), again all still missing trigger kind
  • 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
  • the startup kind-8 owner strip has a dedicated checked artifact now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-startup-subgraph.{dot,md} seeds 0x00444d92, 0x00432f40, 0x004323a0, 0x00431b20, and 0x00433130 at depth 5, giving the current ordinary bring-up path a reusable static-analysis surface instead of only scattered queue prose
  • that artifact narrows the immediate owner one step higher too: the ordinary restore/service pair 0x00433130 and 0x00432f40 now sit directly under world_entry_transition_and_runtime_bringup 0x00443a50 in the checked subgraph, alongside 0x004133b0 placed-structure refresh, 0x00421510 region refresh, and the 0x00433bd0/0x00434130/0x004354a0/0x00435603 year-band/state refresh strip. That means the next static recovery pass can focus on 0x00443a50 ordering and preconditions instead of treating 0x00444d92 as a floating standalone caller.
  • there is now a smaller checked artifact for that owner too: artifacts/exports/rt3-1.06/world-entry-bringup-refresh-subgraph.{dot,md} seeds only 0x00443a50 at depth 3, giving a 343-node / 989-edge bringup-refresh surface that is easier to work from than the broader kind-8 startup export when the immediate question is just ordering and neighboring refresh owners.
  • the saved-runtime-state loader is boxed in one step lower now too: artifacts/exports/rt3-1.06/world-load-saved-runtime-state-subgraph.{dot,md} seeds 0x00446d40 at depth 3 and shows the loader directly reaches 0x00433130 scenario_event_collection_refresh_runtime_records_from_packed_state, but not 0x00432f40. That shifts the remaining ordinary kind-8 question upward: the unresolved service-vs-restore ordering is now specifically inside 0x00443a50, not inside the loader itself.
  • the bringup owner note now supplies the high-level ordering too: current function-map.csv notes for world_entry_transition_and_runtime_bringup 0x00443a50 already state that the tagged load phase reloads event runtime records through 0x00433130, while the one-shot kind-8 runtime-effect service through 0x00432f40 only runs much later in the final reactivation tail, after the candidate/region/year-band refresh strip and before shell-profile latch [0x006cec7c+0x97] is cleared. That means the remaining unknown is no longer restore-vs-service ordering in the abstract; it is which late bringup branch or retagger between those two points materializes the live kind-8 records that carry the mutation-capable compact payloads.
  • the late retagger remains a prose-first seam: a direct 0x00442c30 subgraph export currently collapses to the seed node only, because the grounded function-map note carries the useful scenario-title and collection-mutation detail but not many mapped-address backrefs. So the post-load scenario-fixup branch should currently be treated as a manual-note recovery seam rather than one the generic subgraph exporter can answer by itself.
  • the relevant prose is checked in separately now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-late-bringup-note.md extracts the current late-bringup facts for 0x00446d40, 0x00443a50, 0x00442c30, and the explicit SP - GOLD / Labor trigger-kind rewrites, so the next pass can work from one bounded note instead of stitching the same ordering back together from the queue plus function-map prose.
  • the shipped add-building carrier corpus no longer supports the older filename-mismatch bias: the checked report artifacts/exports/rt3-1.05/add-building-map-title-hints.json now scans the six bundled carrier maps in artifacts/exports/rt3-1.05/add-building-compact-dispatch-corpus.json against the grounded 0x00442c30 title set (Go West!, Germany, France, State of Germany, New Beginnings, Dutchlantis, Britain, New Zealand, South East Australia, Tex-Mex, Germantown, The American, Central Pacific, Orient Express).
  • the new title-hint probe narrows that evidence precisely: five of the six shipped carrier maps now show at least one grounded retagger-title hit, but only one map currently shows an adjacent embedded .gmp reference plus grounded title and only one shows a same-stem pair. Louisiana.gmp carries Dutchlantis.gmp / Dutchlantis at offset 0x73d0 with zero byte distance, while the other current carrier-map hits stay weaker (Alternate USA.gmp late Germany / France / Britain, Chicago to New York.gmp late Germany / France, Pacific Coastal.gmp later Central Pacific, Texas Tea.gmp later Germany, Rhodes Unfinished.gmp no current hit).
  • that keeps the title-fixup branch alive but no longer as a broad filename-level explanation: the evidence now supports a narrow “one strong Louisiana -> Dutchlantis overlap plus several weaker prose-only or late-string overlaps” reading rather than a clean one-to-one mapping from the shipped add-building carrier filenames to the grounded 0x00442c30 scenario-title set.
  • the direct runtime-event comparison narrows it further too: the checked note artifacts/exports/rt3-1.06/runtime-effect-kind8-title-overlap-note.md shows that Louisiana.gmp is the only carrier with a same-stem Dutchlantis.gmp / Dutchlantis pair, but Dutchlantis.gmp itself still has no current add-building dispatch rows while Louisiana.gmp keeps the one-row Add Building Warehouse05 cluster on nondirect-ge1e-h0001-0007-0000-5200-0200-p0000-0000-0000-ffff :: [7:0]. So the strongest current title overlap still does not reproduce the actual shipped add-building row family.
  • the post-reload candidate set is checked in now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-post-reload-candidates.md extracts the currently plausible late 0x00443a50 branches between ordinary reload and final kind-8 service, with the current bias explicitly shifted away from the known title-fixup branch and toward the Tier 2 candidate/world-state rebuild owners rather than the Tier 3 shell-progress/year-scalar refresh strip.
  • the Tier 2 owner strip is checked in separately now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-candidate-rebuild-subgraph.md shows the current bounded rebuild band rooted at 0x00412c10 / 0x00412bd0 / 0x00437737 reaching candidate runtime-record rebuild 0x00412d70 / 0x00412fb0, named-availability query/upsert 0x00434ea0 / 0x00434f20, cargo-economy filter refresh 0x0041eac0, port/warehouse recipe rebuild 0x00435630, and only then the later world bringup / event-service neighborhood 0x004384d0 / 0x00443a50 / 0x00432f40.
  • the strongest same-stem title pair has a Tier 2 availability note now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-named-availability-note.md shows Louisiana.gmp and Dutchlantis.gmp share the direct named-availability bit for Warehouse05 (1/1), as well as Port01, Furniture Factory, FarmGrain, and Logging Camp; their current 18 named-availability differences fall elsewhere (Bauxite Mine, AluminumMill, Farm Corn, FarmCotton, FarmRice, FarmSugar, etc.). The same note now folds in two deeper grounded constraints too: 0x00412d70 does not consult the scenario-side recipe-book name at [state+0x0fe8], and 0x00434f20 writes only a boolean availability override bit. So the current Tier 2 question is no longer “is Warehouse05 simply toggled differently?” or “is a recipe-book display name leaking through?” but “which broader candidate-state rebuild or latch sequencing difference above 0x00437737 / 0x00412c10 / 0x00412bd0 / 0x00412d70 / 0x00412fb0 leads to the shipped Add Building Warehouse05 row in Louisiana.gmp?” The broader compare-candidate-table surface now reinforces the same point too: Louisiana.gmp versus Dutchlantis.gmp stays on the same scenario-named-candidate-availability-table semantic family, still keeps Warehouse05 = 1/1, and moves the actual difference_count = 43 into the wider industry mix and zero-trailer-name set rather than a unique Warehouse05 gate.
  • that sequencing question is checked in directly now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md extracts the current late order around the explicit 0x197 checkpoint: the earlier 0x00443ebc recipe-runtime rebuild still sits before 0x00412c10 / 0x00412bd0 / 0x00434130 / 0x00436af0, while the later 0x00444ac1 checkpoint runs after 0x004354a0 / 0x00487de0 and then falls through into 0x00437737 -> 0x00434f20 -> 0x00412c10, with the separate recipe-runtime side re-entering 0x00435630 -> 0x00412d70. That keeps the next recovery pass focused on Tier 2 sequencing interactions instead of title strings or direct Warehouse05 availability bits.
  • the strongest title-overlap pair now has a recipe-book note too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-recipe-book-note.md shows Louisiana.gmp and Dutchlantis.gmp diverge heavily on the recipe-book surface even though Warehouse05 stays 1 / 1 in the named-availability table. Louisiana.gmp is sparse there (currently only book00.line02 stays nonzero), while Dutchlantis.gmp keeps multiple later mixed lines and mode words. That shifts the current Tier 2 bias further toward the 0x00435630 -> 0x00412d70 rebuild side rather than the direct 0x00437737 -> 0x00412c10 availability side. The same note now also boxes in the same-condition-family counterexample: Louisiana.gmp and Texas Tea.gmp both sit on [7:0], but Louisiana.gmp keeps the one-row Warehouse05 cluster with only book00.line02 = 0x00080000, while Texas Tea.gmp keeps the one-row Port01 cluster with a broader four-book nonzero mode strip. So the current evidence no longer supports “shared [7:0] family implies one shared Tier 2 recipe/runtime shape.”
  • the bundled add-building carrier set now has a checked recipe-book corpus too: artifacts/exports/rt3-1.05/add-building-carriers-recipe-book-scan.json shows the six carrier maps split into two recipe families: Alternate USA.gmp stands alone with the richer five-book nonzero mode strip, while the other five carrier maps fall into one broader family but still diverge sharply inside it. Among that five-map family, Louisiana.gmp is currently the sparsest nonzero profile (only book00.line02 = 0x00080000 plus the paired book00 token lanes), while Chicago to New York.gmp, Rhodes Unfinished.gmp, and Texas Tea.gmp each keep broader multi-book nonzero mode strips and Pacific Coastal.gmp keeps supplied-token-only activity. That makes Louisiana.gmp look less like a generic carrier-map recipe pattern and more like a genuinely narrow Tier 2 recipe/runtime-record case.
  • the recipe/runtime owner strip is checked in separately now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-recipe-runtime-note.md summarizes the new subgraph rooted at 0x00435630 / 0x00412d70 / 0x00412fb0. The current bounded shape is a coupled rebuild family rather than a one-way ladder: 0x00435630 re-enters 0x00412d70, 0x00412d70 re-enters 0x00435630 plus 0x00411ce0 / 0x00411ee0, and 0x00412fb0 re-enters 0x004120b0 -> 0x00412d70 -> 0x00412ab0 -> 0x00412c10. That keeps the next pass focused on the internal sequencing and handoff across the coupled recipe/runtime/availability rebuild strip, not on one isolated helper. The same note now carries the first upstream feed-in difference too: compare-setup-payload-core Louisiana.gmp Dutchlantis.gmp already differs on payload_word_0x14 (1870 vs 2025), payload_byte_0x20 (0x3a vs 0xfd), payload_word_0x3b2 (2 vs 1), and the candidate-header words (0xcdcdcdcd vs 0x00000000). So the next pass can now work on both sides of the coupled Tier 2 strip: the upstream setup payload core and the downstream recipe/runtime rebuild loop.
  • the carrier-set setup-core comparison is checked in now too: artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-setup-core-note.md widens that upstream comparison across all six bundled add-building carriers. It shows Louisiana.gmp is not unique on payload_word_0x3b2 (Chicago to New York.gmp also has 2) and shows Louisiana.gmp is unique among that six-map carrier subset on the candidate-header sentinel pair 0xcdcdcdcd / 0xcdcdcdcd, while Alternate USA.gmp stays separately unique on the recognized rt3-105-map-container-v1 header pair. The same note now widens further across all 41 bundled rt3_105 maps and shows the candidate-header pair is not actually Louisiana-specific in the full corpus at all: nine maps share 0xcdcdcdcd / 0xcdcdcdcd, matching the older atlas read that this looks like coarse scenario-family framing instead of a direct Tier 2 trigger. That trims the next upstream Tier 2 question again: focus on the more specific remaining setup-core combination (payload_word_0x14, payload_byte_0x20, plus the sparse recipe/runtime profile), not on the candidate-header class by itself. The same widened note now records that the full current Louisiana.gmp tuple (payload_word_0x14 = 1870, payload_byte_0x20 = 0x3a, payload_word_0x3b2 = 2, candidate_header = 0xcdcdcdcd / 0xcdcdcdcd) is still unique across the 41-map corpus even after the coarse header class is demoted, so the next pass should compare that tighter tuple to the sparse recipe/runtime family rather than reopening the broad header-pair question. The same note now also carries the grounded owner bridge for those compared setup-core fields. The early copy path is still 0x00442400 -> 0x00502220 -> 0x0047be50, but the later reset or reactivation owners are now bounded too: 0x00436d10 and 0x00443a50 both reimport the staged subset [profile+0x77/+0xc5] before rerunning the same rebuild family that includes 0x00435603, 0x00435630, 0x0041e970, 0x00412bd0, 0x00434130, and 0x00436af0. That narrows the open question again: +0x14/+0x20 now have one real bridge into the Tier 2 strip through [profile+0x77/+0xc5], while +0x3b2/+0x3ba still stop on the setup-panel threshold or scroll path. The next pass should therefore test whether the unique Louisiana.gmp +0x14/+0x20 pair is enough to explain its Tier 2 runtime shape through that grounded bridge, or whether the sparse recipe/runtime side is still the more plausible differentiator. One adjacent compare-setup-launch-payload check now sharpens that too: Louisiana.gmp does not collapse into the nearest setup-core peers on the launch-token side either, but that band is still not part of the currently grounded Tier 2 bridge. So the next pass should keep launch tokens as supporting context while testing the already-grounded +0x14/+0x20 -> [profile+0x77/+0xc5] bridge against the sparse recipe/runtime family. The same widened setup-core note now shows the split inside that bridge too: payload_byte_0x20 = 0x3a is unique to Louisiana.gmp across all 41 bundled rt3_105 maps, while payload_word_0x14 = 1870 has only one peer (Mexico). That makes the campaign/setup-byte side of the bridge the strongest remaining setup-core differentiator, with the year-word side a secondary companion rather than a full peer-group collapse. The same note now also carries the direct bridge-peer check: compare-recipe-book-lines Louisiana.gmp Mexico.gmp shows that the only +0x14 peer still stays zero across the checked recipe-book surface while Louisiana.gmp keeps the sparse nonzero book00 profile. So the next pass should keep the setup bridge narrowed to the unique +0x20 campaign/setup-byte side while still treating the sparse recipe/runtime family as the stronger remaining differentiator. The same note now also sharpens the +0x20 bridge itself: current grounded downstream consumers of mirrored [world+0x66de] are mostly the editor metadata checkbox and campaign-gated branches inside 0x00442c30, not the core Tier 2 helpers directly. So the likely Tier 2 relevance of +0x20 is the branch gate inside 0x00436d10 / 0x00443a50 before the rebuild family runs, not a later direct [world+0x66de] -> 0x00435630/0x00412bd0/0x00412c10 data path. The same note now weakens that bridge a step further: current grounded profile-side consumers treat [profile+0xc5] as a nonzero gate, and both 0x004425d0 and the campaign-side launch branch force it to 1. So the raw Louisiana.gmp setup payload byte +0x20 = 0x3a is not yet a grounded unique numeric Tier 2 input; on the current evidence it collapses to the ordinary nonzero campaign or setup branch before 0x00436d10 / 0x00443a50 run. That shifts even more weight back onto the sparse recipe/runtime family, with +0x14 the only currently grounded preserved setup-side scalar still crossing the bridge. The same note now also adds a same-header-class recipe check: compare-recipe-book-lines Louisiana.gmp "Argentina Opens Up.gmp" shows that even another 0xcdcdcdcd / 0xcdcdcdcd peer keeps a broader mixed book01/book02 profile while Louisiana.gmp stays sparse. So the coarse setup-header class is no longer a plausible predictor of the Tier 2 runtime shape either; the recipe/runtime family remains the dominant differentiator. The checked Tier 2 recipe-runtime note now carries the stronger current read: 0x00435630 only materializes nonzero-mode rows, Mexico.gmp is the only +0x14 peer and still stays zero across the checked recipe-book surface, and the same-header peer Argentina Opens Up.gmp keeps additional nonzero book01/book02 content. So the next pass should bias toward finding other maps that share Louisiana's minimal imported nonzero recipe-runtime set, rather than reopening broader setup-core or header-class hypotheses. That scan is now checked in at artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-recipe-signature-note.md: across all 41 bundled rt3_105 maps there are 23 nonzero-mode path signatures, and Louisiana.gmp sits in a small three-map book00.line02-only mode family with Britain.gmp and South East USA.gmp. But Louisiana.gmp becomes unique again once the supplied and demanded token lanes are included. That makes the next concrete Tier 2 recipe pass smaller: compare Louisiana.gmp directly against Britain.gmp and South East USA.gmp on the token-bearing minimal imported set and then on any downstream runtime-facing differences. The note now carries that first peer split too: Britain.gmp diverges strongly with different mode and extra supplied rows, while South East USA.gmp stays structurally closer but still differs on the exact book00.line01 demanded token and book00.line02 mode/supplied-token pair. So the current queue head is no longer “find a peer”; it is “find the downstream runtime-facing consequence of Louisiana’s distinct exact book00 token-bearing signature.” That downstream split is now partially grounded too: direct inspect-smp checks show both Britain.gmp and South East USA.gmp still carry Port01 and Warehouse05 names in-file but neither has any add-building dispatch-strip trigger rows at all. So Louisiana.gmp is now the first checked member of that book00.line02 mode-shape family whose exact token-bearing signature also lines up with the shipped add-building runtime path.
  • the next corpus split is tighter now too: the apparent 0x00010000 / 0x6c430000 / 0x00080000+0x00004080 three-row cluster is no longer just a local Louisiana.gmp curiosity; Ireland.gmp and Eastern China.gmp both reuse parts of it, but only inside broader multi-book imported profiles, and neither currently reaches any add-building dispatch-strip rows. Louisiana.gmp is the only bundled map whose entire nonzero imported recipe surface collapses to that exact three-row cluster. So the current queue head is now narrower again: test whether the shipped 5200 :: [7:0] Add Building Warehouse05 strip is tied to that minimal imported-cluster shape specifically, rather than to the mere presence of one reused 0x00080000 / 0x00004080 triplet inside a broader recipe profile.
  • the same split is tighter even inside the broader “single imported row” family: eight bundled maps currently materialize only one nonzero recipe row, but Louisiana.gmp is the only one whose supporting token surface is just two additional demand rows instead of three or four extra token-bearing rows. So the next checked discriminator is now narrower than “single imported row” too: test whether the 5200 :: [7:0] add-building strip tracks that exact two-demand-plus-one- imported minimal cluster, not just the existence of one imported row or one reused 0x00080000 / 0x00004080 triplet.
  • the importer-side boundary is tighter now too: direct inspect-smp checks show Louisiana.gmp, Britain.gmp, and South East USA.gmp all collapse to the same first importer shape of exactly one imports_to_runtime_descriptor = true line on nonzero-supply-branch, while the broader reuse case Ireland.gmp imports four such rows. So the next queue head is no longer “prove the first importer branch differs”; it is: recover the later runtime-record / named-availability consequence under 0x00412d70 / 0x00412fb0 / 0x00412c10 that makes the minimal cluster land on 5200 :: [7:0] only in Louisiana.gmp.
  • the direct named-availability table is still not that consequence: the nearest single-import peer South East USA.gmp keeps Warehouse05 = 1 and Port01 = 1 just like Louisiana.gmp, matching the earlier Dutchlantis.gmp read. So the next later Tier 2 question is now even narrower: recover the runtime-record bank/template consequences under 0x00412d70 (plus dependent 0x00411ce0 / 0x00411ee0) before 0x00412c10 mirrors anything into [candidate+0x7ac].
  • the 0x00412d70 runtime-record roots are grounded now too: direct objdump over RT3.exe shows 0x005c93d8 = "Warehouse%02d" and 0x005c93e8 = "Port%02d", with the rebuild choosing the Port%02d root only when [candidate+0xba] != 0 and the Warehouse%02d root otherwise. That turns the next queue head into a concrete port-versus-warehouse runtime-record question: recover how the bank/template pass and live availability bytes [candidate+0xba/+0xbb] make Louisiana.gmp land on the Warehouse%02d side that later lines up with 5200 :: [7:0].
  • the writer-side split is narrower now too: direct disassembly of 0x004120b0 shows that the per-record stream-load helper clears [candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0], restores the fixed fields through [candidate+0x33], restores [candidate+0xb9/+0xba/+0xbb], and streams the packed 0xbc descriptor array into [candidate+0x37]. Direct disassembly of upstream source-record import 0x00414490 also restores [record+0xb8/+0xb9/+0xba/+0xbb]. The new checked-in building source inspector now shows the stock Data/BuildingTypes/*.bca corpus keeps those four bytes zero across every observed file, including Warehouse.bca and Port.bca. So the next concrete recovery target is no longer the lower tagged-record reader itself: recover which later owner or alternate content path makes the live [candidate+0xba/+0xbb] bank/template state diverge from that all-zero shipped BCA corpus before 0x00411ee0 / 0x00411ce0 / 0x00412c10 run.
  • the broader consumer strip above that split is narrower now too: direct disassembly now rules three more neighbors onto the read-only side of the bank bytes. 0x00419230 only scans already-linked owner candidates and runs two rebank-or-clone passes keyed by candidate[+0xba] and candidate[+0xbb] before stamping Port%02d / Warehouse%02d labels into the auxiliary pool. 0x00418610 only feeds candidate[+0xba] plus subtype/class predicates into the projected-rectangle sample-band helper. And the broader projected-offset lane at 0x0041a5fd..0x0041a944 resolves the same owner candidate and gates a world-cell occupancy sweep on candidate[+0xba], but still does not reconstruct the byte. The .smp restore-side auxiliary branch is negative in the same way: 0x00413f80 only restores queued temporary aux-record images without the fixed selector-byte body [+0xb8..+0xbb], and 0x0041a950 only releases the live aux collection before re-entering the same 0x004196c0 -> 0x00419230 import-plus-follow-on strip when the restore flags demand it. The outer world-entry load branch is fixed in the same way: 0x00438c70 allocates the live candidate pool through 0x004131f0 and the auxiliary/source pool through 0x0041aa50, and both constructors tail directly into the same fixed tagged-import families rather than taking a title-specific source-selection branch in between. The startup-side availability preseed is negative in the same way now too: direct disassembly of 0x00437737 and its sibling callsite 0x00436ad7 shows both branches only reading live candidate subtype [candidate+0x32] plus bank bytes [candidate+0xba/+0xbb] and then feeding those predicates into the scenario-side availability table at [state+0x66b2] through 0x00434f20; the later bring-up caller 0x00444acc simply re-enters that same 0x00437737 -> 0x00434f20 -> 0x00412c10 strip. So even the visible startup preseed still consumes already-materialized bank/template bytes rather than explaining how they became nonzero in the first place. The constructor/import seam is fixed in the same negative way now too: 0x00438c70 allocates the live candidate pool through 0x004131f0, calls 0x004411d90 (currently a no-op stub), and only then allocates the aux/source pool through 0x0041aa50, so there is no hidden branch between those two constructors. The only checked caller of source-record importer 0x00414490 is 0x00419788, and the surrounding .rdata proves that strip is the stock "%1*.bca" / ".\\Data\\BuildingTypes\\" scan rather than a map-specific alternate package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA parser?”; it is “which later non-stock writer or projection seam makes live [candidate+0xba/+0xbb] diverge after the fixed stock BCA import has already run?” The stock asset-side negative is no longer completely uniform either. The checked-in inspect-building-type-sources report now shows the shipped Data/BuildingTypes corpus is zero at 0xb8..0xbb for every current .bca except MachineShop.bca, which carries the lone selector-window exception (0x00, 0x80, 0x3f, 0x00) on a 788-byte row. The separate backup/Bldg/*.bca corpus stays fully zero in that same window. So the queue head is narrower again: explain whether the Machine Shop exception is part of the seeded Tier-2 family at all, or recover the later projection seam that still has to account for the broader live divergence. The direct +0xba/+0xbb writer census is narrower now too. The obvious newly surfaced stores at 0x004ecd42/0x004ecdaa and 0x004ed5d5/0x004ed625 are only shell-side portrait/string refresh helpers: they walk a separate id-keyed collection through 0x0053f830, free and replace heap strings at dword [entry+0xba], and mirror shell text from [0x006cec74+0x1ef]. The other new dword writers at 0x00540251/0x0054034d, 0x0055fd40, 0x0055bdc4/0x0055bf01, 0x0055ca78, 0x0055f290, 0x005b5168, and 0x005b6718 likewise belong to wider non-candidate heap objects with their own vtables and field layouts, not to the live 0x005c93cc candidate rows. The actual candidate import strip now has a tighter positive bound instead: 0x004120b0 explicitly declares [candidate+0xba] and [candidate+0xbb] as one-byte parser fields through 0x00531150, while 0x00412d70 can later clone a whole already-materialized candidate row through rep movsl, including those byte fields, before 0x00412f02 chooses the Port%02d/Warehouse%02d naming branch from the cloned [candidate+0xba] bit. So the live divergence frontier is narrower again: not generic direct stores into candidate rows, but the earlier seed or projection seam that first makes some source/live rows reach that clone path with nonzero bank bytes. The clone-group lane is tighter now too. Candidate dword [candidate+0x794] is not a broader owner-state field written elsewhere; the current direct write set shows it is initialized to zero in 0x004120b0 and then assigned only in 0x00412d70 as the chosen seed-row index that later clones should follow. The known consumers now line up with that meaning: 0x0041eba8 compares region-side row key [row+0x2f2] against [candidate+0x794], 0x004cccdc excludes candidates whose [candidate+0x794] already matches one active row key, and 0x0050a1cd keeps the same seeded rows out of one later availability branch. So the open question is not “who writes the mysterious group id?” but “which source/live rows become the first seeded rows that let 0x00412d70 propagate nonzero bank bytes within that family?” So the honest next queue head is now one step earlier again: recover the non-stock writer or restore-time projection owner that makes some live candidates reach those later consumer strips with nonzero [candidate+0xba/+0xbb] beyond the lone MachineShop.bca selector-window exception in the shipped BuildingTypes/*.bca corpus. 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 direct writer census is split more cleanly now too: 0x00421200 is the broad late-field constructor/reset zero-fill over the same 0x23a/0x23e/0x25a/0x25e/... row family and clears [+0x276] as part of that initialization, 0x00428270 is a collection-wide live owner remap over 0x0062b26c that rewrites [site+0x276] only for rows matching one old owner id, and 0x00422280 is a subtype-local synthetic scalar writer that stores one 100000 * rand(bucket) result into [+0x276] before publishing localized-id 7, so none of those three writes is the missing replay owner seam
  • 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 less ambiguous now too: the loader immediately after territory/support refresh, 0x00433130, is only scenario_event_collection_refresh_runtime_records_from_packed_state, opening 0x4e99/0x4e9a, repopulating live event collection 0x0062be18 through 0x0042db20, and closing 0x4e9b. So the event-side branch under 0x00444887 is ruled out as the missing later region restore handoff too.

• 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 early 0x004384d0 setup strip is tighter now too: before the conditional 320/321 gates it always runs 0x0044fb70 transport/pricing-grid setup and 0x0041ea50 candidate-local-service setup, and the extra arg-guarded 0x00421b60 -> 0x004882e0 default-region pair sits beside them as the last pre-320/321 setup branch. Those helpers are already grounded as world-grid, candidate-table, and border-refresh owners rather than the missing [region+0x2a4] / [region+0x310/+0x338/+0x360] republisher, so they drop out of the remaining region-handoff search too.

• 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 319 adjacency is tighter in another negative way now too. Direct disassembly of 0x004377a0 shows the post-319 call staying on chairman-slot/profile materialization: it normalizes the 16 slot bundles at [world+0x69da..], republishes selector bytes into [0x006cec7c+0x87], populates the live chairman-profile collection 0x006ceb9c, and clears the selected company/chairman bytes [world+0x21/+0x25] before the optional 0x0047d440 news follow-on. The same trace rules down the companion queue strip too: 0x004348e0 is only the gate for the transient list at [world+0x66a6], 0x00437c00 is its typed dispatcher over queue-node kind byte [node+0x08], and the later 0x0044d410 calls are world-rect/grid refresh work. None of those helpers republish [region+0x2a4] or [region+0x310/+0x338/+0x360], so the remaining region search stays centered on 0x004133b0 -> 0x0040ee10 -> 0x00480710 and the later post-load continuation above it rather than the chairman/queue-side 319 neighbors.

• The 319 plateau is split more cleanly now too: its neighboring world helpers are no longer plausible region-body owners. 0x00437220 and 0x004377a0 are the chairman-slot selector and profile materialization family over [world+0x69d8], [world+0x69db], and scenario selector bytes [0x006cec7c+0x87], while 0x00434d40 is only the subtype-2 candidate runtime-latch seeder over live placed structures. That leaves 0x004133b0 as the only region-adjacent 319 bridge worth chasing for the missing restore seam.

• The 320 branch is narrower than that headline now too: direct worker recovery shows 0x004235c0 staying inside the live region demand-and-placement family by routing through 0x00422900 cached category accumulation, 0x004234e0 projected structure-count scalars, 0x00422be0 placed-count subtraction, and 0x00422ee0 placement attempts over the live placed-structure registry 0x0062b26c. That keeps it on live setup and maintenance work rather than any restore-time republisher for [region+0x2a4] or [region+0x310/+0x338/+0x360].

• The 321 branch is narrower in the same way: 0x00437b20 only stages the fast-forward burst, then re-enters the live region collection through 0x00423d30, and that helper only republishes [region+0x27a/+0x27e/+0x282/+0x286] via 0x00422900. It should stay ruled down as a cached summary refresh instead of a plausible owner for the missing restore-side body lanes.

• 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.