# Runtime Effect Kind-8 Tier2 Setup Core Note This note records the current setup-payload-core comparison across the six bundled add-building carrier maps: - `Alternate USA.gmp` - `Chicago to New York.gmp` - `Louisiana.gmp` - `Pacific Coastal.gmp` - `Rhodes Unfinished.gmp` - `Texas Tea.gmp` The comparison uses the checked `compare-setup-payload-core` surface. ## Immediate result The upstream setup payload already differs across the carrier set. Observed differing fields: - `payload_word_0x14` - `payload_byte_0x20` - `payload_word_0x3b2` - `candidate_header_word_0_hex` - `candidate_header_word_1_hex` ## Carrier-set shape Current `payload_word_0x3b2` values: - `Alternate USA.gmp = 1` - `Chicago to New York.gmp = 2` - `Louisiana.gmp = 2` - `Pacific Coastal.gmp = 1` - `Rhodes Unfinished.gmp = 1` - `Texas Tea.gmp = 3` That means `Louisiana.gmp` is **not** unique on `payload_word_0x3b2`. Current candidate-header word pairs: - `Alternate USA.gmp = 0x10000000 / 0x00009000` - `Chicago to New York.gmp = 0x00000000 / 0x00000000` - `Louisiana.gmp = 0xcdcdcdcd / 0xcdcdcdcd` - `Pacific Coastal.gmp = 0x00000000 / 0x00000000` - `Rhodes Unfinished.gmp = 0x00000000 / 0x00000000` - `Texas Tea.gmp = 0x00000000 / 0x00000000` So `Louisiana.gmp` is currently unique among the shipped carrier set on the candidate-header sentinel pair, while `Alternate USA.gmp` stays separately unique on the recognized `rt3-105-map-container-v1` header pair. ## Wider map-corpus check A wider `compare-setup-payload-core` pass over all 41 bundled `rt3_105/maps/*.gmp` files changes the candidate-header read materially: - `(0x00000000, 0x00000000)` appears on 31 maps - `(0xcdcdcdcd, 0xcdcdcdcd)` appears on 9 maps - `(0x10000000, 0x00009000)` appears only on `Alternate USA.gmp` Current `0xcdcdcdcd / 0xcdcdcdcd` maps in that wider corpus: - `Argentina Opens Up.gmp` - `Britain.gmp` - `Crossing the Alps.gmp` - `Greenland Growing.gmp` - `Japan Trembles.gmp` - `Louisiana.gmp` - `Pacific NW.gmp` - `South East Australia.gmp` - `Spanish Mainline.gmp` So the candidate-header sentinel pair is no longer a plausible `Louisiana`-specific upstream explanation by itself. That wider read also matches the already checked atlas note in `post-load-generation-paintterrain-and-save-load-restore.md`: the candidate-availability table header scan had already narrowed the visible family to those same three stable `(header_word_0, header_word_1)` pairs, with the `0xcdcdcdcd` class behaving like reused source-family framing rather than a direct availability payload or a unique scenario-side trigger. One narrower outlier still survives that wider scan: - no other bundled `rt3_105` map matches the full current `Louisiana.gmp` setup-core tuple `payload_word_0x14 = 1870`, `payload_byte_0x20 = 0x3a`, `payload_word_0x3b2 = 2`, `candidate_header = 0xcdcdcdcd / 0xcdcdcdcd` - the two fields on the currently grounded Tier 2 bridge split differently in the wider corpus: - `payload_byte_0x20 = 0x3a` is unique to `Louisiana.gmp` - `payload_word_0x14 = 1870` has only one peer, `Mexico.gmp` - even the nearest header-class peers still diverge: - `Argentina Opens Up.gmp`: same header pair, but `payload_word_0x14 = 1880`, `payload_byte_0x20 = 0x57`, `payload_word_0x3b2 = 1` - `Crossing the Alps.gmp`: same header pair, but `payload_word_0x14 = 1875`, `payload_byte_0x20 = 0x8f`, `payload_word_0x3b2 = 1` - `Spanish Mainline.gmp`: same header pair, but `payload_word_0x14 = 1876`, `payload_byte_0x20 = 0xe3`, `payload_word_0x3b2 = 1` ## Known owner path for the compared fields The named consumer path for the compared setup-core fields is now bounded too: - `0x00442400` `shell_setup_load_selected_profile_bundle_into_payload_record` materializes the larger setup payload record from the map-style chunk family - `0x00502220` `shell_setup_window_publish_selected_profile_labels_and_preview_surface` then copies the small compared field set through - `0x0047be50` `shell_setup_profile_copy_payload_scroll_count_and_campaign_byte_and_seed_row_categories` That grounded copy path currently lands on staged runtime-profile fields, not on the Tier 2 candidate rebuild strip directly: - payload `+0x14 -> [profile+0x77]` - payload `+0x3b2 -> [profile+0x79]` - payload `+0x3ba -> [profile+0x7b]` - payload `+0x20 -> [profile+0xc5]` That setup/profile bridge is not the end of the path, though. The later scenario reset or reactivation owners already import a subset of those staged values back into the live world before the coupled Tier 2 rebuild strip runs: - `0x00436d10` `scenario_state_reset_defaults_seed_named_availability_collections_and_rebuild_runtime_bridges` checks `[profile+0xc5]` and, when the setup-not-sandbox branch is active, copies `[profile+0x77]` into the selected-year world lanes before rerunning `0x00435603`, `0x00435630`, `0x0041e970`, `0x00412bd0`, `0x00434130`, and `0x00436af0` - `0x00443a50` `world_entry_transition_and_runtime_bringup` mirrors `[profile+0xc5]` into `[world+0x66de]`, restores the selected-year lane from `[profile+0x77]`, and then re-enters the same rebuild family in the load-side rehydrate band So the bridge is now narrower and more concrete: - setup payload `+0x14 -> [profile+0x77] -> selected-year restore -> Tier 2 rebuild family` - setup payload `+0x20 -> [profile+0xc5] -> campaign/setup gate -> world-entry/reset branch` - setup payload `+0x3b2/+0x3ba -> [profile+0x79/+0x7b]` are still only grounded on the setup-side panel and scroll-threshold path, not yet on the later Tier 2 rebuild owners The `+0x20` side is tighter in a second way too. Current grounded downstream consumers of the mirrored world byte `[world+0x66de]` are mostly: - the editor metadata checkbox or campaign-scenario flag path - the campaign-gated branches inside `0x00442c30 shell_apply_scenario_name_specific_post_load_world_and_object_fixups` The currently grounded Tier 2 relevance of `+0x20` therefore reads more like a branch gate on the selected-year/reactivation path inside `0x00436d10 / 0x00443a50`, not like a later direct input to `0x00435630 / 0x00412bd0 / 0x00412c10` through the ordinary `[world+0x66de]` consumer set. That bridge weakens one step further on the profile side: - `0x00436d10` currently only checks `[profile+0xc5] != 0` - the validated launch helper `0x004425d0` force-stages `[profile+0xc5] = 1` - the campaign-side launch branch also forces `[profile+0xc5] = 1` So the unique raw setup payload byte `+0x20 = 0x3a` in `Louisiana.gmp` is **not** currently a grounded unique numeric input to the Tier 2 strip. On the current evidence it most likely collapses to the ordinary nonzero campaign/setup branch before `0x00436d10 / 0x00443a50` run. That makes the setup-side bridge weaker than it first looked: - the `+0x20` side is still relevant as a branch gate, but not yet as a unique preserved value - the `+0x14` selected-year side remains the only currently grounded preserved setup-side scalar on the bridge That means the next upstream question is now smaller than before: - whether `Louisiana.gmp`'s unique `+0x14/+0x20` setup-core pair is enough to explain its coupled Tier 2 runtime shape through the already-grounded `[profile+0x77/+0xc5]` bridge - or whether the remaining differentiator still sits elsewhere, most likely in the sparse recipe/runtime side rather than the setup-panel-only `+0x3b2/+0x3ba` pair ## Adjacent setup-launch cross-check One adjacent setup-side comparison also stays divergent rather than collapsing the `Louisiana` outlier into one easy peer group: - `compare-setup-launch-payload` over `Louisiana.gmp`, `Mexico.gmp`, `Argentina Opens Up.gmp`, `Crossing the Alps.gmp`, `Spanish Mainline.gmp`, and `Chicago to New York.gmp` shows no shared launch-flag or token-block signature with `Louisiana.gmp` - `Louisiana.gmp` carries - `launch_flag_byte_0x22 = 0x8f` - `launch_token_block_0x23_0x32 = 0012918f000000000000000000000000` - nonzero selector values only for `Central Pacific = 145`, `Germantown = 18`, `Texas Tea = 143` - all five comparison maps diverge on that launch-side signature, even when they are near peers on the setup-core or candidate-header side That does **not** yet make the launch-token band part of the grounded Tier 2 bridge. Current atlas evidence still only grounds the direct Tier 2 bridge through setup payload `+0x14/+0x20` into `[profile+0x77/+0xc5]`, then through `0x00436d10 / 0x00443a50`. But it does make the upstream picture less likely to collapse to one trivial peer class before that bridge. ## Bridge-peer recipe check The only wider-corpus peer on the selected-year side of the bridge is `Mexico.gmp`, which shares `payload_word_0x14 = 1870` but not the unique `payload_byte_0x20 = 0x3a`. `compare-recipe-book-lines Louisiana.gmp Mexico.gmp` keeps the recipe/runtime split sharp: - `Louisiana.gmp` keeps a nonzero `book00` profile - `book00.line02 mode = 0x00080000` - `book00.line02 supplied token = 0x00004080` - `book00.line00/line01` demanded tokens nonzero - `Mexico.gmp` stays zero across the whole checked recipe-book surface So the only current `+0x14` bridge peer does **not** reproduce the sparse `Louisiana` recipe profile. That keeps the recipe/runtime side as the stronger remaining differentiator even after the setup bridge was narrowed to `+0x14/+0x20`. ## Current implication The upstream side of the Tier 2 strip is now bounded more tightly: - the current `Louisiana.gmp` recipe/runtime outlier status is not explained by `payload_word_0x3b2` alone, because `Chicago to New York.gmp` also carries `2` - and `Louisiana.gmp` no longer stands out on the candidate-header sentinel pair once the broader 41-map corpus is included - but `Louisiana.gmp` still keeps a unique combined setup-core tuple once the broader corpus is included So the next Tier 2 upstream question is narrower: - whether `Louisiana.gmp`'s remaining upstream setup-core outlier is a more specific combination of `payload_word_0x14`, `payload_byte_0x20`, and the sparse recipe/runtime profile, rather than the coarse candidate-header class itself, in the coupled `0x00435630 / 0x00412d70 / 0x00412fb0 / 0x00412c10` rebuild strip.