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.

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.

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