rrt/docs/rehost-queue/periodic-company-control-lane-2026-04-21.md

# Periodic Company Control Lane (2026-04-21)

This note preserves the checked evidence behind the current periodic-company queue head, so the
short queue can stay focused on the remaining owner question.

## Checked Export

- `artifacts/exports/rt3-1.06/compact-event-dispatch-cluster-counts.json`

Current checked corpus totals:

- `maps_scanned = 41`
- `maps_with_dispatch_strip_rows = 38`
- `dispatch_strip_record_count = 318`
- `dispatch_strip_records_with_trigger_kind = 0`
- `add_building_dispatch_record_count = 10`

The add-building subset is still only `7` descriptor keys:

- `Barracks`
- `Bauxite Mine`
- `FarmGrain`
- `Furniture Factory`
- `Logging Camp`
- `Port01`
- `Warehouse05`

## Concrete Carrier Maps

The checked export already keeps the strongest carrier maps visible:

- `Texas Tea.gmp` for `548 Add Building Port01`
- `Louisiana.gmp` for `563 Add Building Warehouse05`
- `Alternate USA.gmp` for the repeated `FarmGrain` / `Logging Camp` `ge34` family
- `Chicago to New York.gmp` and `Pacific Coastal.gmp` for the mixed `[-1:4]` cluster

The widened full-corpus cluster surface now keeps the strongest non-add-building families visible
too:

- `dispatch_signature_condition_cluster_occurrence_counts`
  - `36` for `nondirect-ge1e-h0001-0360-0004-0100-0200-p0000-0000-0000-ffff :: [864:4]`
  - `27` for `nondirect-ge1e-h0001-ffff-0004-0000-0200-p0000-0000-0000-ffff :: [-1:4]`
- `dispatch_signature_condition_cluster_descriptor_keys`
  - the `36`-occurrence cluster is the broader variable/status family over
    `Economic Status` plus `Game/Company Variable 1..4`
  - the `27`-occurrence `[-1:4]` cluster still mixes those variable families with the two checked
    add-building descriptors `Barracks` and `Bauxite Mine`
- `dispatch_signature_condition_cluster_map_paths`
  - the `36`-occurrence cluster spans `18` maps including `Britain.gmp`,
    `Chicago to New York.gmp`, `Crossing the Alps.gmp`, and `Eastern China.gmp`
  - the `27`-occurrence `[-1:4]` cluster spans `14` maps including `Alternate USA.gmp`,
    `Chicago to New York.gmp`, `Coast to Coast.gmp`, and `Go West!.gmp`
- the checked periodic-company trace now mirrors the strongest four of those full-corpus families
  directly through
  `near_city_acquisition_nontransport_top_dispatch_signature_condition_clusters`, so the active
  queue head is no longer backed only by the export file

## Top Cluster Carrier Sets

The checked export now keeps the two strongest ordinary nondirect families concrete enough to cite
without reopening the full JSON:

- `nondirect-ge1e-h0001-0360-0004-0100-0200-p0000-0000-0000-ffff :: [864:4]`
  - descriptor family is only `Economic Status` plus `Game/Company Variable 1..4`
  - carrier maps are:
    `Britain.gmp`, `Central Pacific.gmp`, `Chicago to New York.gmp`,
    `Crossing the Alps.gmp`, `Eastern Canada.gmp`, `Eastern China.gmp`, `Go West!.gmp`,
    `Italy.gmp`, `Japan Trembles.gmp`, `Louisiana.gmp`, `Mexico.gmp`,
    `Mississippi Valley.gmp`, `New Beginnings.gmp`, `Orient Express.gmp`,
    `South East USA.gmp`, `Southern Pacific.gmp`, `Spanish Mainline.gmp`, and `Tex-Mex.gmp`
- `nondirect-ge1e-h0001-ffff-0004-0000-0200-p0000-0000-0000-ffff :: [-1:4]`
  - descriptor family still mixes the variable lanes with `506 Add Building Barracks` and
    `507 Add Building Bauxite Mine`
  - carrier maps are:
    `Alternate USA.gmp`, `Central Pacific.gmp`, `Chicago to New York.gmp`,
    `Coast to Coast.gmp`, `Go West!.gmp`, `Greenland Growing.gmp`, `Japan Trembles.gmp`,
    `New Beginnings.gmp`, `Pacific Coastal.gmp`, `Pacific NW.gmp`, `Rhodes Unfinished.gmp`,
    `Southern Pacific.gmp`, `State of Germany.gmp`, and `War Effort.gmp`

So the active control-lane frontier is no longer “there are one or two sample maps with late
ordinary nondirect rows.” The checked corpus now preserves the full map families on both of the
strongest recurring nondirect clusters.

