Fast loop: plant-side twin, fast reads, writes, alerts and the quality-to-lot link

Company policy: ../../Stamped_Master_Document.md wins on identity and control (section 7).

Why this exists#

Stamped starts with good parts: material and energy a plant has already paid for, lost in parts that never ship. Some of those losses are decided in seconds, on the floor: a billet pushed too cold, a press restarting with a cold die, a basket waiting too long before ageing. The scheduled path (L3 every few minutes, L4 cards in about two minutes) is too slow for them. The fast loop is a plant-side path that reads the machine in under a second, keeps a physics model of each asset in step (PlantState direction; twin on the Plant Box, D3), and acts through accepted procedures: an alert, an action, a short signal, or later a confirmed WriteRequest to an allow-listed process setpoint (D10).

It does not replace the scheduled path. Daily and campaign decisions stay on L3 → L4 → L5.

Architecture#

Fast loop overview

How to read it.

Sub-second reads and the twin run on the Plant Box; the writer is the only OPC UA write path (D10).
Messages leave through the L5 relay under cloud budget authority (D16); config is pulled from L2, not pushed (section 7.3).
The scheduled cloud loop still turns patterns into cards; the fast loop feeds it records and never replaces L4 drafting.

Build now: shadow replay and message-only (AL1). Later: confirmed and standing writes per AutonomyPolicy stages AL2 and AL3.

View Mermaid source

flowchart TB
    %% house-style: fast-loop-overview
    subgraph plant["Plant Box fast loop (D4)"]
        direction LR
        plc["PLC and SCADA"] --> edge["edge-agent"]
        edge --> bus["plant MQTT broker"]
        bus --> twin["stamped-l3-twin"]
        twin --> wr["stamped-writer"]
        wr --> plc
        twin --> relay["stamped-l5-relay (D7, D16)"]
    end
    gate{{"Predictive safety filter (D15)"}}
    twin --> gate --> wr
    relay --> l5c["L5 budgets and closure"]
    sync["sync-agent"] --> twin
    l2p["L2 pulled config"] --> sync
    edge -->|"buffered upload"| l2u["L2 records"]
    twin -->|"records, twin_state, write_log"| l2u
    reg["rejection register"] -->|"quality-to-lot link"| l2u
    l2u --> l3s["L3 scheduled detection"]
    l3s --> l4["L4 cards"]
    l4 --> l5c
    l5c --> l6["L6 dashboard"]

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class gate govc
    class l2p loopc

Documents#

Doc	Decides
01 Twin runtime	Where the twin code lives, the per-second loop, plant states, fault recovery, model governance, why Python
02 Fast read and writer	Sub-second reads in the edge agent; `stamped-writer`, its safeguards, staged authority and hazard analysis
03 Alerts and the quality-to-lot link	Alarm rules, genealogy from billet to customer return, rejection-register matching, per-basket heat-treatment record
04 Messages and missed savings	Four message classes and budgets, standing procedures, follow-through, the missed-savings ledger
05 Records and operations	L2 tables, topics, deployment, security, monitoring, tests, low-data lines, runbooks
06 Parameters and plant changes	Part-keyed parameters, new-part approval switch, continuous tuning, plant change catalog
07 Interfaces and ownership	One owner per job, topic registry, table ownership, cloud-to-box control channel, L5 relay and one budget per person, single Finding outbox, fast-data tier, episode trace, plant-box lockfile, service levels, degraded modes

Principles#

Physics plus data. Grey-box models kept in step by estimators, with honest uncertainty (D14 DECIDED).
Procedures before behaviour. Every fast behaviour belongs to a standing procedure a named person accepted once as a card.
Messages first, writes after proof. Writes come tag by tag, confirmed by a person first (AL2), never silent.
Budgets protect attention. Actions 6–8 per person per day; signals at most 2 an hour; alerts under alarm rules (D16).
Every alert names the lot. Quality risk is tied to the bins and baskets a person can find.
One twin, parameters per context. New parts learn before they recommend; the Stamped team approves them while the switch is on.
Customer specifics stay in the site pack. Platform and sector pack code never names a plant.

Rollout stages#

Stage	What runs	Gate to enter
0 Replay	Months of history replayed through the twin in shadow	Reference tests pass
1 Messages only (AL1)	Alerts, actions, signals, digests; nothing written	Replay passes message budgets per role; procedures accepted
2 Confirmed writes (AL2)	A person confirms each write, one tag at a time	Site check, machine switch, signed hazard row, simulator tests
3 Standing writes (AL3)	Accepted procedure writes within limits, switched on per shift	Two clean weeks at stage 2; uncertainty calibrated; production head signs

AL4 and AL5 are out of scope (section 6).

Control today (master document section 7)#

Today Stamped recommends and the plant team decides. Safety decisions and safety systems, quality holds and release, conformance sign-off and process acceptance, maintenance authorisation and lockout, and customer priority, promise dates, routing, master data and the full dispatch sequence stay with the plant. Any write-back is approved by the plant, narrow, allow-listed and auditable.

The fast loop is the first path to autonomous execution that the master document describes: writes only to allow-listed process setpoints, through stamped-writer on the Plant Box, earned tag by tag through AL2 and AL3, switchable off at any time. Interlocks, trips, E-stops, alarm thresholds, sort limits and heat-treatment setpoints are not on the write list. A remote change can switch writes off; switching them on takes a person at the plant (07).