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.