# 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 carries those stable families explicitly:
  `port00_warehouse00_row_pair_map_counts` keeps the `35/43 -> 30 maps` versus `10/18 -> 7 maps`
  split visible directly, `port00_warehouse00_row_pair_map_paths` keeps the carrier maps checked
  in, and the same export also keeps `files_with_port01_11_run_at_45_55_count = 37` plus
  `files_with_warehouse01_11_run_at_56_66_count = 37` across the whole probe-bearing corpus.
- the same export now keeps the row/trailer crossover explicit too:
  `row_pair_and_numbered_trailer_family_map_counts` records
  `35/43 :: 0x00000001 -> 25 maps`, `35/43 :: 0x00000000 -> 5 maps`,
  `10/18 :: 0x00000000 -> 4 maps`, and `10/18 :: 0x00000001 -> 3 maps`, so the off-row family
  does not collapse to one numbered trailer lane.

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\`
- the trailer split is checked in directly too: the same export's
  `numbered_port_warehouse_trailer_family_map_counts` keeps the `0x00000001 -> 28 maps` versus
  `0x00000000 -> 9 maps` split on the fixed `Port01..11` / `Warehouse01..11` rows visible without
  reopening per-map samples
- 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