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

# Runtime Effect Kind-8 Tier2 Sequencing Note

This note extracts the current late bringup sequencing around the Tier 2
candidate/world-state rebuild strip beneath
`world_entry_transition_and_runtime_bringup` `0x00443a50`.

## Earlier recipe-runtime rebuild checkpoint

The earlier post-load recipe-runtime rebuild call at `0x00443ebc` runs:

- immediately after the named candidate-availability collection at `[world+0x66b2]`
  has been restored from fixed `0x22`-byte rows
- by directly calling `0x00435630`
- then calling `0x00412c10` only if live candidate pool `0x0062b268` is non-null
- before the neighboring candidate filter/count rebuilds
  `0x00412c10 / 0x00412bd0`
- before the year-derived follow-ons
  `0x00434130 / 0x00436af0`

That means the earlier checkpoint is already candidate/world rebuild work, not the final
kind-`8` materializer by itself.

## Later `0x197` checkpoint

The later explicit `0x197` checkpoint at `0x00444ac1` sits:

- after `world_publish_shell_controller_progress_scalar_from_year_thresholds_or_selector_overrides`
  `0x004354a0`
- after the territory-side sweep
  `world_region_border_overlay_emit_segment_geometry_from_region_grid`
  `0x00487de0`
- and then directly reruns `0x00435630`
- then falls through into
  `world_preseed_named_candidate_availability_records_from_live_pool`
  `0x00437737`
- followed by the later unconditional candidate-side availability refresh
  `0x00412c10`
- and then `0x00434d40`

So the late Tier 2 strip begins with named-availability preseed and latch refresh, not with the
shell progress or territory overlay helpers that precede it, and it ends with one extra subtype-`2`
mark pass rather than stopping at the named-availability latch refresh.

## Internal Tier 2 rebuild relationships

Current grounded internal relationships:

- `0x00437737`
  - pre-seeds scenario-side named candidate availability records from the live pool
  - upserts records through `0x00434f20`
- `0x00434f20`
  - writes a boolean named-availability override bit
  - immediately re-enters `0x00412c10` when the live candidate pool exists
- `0x00412c10`
  - refreshes `[candidate+0x7ac]` from named availability and then tails into
    cargo-economy filter refresh `0x0041eac0`
- `0x00435630`
  - rebuilds port/warehouse recipe runtime tables from scenario-side recipe books
  - then re-enters `0x00412d70`
- `0x00412d70`
  - rebuilds candidate runtime records from scenario state
  - runs two explicit bank passes, first on nonzero `[candidate+0xba]` rows and then on nonzero
    `[candidate+0xbb]` rows
  - picks one availability-qualified seed row and either reuses or clones its full `0x1f2`-dword
    body into the rebuilt numbered record
  - does not consult the scenario-side recipe-book name at `[state+0x0fe8]`
- `0x00412fb0`
  - broader collection load owner that directly loops through `0x004120b0`, then calls
    `0x00412d70`, then `0x00412ab0`, and only after its later catalog rebuild re-enters
    `0x00412c10`
  - `0x004120b0` itself explicitly reads selector bytes `[candidate+0xba/+0xbb]` from the stream
- `0x00434d40`
  - late post-refresh sweep over collection `0x0062b26c`
  - sets `[entry+0x7b0] = 1` for subtype-`2` rows

## Current recovery implication

The strongest remaining Tier 2 question is sequencing, not naming:

- whether the shipped `Add Building Warehouse05` row in `Louisiana.gmp`
  depends on the order or interaction of
  `0x00437737 -> 0x00434f20 -> 0x00412c10`
  versus
  `0x00435630 -> 0x00412d70`
  and the broader load-side rebuild owner
  `0x00412fb0`,
  with `0x004120b0` now grounded as the loader that reads `[candidate+0xba/+0xbb]` and
  `0x00412d70` grounded as the immediate two-pass consumer of those bytes,
  with the early checkpoint only conditionally refreshing `0x00412c10` but the late checkpoint
  always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10 -> 0x00434d40`,
  rather than on a direct `Warehouse05` availability bit or recipe-book display-name leak.