L3 — Twin runtime and the fast loop

L3 view of the fast loop: what L3 adds, what stays in scheduled L3, and where the boundary sits. Twin math, plant states and recovery: fast-loop/01; parameters: fast-loop/06.

1. Two deployables, one repo#

Deployable	Command	Runs	Cadence	Output
Scheduled L3 (as-built)	`stamped-l3-core`	Cloud or plant server	Every few minutes	Findings through the outbox to L4
Twin runtime (direction)	`stamped-l3-twin`	Plant Box (D4; cloud while messages only)	Per second	PlantState direction (`twin_state`), write requests, records to L2, alert and signal requests to the L5 relay

Both live in intelligence-core. The twin is package stamped_l3_core/twin/ (kit/, assets/, genealogy/, procedures/, runtime/). The plant image installs only the twin extra. Runtime language and heartbeat gate: D3.

2. Boundary rules#

One Finding outbox, in scheduled L3. The twin holds no outbox. Anything that becomes a card is detected by a scheduled engine reading twin records from L2 and goes out as a Finding.
Twin outputs are not Findings. Twin state, write requests, alerts and signals use the fast-loop topics (07 section 2); they never enter L4 intake directly.
Import-linter: scheduler, engines and agentic code never import the twin write path; the twin never imports the scheduler, agentic, fine-tune or challenger code.
The runner executes accepted procedures only. Procedures are versioned YAML accepted by a named plant person; the runner never executes LLM output. Unaccepted procedures run in shadow and are only logged.
No L2 SQL holds for both deployables: the twin reads the plant broker and writes records through the sync agent; scheduled engines read L2 over HTTP.
Event time and wall time are separate. Backlogged or replayed data updates state but never triggers messages.

3. Twin-record engines (scheduled, direction)#

Scheduled engines that read twin records from L2 and emit ordinary Findings:

Family	Reads	Finding for
Procedure not followed	`follow_through`, `write_log`, `twin_state`	Repeated ignored or overridden actions on a procedure, per shift
Model drift	`param_row`, `twin_state` residuals	Context needing refit or re-validation
Repeated part risk	`part_flag`, `part_link`, `rejection_row`	Recurring flagged parts matched to register rejects
Heat-treatment basket risk	`ht_basket`, `ht_test`	Baskets near limits; ageing drift

Each family ships behind an ENABLE_* flag like other engines and follows the same dual-lane rules.

4. Packs#

Pack	Repo	Holds
Platform	`intelligence-core` (`twin/kit/`)	Estimators, gate, Monte Carlo, calibration, replay, drift, loaders
Sector (forging first)	`intelligence-rulepacks`	Asset physics priors per alloy family, procedure catalog templates (YAML), alarm rule templates
Site	Private site workspace, signed	Tag bindings, model cards, parameter rows, part aliases, plant-written limits, roster roles, write allow-list (signed by the production head)

Plant names never appear in platform or sector pack code. Plant-owned limits are never tuned.

5. Parameters and promotion#

Parameters are context-keyed rows (baselines.param_row in L2) with source, date, data volume and confidence; promotions are records per ADR-011. New parts enter Learning and need named Stamped approval while require_internal_approval_new_part = true (default). Detail: fast-loop/06.

6. Replay and reference tests#

Replay harness in intelligence-evals: leave-one-run-out replay on recorded L2 data; gates on forecast error, alarm precision and recall, interval coverage and per-role message budget.
Reference tests: rewritten modules reproduce the analysis scripts' outputs on recorded data within stated tolerances before replacing them. Product repos hold expected numbers and synthetic fixtures; plant data stays in the private site workspace.
Every incident replays from L2 through the same code, because the loop has no hidden wall-clock dependency.

7. Trace#

Each twin decision carries an episode_id from reading to record to message (07 section 8). Scheduled Findings derived from twin records cite the episode_id and the plant-box lockfile id in evidence references (04).