## Grounded Boundary

The active strip is still:

- `0x00444d92 -> 0x00432f40(kind 8) -> 0x004323a0 -> 0x00431b20`

The checked boundary around that strip is now narrow:

- ordinary loaded nondirect rows already reach the `0x00431b20` mutation strip at scale
- the export still shows no recovered trigger kind for any of those checked rows
- the remaining question is therefore not whether ordinary loaded rows can reach the compact
  dispatch strip, but where they acquire or bypass the missing trigger-kind control lane before
  placed-structure mutation opcodes run

## Closest Already-Grounded Retags

The checked periodic-company service trace now also exposes these grounded control-lane neighbors
directly through:

- `near_city_acquisition_nontransport_late_bringup_candidate_branches`
- `near_city_acquisition_nontransport_explicit_trigger_kind_retags`

The current artifact notes and trace now agree on the same two explicit late retag writers away
from ordinary reload:

- `SP - GOLD` branch at `0x00443526`
  - rewrites `[event+0x7ef]` from `1 -> 5`
- `Labor` branch at `0x00443601`
  - rewrites `[event+0x7ef]` from `0 -> 2`

So the next non-hook question stays above those already-known title or scenario-specific retags:

- which late bringup branch between ordinary reload `0x00433130` and final kind-`8` service
  `0x00432f40` materializes the live mutation-capable ordinary rows

## Scenario-Name Fixup Bound

The broad scenario-name post-load fixer is narrower now too:

- `0x00442c30`
  - definitely mutates live event rows in collection `0x0062be18` before the late kind-`8`
    service
  - but the grounded event-side trigger-kind writes there are still only:
    - `0x00443526`: event row `1`, `1 -> 5`
    - `0x00443601`: event row `0x0d`, `0 -> 2`
  - the other surfaced event-side branches around `0x004436ca`, `0x004438e8`,
    `0x00443948`, and `0x004439a8` only patch modifier bytes or payload fields under already
    existing trigger kinds `6`, `5`, `1`, `1`, `2`, `3`, or `9`
- no grounded branch inside `0x00442c30` seeds `[event+0x7ef] = 8`

So the active shellless control-lane question is narrower again:

- `0x00442c30` is a real event-side post-load mutator
- but it still does not explain how ordinary loaded rows acquire the later world-entry kind `8`
  gate

## Direct Trigger-Kind Gate

Fresh `objdump` over the control-lane strip now keeps the missing trigger-kind boundary concrete:

- `0x00444d92`
  - calls `0x00432f40` with trigger kind `8`
  - then clears shell-profile latch `[0x006cec7c+0x97]`
- `0x00432f40`
  - iterates the live runtime-effect collection
  - calls `0x004323a0` once per row with the requested trigger kind
  - records whether any row fired
  - if collection flag `[this+0x88]` is raised, reruns the same service loop with trigger kind
    `0x0a`
- `0x004323a0`
  - returns immediately unless `[event+0x81f] == 0`
  - returns immediately unless `[event+0x7ef] == trigger_kind`
  - only after that exact trigger-kind compare does it continue toward the compact dispatch body

So the current blocker is no longer “is trigger kind really a direct gate?” It is: where ordinary
loaded rows get a nonzero `[event+0x7ef]` that matches the later `0x00432f40(kind 8)` or follow-on
`kind 0x0a` service.

## Wider Caller Census

The collection-wide dispatcher above that gate is broader than the narrow queue head alone:

- the recurring simulation-maintenance strip at `0x0040a220..0x0040a9ac` already drives:
  - kind `1` at `0x0040a276`
  - kind `0` at `0x0040a55f`
  - kind `3` at `0x0040a6cb`
  - kind `2` at `0x0040a7a3`
  - kind `5` at `0x0040a930`
  - kind `4` at `0x0040a9ac`
- the kind-`7` family is already grounded too:
  - `0x00407682`
  - `0x0047d293`
  - `0x0047d42b`
  - `0x0047d6de`
- the kind-`6` family is also wider than one site-local branch:
  - placed-structure post-create tail `0x0040f69e`
  - build-version-gated startup or roster-refresh tail `0x00428406`
  - route-entry post-change sweep `0x004a3eae`
- kind `9` is the `LoadScreen.win` briefing query at `0x004e520b`
- kind `8` still sits only in the late world-entry one-shot at `0x00444d92`

So the active control-lane question is narrower again:

- `0x00432f40` is not a missing shellless service entrypoint
- ordinary runtime-effect rows are already swept under many grounded trigger kinds `0..7` plus the
  special briefing kind `9`
- the unresolved seam is why ordinary loaded rows still do not present a matching nonzero
  `[event+0x7ef]` when that later world-entry kind-`8` sweep runs

