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

Runtime Effect Kind-8 Tier2 Named Availability Note

This note records the current named-candidate availability comparison between the strongest title-overlap pair:

• Louisiana.gmp
• Dutchlantis.gmp

The comparison uses the checked rt3_105_save_name_table_probe surface from inspect-smp.

Immediate Result

Warehouse05 is not the differentiator.

Observed values:

• Warehouse05
  • Louisiana.gmp = 1
  • Dutchlantis.gmp = 1
• Port01
  • Louisiana.gmp = 1
  • Dutchlantis.gmp = 1
• Furniture Factory
  • Louisiana.gmp = 1
  • Dutchlantis.gmp = 1
• FarmGrain
  • Louisiana.gmp = 1
  • Dutchlantis.gmp = 1
• Logging Camp
  • Louisiana.gmp = 1
  • Dutchlantis.gmp = 1

So the strongest current Louisiana -> Dutchlantis title overlap does not also come with a unique Warehouse05 availability toggle that would directly explain the one-row Add Building Warehouse05 dispatch cluster in Louisiana.gmp.

Full Named-Availability Differences

The current comparison shows 18 differing names:

• AluminumMill: Louisiana = 0, Dutchlantis = 1
• AutoPlant: Louisiana = 0, Dutchlantis = 1
• Bauxite Mine: Louisiana = 0, Dutchlantis = 1
• Chemical Plant: Louisiana = 0, Dutchlantis = 1
• Farm Corn: Louisiana = 1, Dutchlantis = 0
• FarmCotton: Louisiana = 1, Dutchlantis = 0
• FarmRice: Louisiana = 1, Dutchlantis = 0
• FarmSheep: Louisiana = 0, Dutchlantis = 1
• FarmSugar: Louisiana = 1, Dutchlantis = 0
• Fertilizer Factory: Louisiana = 0, Dutchlantis = 1
• Iron Mine: Louisiana = 0, Dutchlantis = 1
• Nuclear Power Plant: Louisiana = 0, Dutchlantis = 1
• Oil Refinery: Louisiana = 1, Dutchlantis = 0
• Plastics Factory: Louisiana = 0, Dutchlantis = 1
• Recycling Plant: Louisiana = 0, Dutchlantis = 1
• Steel Mill: Louisiana = 0, Dutchlantis = 1
• Tool And Die: Louisiana = 0, Dutchlantis = 1
• Uranium Mine: Louisiana = 0, Dutchlantis = 1

The broader compare-candidate-table surface agrees with the same conclusion:

• common semantic family remains scenario-named-candidate-availability-table
• Warehouse05 stays 1 / 1
• difference_count = 43, but those differences are still driven by the wider industrial mix, header words, and the zero-trailer-name set rather than by any unique Warehouse05 bit

Current Export Join

The checked-in Tier-2 evidence set now joins three canonical exports directly:

• artifacts/exports/rt3-1.06/building-type-sources.json
• artifacts/exports/rt3-1.06/event-effects-building-bindings.json
• artifacts/exports/rt3-1.06/candidate-table-named-runs.json

Taken together they keep the current frontier narrow and concrete:

• building-type-sources.json still shows the stock Data/BuildingTypes corpus only owns the bare source stems port and warehouse; the numbered port00..11 / warehouse00..11 families remain binding-only canonical stems rather than stock numbered assets.
• event-effects-building-bindings.json is still the checked event-side naming surface that proves those numbered Port%02d / Warehouse%02d families matter to runtime dispatch.
• candidate-table-named-runs.json now shows the shipped 37 probe-bearing maps split into two stable 00-row families while keeping Port01..11 fixed at rows 45..55 and Warehouse01..11 fixed at rows 56..66 in every probe-bearing map.

So the open question is no longer whether the numbered families exist in stock assets, bindings, or shipped candidate tables. The real remaining question is which earlier seed/projection seam lets that fixed candidate-table cluster reach 0x00412d70 with nonzero bank-qualified state before 0x00419230 ever clones or renames it.

