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

Runtime Effect Kind-8 Tier2 Recipe Runtime Note

This note summarizes the checked subgraph artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-recipe-runtime-subgraph.md, seeded from:

• 0x00435630
• 0x00412d70
• 0x00412fb0

High-level shape

The current Tier 2 recipe/runtime strip is one tightly coupled rebuild family, not a set of independent helpers.

Important bounded relationships:

• 0x00435630
  • rebuilds scenario-side port/warehouse cargo recipe runtime tables
  • re-enters 0x00412d70
• 0x00412d70
  • rebuilds candidate runtime records from scenario state
  • re-enters 0x00435630
  • also re-enters 0x00411ce0 and 0x00411ee0
• 0x00412fb0
  • broader collection-load owner
  • re-enters 0x004120b0
  • then 0x00412d70
  • then 0x00412ab0
  • then 0x00412c10

So the current recipe/runtime strip is not a simple one-way ladder. It is a coupled rebuild loop:

• recipe runtime rebuild
• candidate runtime-record rebuild
• per-record stream-load rebuild
• later named-availability latch refresh

Neighboring owners

The same bounded subgraph also shows the relevant downstream and side owners:

• named availability / cargo-economy side:
  • 0x00412c10
  • 0x0041eac0
  • 0x00434ea0
  • 0x00434f20
• broader load / bringup side:
  • 0x004131f0
  • 0x004384d0
  • 0x00443a50

Current implication

This supports the current Tier 2 bias:

• the shipped add-building carrier differences are more likely to live in the interaction between recipe rebuild, candidate runtime-record rebuild, and later availability-latch refresh
• not in one isolated helper or one isolated named-availability bit

So the next recovery pass should target the internal sequencing and data handoff across:

• 0x00435630
• 0x00412d70
• 0x00412fb0
• 0x00412c10

rather than returning to the title overlap or direct Warehouse05 availability question.