## Reload-Side Boundary

The ordinary reload path is narrower in the same negative way now too:

- `0x00433130`
  - restores tagged record families `0x4e99`, `0x4e9a`, and `0x4e9b`
  - reads one fixed `4`-byte scalar block through `0x00531150`
  - loops live rows through per-record restore helper `0x0042db20`
  - clears collection flag `[this+0x88] = 0` before returning
- that reload path does not pass any trigger-kind argument analogous to the later `0x00432f40`
  service call
- and the per-record helper `0x0042db20` is narrower than a full metadata restore:
  - it conditionally rebuilds the six fixed text bands and the linked `0x1e` / `0x28` row families
  - it does **not** restore the event metadata band `+0x7ee..+0x80e`, including `[event+0x7ef]`
- the save-side companion `0x00430d70` matches that same omission:
  - it writes the fixed text bands plus the linked condition/effect rows
  - it does **not** serialize the metadata band `+0x7ee..+0x80e`

So the remaining periodic-company question stays between reload and service: the checked restore
path repopulates the rows, but the later trigger-kind gate lives only in the service strip.

## Deep-Copy Boundary

The one remaining metadata-copy helper is narrower now too:

- `0x0042e050`
  - really does mirror the omitted metadata band `+0x7ee..+0x80e`, including `[event+0x7ef]`
  - but the current whole-binary caller search only grounds one caller:
    `0x004db8b0`, the shell-side `EventConditions.win` clone-selected-event path
- no grounded post-load, world-entry, or periodic-service caller currently re-enters `0x0042e050`

So the control-lane frontier narrows again:

- shell event cloning can duplicate trigger-kind metadata intact
- but there is still no grounded shellless duplication path between reload `0x00433130` and the
  late `kind 8` service

## Current Writer Census

The direct writer set for `[event+0x7ef]` is narrower now too:

- `0x0042d5a0`
  - zero-initializes the live runtime-effect record control band
  - clears `[event+0x7ee]`, `[event+0x7ef]`, `[event+0x7f4]`, `[event+0x81f]`, `[event+0x823]`,
    and `[event+0x82b]`
- `0x0042e11a`
  - straight copy helper over the same control band
  - copies `[event+0x7ee/+0x7ef/+0x7f0/+0x7f4...]` from one live row into another
- `0x00430b50`
  - the already-grounded follow-on runtime-effect builder
  - reaches the fresh live row through `0x00432ea0 -> 0x0042d5a0`
  - then seeds `[event+0x7ef]` to `2` or `3` from the current `[world+0x11]` threshold
  - also sets `[event+0x7f5] = 1`
- `0x00443526` and `0x00443601`
  - the already-grounded late retags to `5` and `2`

So the remaining control-lane question is narrower again:

- ordinary reload `0x00433130 -> 0x0042db20` does not itself pass a trigger kind
- the late service strip gates strictly on `[event+0x7ef]`
- and the currently grounded nonzero seed outside the scenario-name retags is the follow-on
  builder reached from the service/dispatch family rather than from the reload loop itself

The direct-write census is narrower than that bullet list alone suggests:

- current whole-binary `objdump` search for `mov BYTE PTR [...+0x7ef], imm/reg` grounds only:
  - zero-init `0x0042d5a0`
  - copy helper `0x0042e11a`
  - follow-on builder `0x00430b50`
  - late retags `0x00443526` and `0x00443601`
  - shell editor selector table `0x004d8ea0`
- the only grounded explicit `kind 8` write is `0x004d91b3`, inside the shell-side selector table
  for controls `0x4e98..0x4ea2`
- no grounded shellless runtime-side direct writer currently seeds `8` into `[event+0x7ef]`

## Ruled-Out Shell Seed Table

The largest remaining direct writer family is no longer ambiguous either:

- `0x004d8ea0`
  - is the shell-side `EventConditions.win` commit helper already grounded in `function-map.csv`
  - resolves the currently selected live event from the editor window singleton, not from post-load
    bringup
  - writes `[event+0x7ef] = 0..10` from the fixed control family `0x4e98..0x4ea2`
  - also commits neighboring editor-strip fields such as `[event+0x7f9]`, `[event+0x7fa]`,
    `[event+0x7f5]`, and `[event+0x7f0]`
- `0x004db120`
  - is the paired shell refresh helper
  - republishes that same `0x4e98..0x4ea2` family one-to-one from stored `[event+0x7ef]`

So the active shellless queue head narrows again:

- the broad `0..10` trigger-kind selector table is real
- but it belongs to the shell editor strip rather than ordinary post-load simulation bringup
- the remaining runtime question stays above ordinary reload `0x00433130` and below final service
  `0x00432f40(kind 8)`, not inside the explicit shell editor commit path