Current Implication

The Tier 2 candidate/world-state rebuild strip remains plausible in general because it owns named candidate availability seeding and refresh, but the current evidence no longer supports the narrow claim that Louisiana.gmp gets its Add Building Warehouse05 row from a unique Warehouse05 availability difference relative to Dutchlantis.gmp.

Two deeper grounded notes tighten that further:

• structure_candidate_collection_rebuild_runtime_records_from_scenario_state 0x00412d70 does not consult the scenario-side recipe-book name at [state+0x0fe8]; it formats the rebuilt candidate display stem from one of two fixed built-in roots 0x005c93d8 or 0x005c93e8 plus the current ordinal.
• scenario_state_upsert_named_candidate_availability_record_and_refresh_runtime_filters 0x00434f20 now reads safely as a real boolean availability override writer rather than a wider mode enum.

So the next Tier 2 recovery question is now tighter still:

• whether the relevant difference is in broader candidate-state rebuild sequencing, latch refresh, or cargo-membership/runtime-record reconstruction under 0x00437737 / 0x00412c10 / 0x00412bd0 / 0x00412d70 / 0x00412fb0, rather than in the direct named availability bit for Warehouse05 itself.

Nearest Single-Import Peer Check

The same boundary now holds against the nearest single-import recipe peer too:

• Louisiana.gmp
• South East USA.gmp

Direct inspect-candidate-table checks still keep the key port/warehouse rows aligned:

• Warehouse05
  • Louisiana.gmp = 1
  • South East USA.gmp = 1
• Port01
  • Louisiana.gmp = 1
  • South East USA.gmp = 1

So even after the recipe-side frontier moved from “same coarse mode shape” to “same single-import family,” the direct named-availability table still does not provide the missing Tier 2 split for the shipped 5200 :: [7:0] Add Building Warehouse05 row.

That leaves the same later owners as the honest next focus:

• 0x00412d70 template-bank and runtime-record rebuild
• 0x00411ce0 / 0x00411ee0 dependent mode-flag and cargo-summary refresh
• 0x00412c10 latch refresh after those runtime records already exist

Port Versus Warehouse Runtime Roots

One broader binary pass now closes the fixed-root ambiguity inside 0x00412d70.

Direct objdump over RT3.exe shows the two built-in format roots are:

• 0x005c93d8 = "Warehouse%02d"
• 0x005c93e8 = "Port%02d"

And the candidate rebuild chooses between them exactly as:

• if [candidate+0xba] != 0
  • use Port%02d
• else
  • use Warehouse%02d

So the later Tier 2 runtime-record frontier is no longer an abstract “two built-in roots” question. It is specifically:

• how 0x00412d70 bank or template selection and the live availability bytes [candidate+0xba/+0xbb] determine which rebuilt candidates land on the Warehouse%02d side versus the Port%02d side
• and why the Warehouse%02d side in Louisiana.gmp is the one that later lines up with the shipped 5200 :: [7:0] Add Building Warehouse05 strip

That also keeps the direct named-availability boundary honest:

• Warehouse05 = 1 in the fixed scenario table still does not explain the runtime split by itself
• the next meaningful owner seam is the later port-versus-warehouse runtime-record rebuild under 0x00412d70, before 0x00412c10 mirrors anything into [candidate+0x7ac]

Writer-Side Split Above The Availability Bytes

One more direct disassembly pass narrows that owner seam further.

structure_candidate_stream_load_runtime_record_and_rebuild_cargo_state 0x004120b0 does rebuild a substantial portion of each live candidate record:

• clears dependent runtime pointers and flags such as [candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0]
• reads the fixed per-record stream fields at [candidate+0x04/+0x22/+0x26/+0x28/+0x2a/+0x2e/+0x32/+0x33]
• restores the selector-bank bytes [candidate+0xb9/+0xba/+0xbb]
• allocates and streams the packed 0xbc descriptor array into [candidate+0x37]

So the current strongest ownership split is now:

