rrt/artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-setup-core-note.md

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