05 Records, deployment, security, tests and operations

1. L2 production tables#

One migration in universal-repositary/packages/migrate/sql/, extending the existing context and outcome records (telemetry.stop_event, features.process_batch, features.quality_status, features.shift_roster).

Table: 16 rows by table

Table	Schema	One row per	Idempotent key
fast_reading	telemetry	Batch of fast readings for one asset (compressed)	plant, asset, batch start, sequence
billet_push	telemetry	Billet pushed	plant, line, push time, counter
forged_part	telemetry	Part forged	plant, line, part time, counter
part_link	features	Billet-to-part link with method and confidence	part
part_flag	features	Flag or score on a part	part, flag, model version
time_bin	features	Part and time window	plant, line, part, bin start
ht_basket	features	Heat-treatment basket and its record	plant, furnace, quench time
ht_test	features	Strength test linked to a charge	plant, charge, sample
rejection_row	features	Register row with match status	plant, source ref, row hash
twin_state	features	Twin checkpoint	plant, line, asset, event time
write_log	ledger	Write request and result, hash-chained	writer, sequence
follow_through	ledger	Outcome of each action or signal	action
missed_savings	ledger	Expected loss and outcome	action
param_row	baselines	Versioned parameter row	context, version
param_promotion	baselines	Promotion record	context, version
part_alias	graph	Raw part name to part key	plant, raw name

Every insert is an upsert on its key. fast_reading is kept at least 13 months so a full-year replay is possible; records and the write log are never compacted by Stamped. Producers and consumers per table: 07.

2. Topics#

All under stamped/v1/{org}/{plant}/; the full registry with publishers, readers and ACLs is in 07.

Schemas live in contracts/ with contract tests on both sides.

3. Deployment#

Plant BoxPlant-side computer for the fast loop (direction; D4) (D4): fanless industrial PC on a UPS, with an imaged spare on site. Images are signed; the twin is Nuitka-compiled; the writer and edge agent are Go binaries. No updates during a shift with writes on; the writer starts switched off after any update. L2 hosting follows D20.

4. Security#

Zones and conduits in the style of IEC 62443: plant OT (PLCs, SCADA) ↔ Stamped Plant Box (read conduit for readers; write conduit for the writer only, to allow-listed tags) ↔ Stamped cloud (outbound only from the plant). The writer has its own PLC credentials; broker ACLs let only the twin publish write requests and only the writer read them. Remote support is a time-limited outbound tunnel a plant person switches on. No secrets in git.

5. Monitoring targets#

Twin loop p99 under 100 ms; fast-tag freshness under 2 s; signals event-to-phone under 5 s; P1 alerts under 5 min; zero writer read-back failures; no heartbeat gap over 5 s; edge buffer drains within an hour of link return; rising register match rate; about 1 alert per person per hour.

6. Replay#

Months of plant history replay through the twin in shadow, on event time, from a harness in intelligence-evals. Output per line, role and threshold: forecast error, interval coverage, alerts, actions and signals per person per shift, flag shares, expected value per procedure.

7. Test strategy#

No write path reaches a real PLC before its simulator and fault-injection tests pass.

8. Low-data lines#

Lines with only push and part counters run a low-data mode: stop and start detection, stop/Ready/first-part messages, and first-parts-after-a-stop flags. No heater twin, no temperature flags, no writes. Each line is its own site-pack entry with mode: low_data, so upgrading it later is configuration.

9. Runbooks#