• direct named-availability table [state+0x66b2] is not the missing differentiator by itself
• both source-record import 0x00414490 and per-record stream-load 0x004120b0 do carry the relevant selector-bank bytes from persisted/source state into the live candidate family
• but the stock Data/BuildingTypes/*.bca corpus currently keeps [record+0xb8/+0xb9/+0xba/+0xbb] at zero across every observed file, including Warehouse.bca and Port.bca
• so the surviving frontier is no longer “does the lower loader import [candidate+0xba/+0xbb]?” but rather which later owner or alternate content path makes the live bank-qualified split differ from that all-zero shipped BCA corpus before 0x00412d70 clones or reuses one bank-qualified live candidate

That makes the next Tier 2 question more concrete still:

• how any nonzero bank-qualified template source under [candidate+0xba] versus [candidate+0xbb] is actually seeded above the stock all-zero BCA corpus, and then drives the later Warehouse%02d side in Louisiana.gmp
• and whether that preserved bank/template state is the real bridge from the minimal recipe cluster to the shipped 5200 :: [7:0] Add Building Warehouse05 row
• and, more concretely, which earlier seed/projection seam lets candidate-table rows 35/43/45..66 reach 0x00412d70 with nonzero [candidate+0xba/+0xbb] before the later rebank-or-clone owner 0x00419230 consumes them

Later Consumer-Side Reads Already Narrowed

One broader non-hook pass now rules several tempting later neighbors onto the consumer side rather than the missing writer or projection seam.

• aux_candidate_collection_rebank_or_clone_records_by_availability_pass_and_refresh_owner_links 0x00419230 does not seed [candidate+0xba/+0xbb] into the live candidate pool. It walks the already-imported auxiliary/source pool at 0x0062b2fc, selects template records only when the linked live owner candidate at [entry+0x173] already passes the current bank test (+0xba on pass 0, +0xbb on pass 1), and then clones or reuses auxiliary entries before stamping the built-in Port%02d / Warehouse%02d roots back into [entry+0x22] and [entry+0x04].
• world_grid_refresh_projected_rect_sample_band_and_flag_mask 0x00418610 is also only a consumer of the same candidate-bank state. It resolves the current candidate through helper accessors, uses candidate[0xba] and the subtype/class predicates as mode inputs for the projected-rectangle sample pass, and never writes the candidate bank bytes.
• the broader projected-offset lane at 0x0041a5fd..0x0041a944 is the same shape: after geometric reuse tests it resolves the current candidate owner, immediately branches on candidate[0xba], and then either runs one world-cell occupancy sweep or falls back to localized status strings. Current direct disassembly still shows this path consuming the bank byte as a gate, not reconstructing it.

So the surviving frontier is narrower again:

• 0x00414490, 0x004120b0, and the shipped BuildingTypes/*.bca corpus explain how the stock zero bank bytes enter the source and live candidate families
• 0x00419230, 0x00418610, and 0x0041a5fd..0x0041a944 explain how later auxiliary and projected-placement consumers react to already-materialized bank bytes
• the .smp restore-side auxiliary temp-bank path is ruled out as a hidden bank-byte source too: 0x00413f80 restores queued temporary images with scalar runs, inline dword runs, and paired byte streams, but not the auxiliary fixed body or selector bytes [+0xb8..+0xbb]; and 0x0041a950, when the restore flags demand it, only releases the current live aux collection and tail-jumps back into the same 0x004196c0 -> 0x00419230 import-plus-follow-on chain
• the world-entry load branch does not add a hidden title-specific selector in between either: 0x00438c70 allocates the live candidate pool through 0x004131f0 and the auxiliary/source pool through 0x0041aa50, and both constructors tail directly into the same fixed tagged-import families rooted at 0x005c93fc and .\Data\BuildingTypes\
• but the still-missing owner is the earlier non-stock writer or restore-time projection seam that makes some live candidates reach those later consumers with nonzero [candidate+0xba/+0xbb] despite the observed all-zero BCA corpus