The layer model
Data moves through six conceptual layers: Plant systems, Context, Analytics, Decision, Action and Value, where the outcome is written as a ValueRecord. Governance (data quality, the registry, autonomy policy, budgets, audit and the predictive safety filter) is a plane that applies to every layer. Agents sit outside the stack, with read-only tools, and can only propose. The work runs as two loops: a fast loop on the Plant Box in seconds and a slow loop in the cloud over minutes to weeks. Section 3.5 maps repo layers L0 to L6 onto the six, and 3.6 gives each layer its own diagram.
3.1 What the brief proposed#
Five layers: plant context, analytical intelligence, optimisation, action, verification and learning. And a fuller stack: plant systems → edge → context → analytical → decision and optimisation → action and agents → value ledger → learning.
3.2 What the evidence says#
The production control wins in the ledger share a pattern.
- Google's cooling system predicts the effect of actions, picks actions with an optimiser under constraints, lets the local control system verify them, drops low-confidence actions, and narrowed its boundaries before widening them (E05).
- ENEOS kept the existing DCS and safety functions in charge and ran one column (E03).
- Aramco trained agents on a simulator and integrated with the existing safety functions (E04).
- Imubit's controller sits on top of existing APC (E06).
- Fero at Gerdau shows a recommendation to the operator, who adds the alloy (E08).
None of these put the learning system in charge of safety, and all had a model of the unit before any action.
Two further facts shape the model.
- APC benefit decays to zero within 18 to 24 months at more than 65% of installations without upkeep (E11), so verification and model upkeep must be part of the architecture, not a phase.
- The WEF Lighthouse numbers (77% analytical AI, 9% generative AI among top-five use cases, E01) say that the value in factories so far comes from analytical models, with generative AI a thin share. Caveat: those use cases are chosen by the sites themselves for an award panel.
3.3 The modified model#
How to read it. Follow the numbers from top to bottom:
- Data leaves the plant's own systems (layer 1) through connectors and one ingest path into one context store and metric layer (layer 2, Context).
- The Analytics layer (layer 3) detects, estimates, predicts and attributes. The router picks the method the evidence supports, or abstains.
- The Decision layer (layer 4) turns that into ranked prescriptions, optimised settings or control moves. For the first three plants the control ladder stops at BO/EVOP; MPC waits for an identified model that passes calibration.
- Every proposal, from any source, passes the predictive safety filter before it can act.
- Approved proposals become messages, experiments or policy-granted writes (layer 5). Writes go back into the plant's systems, inside its limits.
- Outcomes and operator feedback land in the value ledger (layer 6, Value), which feeds learning and sustainment back into layers 3 and 4.
View Mermaid source
flowchart TB
%% house-style: layer-model
gov["<b>Governance plane</b> (applies to every layer; no arrows drawn)<br/>• Data quality, evidence labels, calibration gates<br/>• Model registry, evals, sustainment (re-ID, model health)<br/>• Autonomy policy<br/>• Message/alarm budgets and disposition<br/>• Audit trail, intervention log, episode_id<br/>• Predictive safety filter (drawn in the flow below)"]
subgraph L_plant["① Layer 1 · Plant systems (customer-owned)"]
ps["PLC, DCS, SIS, historians, meters, MES, ERP, paper"]
end
subgraph L_ctx["② Layer 2 · Context"]
direction LR
conn["Connectors and fast read, one ingest path"] --> ctx["Context store in L2: assets, topology, states, lots, genealogy links with confidence, documents"] --> sem["Semantic metric layer"]
end
subgraph L_ana["③ Layer 3 · Analytics (seven-job chain, jobs 1–5)"]
direction LR
det["SPC → MSPC → residuals"]
est["Estimation (KF family, twins)"]
pred["Prediction: soft sensors, forecasts"]
cause["Causal quality and attribution"]
router["Method-selection router with abstain"]
det & est & pred & cause --> router
end
subgraph L_dec["④ Layer 4 · Decision (jobs 6–7)"]
direction LR
rank["Prescriptions ranked by value and confidence"]
opt["Optimisation: set-point, scheduling, tariff"]
ctrl["Control: rule → advice → BO/EVOP<br/>Later: MPC; shielded RL not in the next 12 months"]
end
saf{{"Predictive safety filter (governance plane): every proposal passes here"}}
subgraph L_act["⑤ Layer 5 · Action"]
direction LR
msg["Messages and cards"]
exp["Experiments: step tests, EVOP, switchback"]
wr["Policy-granted write-back"]
end
subgraph L_ver["⑥ Layer 6 · Value"]
direction LR
fb["Operator feedback and overrides"] --> led["Value ledger: counterfactual M&V per KPI"]
end
wb(["↩ Back to Layer 1: approved writes only, inside the plant's limits"])
ln(["↩ Learning and sustainment: the ledger updates layers 3 and 4 and the model registry, with review"])
agents["Agents: read-only tools over layers 2 to 4, propose only"]
ps --> conn
L_ctx -->|"context, states, metrics"| L_ana
router -->|"chosen method, or abstain"| L_dec
L_dec -->|"proposals"| saf
saf -->|"approved only"| L_act
L_act -->|"outcomes"| L_ver
wr --> wb
led --> ln
agents -. "reads layers 2 to 4" .-> L_ctx
agents -. "proposes to the router" .-> router
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 gov,saf govc
class agents agentc
class wb,ln loopc
Each layer has its own detail diagram in section 3.6.
The governance plane is shown as one card because it applies to every layer; drawing an arrow to each would hide the flow. Agents sit outside the stack: they read layers 2 to 4 and can only propose to the router. What changed from the brief and why:
| Change | Reason |
|---|---|
| "Edge" removed as a layer; it is a place where layers 2 to 5 run | Any in-shift loop (soak-end, head trims, offset corrections, compressor sequencing) needs context, estimation, decision and write at the plant within seconds, while most analytics do not. Edge is a deployment choice per function (section 7), not a slice of logic. |
| Governance as a plane | Data quality failures, unversioned models and unscoped authority hurt every layer. Putting them in one layer hides that each layer must call them. |
| Experiments added to action | Historical plant data rarely varies the knobs that matter, and simple physics assumptions are often wrong until tested (one customer analysis found a constant-power assumption contradicted by its data). Without sanctioned experiments, the analytical layer cannot learn causal effects. EVOP has done this on running plants since 1957 (E34). |
| Learning is a loop, not a top layer | Learning updates parameters in layers 3 and 4 from the ledger. Drawn as a layer it looks like a product; it is a set of feedback paths with review gates. |
| Agents outside the stack | Agents read structured outputs and propose. They never compute a rupee number or a limit themselves (section 8). |
| Value ledger moved under verification and widened | Energy-only M&V cannot price scrap, throughput, giveaway or quality, which is where much of the value sits in discrete, packaging and batch plants. |
| Seven-job chain named inside layers 3–4 | Makes method order and abstain explicit: SPC → MSPC → residuals → estimation → prediction → optimisation → control (C45). |
| Predictive safety filter in the governance plane | One outer shell for every proposal source before action (C46); matches the staged verification pattern in published closed-loop cases (E05). |
| Sustainment and message governance in the governance plane | APC-style decay without upkeep (E11); ISA-18.2 budgets and disposition (E24, E15; C20, C47). |
| Write path framed by NAMUR OA / NE 178 | Additive M+O channel with Verification of Request into CPC (C34; D17). |
| Short layer names: Context, Analytics, Decision, Action, Value | One word per layer so diagrams, contracts and code comments use the same names (section 1.1). |
| Shielded RL marked not in the next 12 months | AL4 and AL5 are out of scope; the first three plants need rule, advice and BO/EVOP (section 10). |
3.3b Seven-job chain, safety filter and sustainment#
Seven-job analytics chain. Analytical and decision work share one ladder rather than a bag of engines:
- SPC
- MSPC / multiway and profile monitoring
- Residual and innovation diagnostics
- State estimation
- Prediction (soft sensors, forecasts)
- Optimisation
- Control
A method-selection router (C45) chooses how far to climb given evidence labels and calibration status, and abstains when Measured/Estimated support or gates (C44) are insufficient. Regime labels and observability/identifiability checks sit before filter and estimator design inside jobs 2–4. (intake 7 Oct) ALS-identified noise covariances followed by per-horizon ACI feed jobs 3–5, and planned identification (C27) supplies the models for jobs 4, 6 and 7; see D13, D14 and D19 in DECISIONS.md.
Decided (7 Oct 2026, Vinayak). EvidenceLayer contract for detector output (direction; as built: Finding finding.json 1.2.0) labels (Measured, Estimated, Assumed, Unknown, plus calibrated or uncalibrated) attach at Evidence and PlantState and cascade to PrescriptionWhat to do, why, who, check plan (direction; as built: prescription.json 1.0.0 / card-proposal) and ValueRecord, with the section 5.2 tier mapping (D13). Calibration thresholds are set per model class: estimators and forecasters need 85–95% empirical coverage for nominal 90% intervals on unseen data, and NIS inside its 95% chi-squared band, checked after ALS and before ACI per horizon; these are targets, not results, and other classes set theirs when they first ship (D14). MHE is benchmarked offline in the cloud first; a solver and a Plant BoxPlant-side computer for the fast loop (direction; D4) placement are chosen only if it beats the Kalman filter on restart episodes (D19).
Predictive safety filter. Drawn in the governance plane because it must wrap every proposal source — rule packs, ranked prescriptions, human set-point requests and learned policies alike — before messages that imply action, experiments, or writes. It evaluates the predicted next state against envelopes, operating state and FMEA refs. Ownership is D15 (RECOMMENDED: one filter in the L5 autonomy package, run as edge and cloud copies); the architectural rule is that it sits outside the proposer.
Sustainment. Benefit tracking against the value ledger, scheduled re-identification and model-health signals (coverage drift, PSI, residual diagnostics) are governance duties, not a Phase-6 afterthought. The industry claim that more than 65% of APC installations reach zero benefit within 18–24 months without maintenance (E11) is the reason sustainment hooks ship with the first advisory or control mode (C47).
Design doctrine when axes conflict: Safety → Calibration → Data need → Explainability → Accuracy → Cost.
3.4 Two loops#
How to read it.
- This is the steady state; section 3.6.8 shows the shadow-first start and the operator step.
- The cloud can switch writes off; switching them on needs a person at the plant.
- All plant-bound changes are pulled by the Plant Box, never pushed in.
Build now: the slow loop at AL1. Later: the fast loop, shadow first.
View Mermaid source
flowchart TB
%% house-style: two-loops
subgraph fast["Fast loop at the plant (Plant Box), seconds"]
direction LR
r["Fast read 1 s"] --> s["State estimate (twin_state)"]
s --> d["Decision under standing policy"]
d --> f
f{{"Predictive safety filter"}} --> w["Writer: VoR-style verify, limits, watchdog, read-back"]
w --> r
f --> m["Operator message (budgeted)"]
end
subgraph slow["Slow loop in the cloud, minutes to weeks"]
direction LR
a["Analytics, MSPC, causal, forecasts"] --> p["Prescriptions, schedules, policies"]
p --> v["Value ledger and verification"]
v --> u["Model and parameter updates (reviewed)"]
u --> a
end
fast -- "outbound sync: readings, twin_state, write_log, outcomes" --> slow
slow -- "pulled by the plant: approved parameters, policy grants, model versions" --> fast
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 f govc
3.5 How the repo layers map#
| Repo layer | New layer | Note |
|---|---|---|
| L0 platform pack (SE) | Contracts for all | Owns the ten contracts in section 5 |
| L1 connectors | Layer 2 (connectors) and Plant Box | Fast read and writer land here (ADR-034, ADR-035) |
| L2 universal-repositary | Layer 2 (context store, metrics) | Store of record, including lots and twin state |
| L3 intelligence-core, rulepacks, evals | Layer 3 and governance (registry) | Twin runtime per ADR-033 |
| L4 knowledge-reasoning | Layer 4 and agents | DecisionRuntime, scheduling, Ask |
| L5 closure-verification | Layers 5 and 6, plus autonomy policy | Card machine, verification packs, gate |
| L6 experience-integration | Presentation of layers 5 and 6 | UI and channels |
3.6 Layer by layer#
One diagram per layer, then the governance plane and the two loops, in the same style as section 3.3: yellow is governance and safety, blue is people and agents, green rounded boxes are return paths.
3.6.1 Layer 1: plant systems#
How to read it.
- The plant's own control, metering, historian and business systems stay in charge of the plant.
- The edge-agent and the connectors only read, and pass readings, events and records to Layer 2.
- Safety systems and interlocks sit outside every envelope; no arrow touches them.
- The single return path is a set-point write the control system already accepts from operators (D10, section 7.2).
Build now: read-only connectors. Later: live writes, after the fast loop has run in shadow and the ledger shows same-condition wins.
View Mermaid source
flowchart TB
%% house-style: layer-1-plant
subgraph own["① Customer-owned systems: they stay in charge"]
direction LR
plc["PLC and DCS<br/>basic control loops"]
meters["Energy meters,<br/>check-weighers"]
hist["Historians, SCADA"]
mes["MES, ERP, lab results,<br/>paper logs"]
end
sis{{"SIS and interlocks: outside every Stamped envelope, never read as a target, never written"}}
subgraph read["How Stamped reads (read-only)"]
direction LR
ea["edge-agent: Modbus, OPC UA, MQTT,<br/>historian SQL, files"]
up["Connectors and uploads<br/>for orders, lots, documents"]
end
ctx["② Layer 2 · Context"]
wb(["↩ The only way back: an OPC UA write to an operator-settable set point,<br/>through the Plant Box writer, inside a signed operating envelope"])
plc & meters & hist --> ea
mes --> up
ea & up -->|"readings, events, records"| ctx
wb -.-> plc
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 sis govc
class wb loopc
3.6.2 Layer 2: context#
How to read it.
- Slow tags come through the edge-agent and fast-loop tags through the Plant Box; both use the same ingest path.
- Every reading gets a quality code and an evidence label before it is stored.
- One store holds readings, assets, lots, genealogy links and documents, protected by one security model.
- Analytics reads versioned metrics and read-only graph views; there is no second plant record.
Build now: one ingest path, lot and link tables. Later: graph queries through Apache AGE if path queries become painful (D1).
View Mermaid source
flowchart TB
%% house-style: layer-2-context
subgraph site["At the plant"]
direction LR
ea["edge-agent<br/>buffer, drift watcher"]
pb["Plant Box fast read, 1 s<br/>fast-loop tags only"]
end
subgraph ing["One ingest path"]
direction LR
in["CLOUD ingest: Envelope, sequence<br/>numbers, dedupe, replay (section 7.3)"]
dq{{"Quality codes and evidence labels (C03, D13)"}}
end
subgraph store["② L2 store of record: Postgres + TimescaleDB (D1, D20)"]
direction LR
ts["Readings<br/>compressed hypertables"]
assets["Assets, topology,<br/>operating states"]
lots["Lots, events, genealogy links<br/>with method and confidence"]
docs["Context records<br/>and documents"]
end
sem["Semantic metric layer: versioned metrics and baselines (C08, C10)"]
views["Read-only graph views for L3 and KR"]
ana["③ Layer 3 · Analytics"]
ea & pb --> in --> dq --> ts & assets & lots & docs
store --> sem -->|"metrics with versions"| ana
assets & lots --> views --> ana
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 dq govc
3.6.3 Layer 3: analytics#
How to read it.
- Context data enters the chain at job 1 and the causal engine in parallel.
- Each job adds understanding: control charts, multivariate monitoring, residual checks, state estimates, then predictions.
- Nothing passes on until the calibration gate shows the intervals are honest for that model class.
- The router picks the simplest method the evidence supports, or abstains and names what is missing.
Build now: jobs 1–3, Kalman-family estimation, soft sensors, coverage tracking. Later: foundation-model forecasts (D8), MHE (D19).
View Mermaid source
flowchart TB
%% house-style: layer-3-analytics
ctx["② From Layer 2: readings, states, lots, metrics"]
subgraph chain["③ Seven-job chain, jobs 1–5"]
direction LR
j1["1 SPC"] --> j2["2 MSPC and profiles"] --> j3["3 Residuals and<br/>innovations"] --> j4["4 State estimation<br/>Kalman family, twin (C14)"] --> j5["5 Prediction<br/>soft sensors, forecasts"]
end
cause["Causal quality and attribution (C18)"]
cal{{"Calibration gate (C44): coverage and NIS per model class (D14)"}}
router["Method-selection router (C45): climbs only as far as the evidence allows"]
abst(["↩ Abstain: say which data or test is missing"])
dec["④ Layer 4 · Decision"]
ctx --> j1
ctx --> cause
j5 & cause --> cal --> router
router -->|"chosen method"| dec
router --> abst
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 cal govc
class abst loopc
3.6.4 Layer 4: decision#
How to read it.
- Calibrated outputs become ranked prescriptions; hold is always one of the options (section 5.3).
- Optimisation proposes settings, scheduling proposes a sequence, and the control ladder proposes moves.
- A sequence change goes to a named person first; Stamped never changes priority, routing or the full dispatch sequence on its own.
- Every proposal, from any source, goes through the safety filter.
Build now: ranking, BO/EVOP, scheduling repair with human acceptance. Later: MPC once an identified model passes calibration.
View Mermaid source
flowchart TB
%% house-style: layer-4-decision
ana["③ From Layer 3: chosen method and calibrated outputs"]
subgraph jobs["④ Jobs 6–7"]
direction LR
rank["Rank prescriptions by value,<br/>confidence and evidence tier"]
sp["Set-point optimisation<br/>BO or EVOP inside the envelope"]
sched["Scheduling repair (CP-SAT)<br/>proposes a near-term sequence"]
ctrl["Control ladder: rule, advice, BO/EVOP<br/>Later: MPC"]
end
person["A named person accepts any sequence before write-back"]
saf{{"Predictive safety filter: every proposal passes here"}}
act["⑤ Layer 5 · Action"]
ana --> rank
rank --> sp & sched & ctrl
sched --> person
rank & sp & ctrl & person --> saf
saf -->|"approved only"| act
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 saf govc
class person agentc
3.6.5 Layer 5: action#
How to read it.
- Approved proposals become one of three things: a card, an experiment or a write request.
- Cards go out through one sender and the Plant Box display, inside message budgets.
- A write request passes every Verification of Request step before the writer touches a set point, and the writer reads the value back.
- Whatever a person or the writer does is recorded as an Action for Layer 6.
Build now: cards, one sender, local display, experiments; writes in shadow. Later: AL2 confirmed writes, then AL3 standing policies.
View Mermaid source
flowchart TB
%% house-style: layer-5-action
dec["④ From Layer 4: proposals"]
saf{{"Predictive safety filter (L5 autonomy, D15): operating envelope, operating state, FMEA refs"}}
subgraph act["⑤ Layer 5 · Action"]
direction LR
cards["L5 card machine (ClosureState)<br/>budgets and suppression (D16)"]
exp["Experiments: step test, EVOP,<br/>switchback, under their own policy"]
wrq["WriteRequest (section 5.8)<br/>Verification of Request flow"]
end
send["One sender: WhatsApp"]
disp["Plant Box local display (D7)"]
wri["Plant Box writer: limits, watchdog, read-back"]
op["Operator or owner: acts, overrides, stops"]
wb(["↩ To Layer 1: OPC UA set point inside the operating envelope"])
val["⑥ Layer 6 · Value"]
dec --> saf --> cards & exp & wrq
cards --> send & disp --> op
wrq --> wri --> wb
op -->|"Action records"| val
wri -->|"Action records"| val
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 saf govc
class op agentc
class wb loopc
3.6.6 Layer 6: value#
How to read it.
- Outcomes are normalised for output, product mix, shift and weather before anything is compared.
- The method depends on the action: switchback where the action can alternate, adjusted baseline otherwise, sized by a power analysis first.
- Each ValueRecord carries a tier derived from its weakest evidence label, then waits for the customer's sign-off.
- Results feed sustainment, which keeps models and grants honest over time.
Build now: multi-KPI ValueRecord, switchback and adjusted baseline. Verified savings today: ₹0.
View Mermaid source
flowchart TB
%% house-style: layer-6-value
act["⑤ From Layer 5: actions, outcomes, overrides"]
subgraph val["⑥ Layer 6 · Value"]
direction LR
norm["Normalise: output,<br/>mix, shift, ambient"]
meth["Method per action class (D5):<br/>switchback, else adjusted baseline;<br/>power analysis first"]
vr["ValueRecord per KPI:<br/>energy, scrap, throughput, quality"]
end
tier{{"Tier from evidence labels: measured, confirmed, modeled, unknown"}}
sign["Customer sign-off (status signed_off)"]
ln(["↩ Sustainment: re-identify models, update the registry, widen or narrow AutonomyPolicy, with review"])
act --> norm --> meth --> vr
vr --> tier --> sign
vr --> ln
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 tier govc
class sign agentc
class ln loopc
3.6.7 Governance plane#
How to read it.
- Each yellow box is one shared service with one owner; no layer may skip it. The top row governs data and models, the second row governs authority and the record.
- Dotted lines show the layer that calls it most often. In practice every layer calls labels and audit.
- The safety filter and the AutonomyPolicy sit outside every proposer, so no model, rule or agent can grant itself authority.
Build now: all eight, at the depth section 10 sets.
View Mermaid source
flowchart TB
%% house-style: governance-plane
subgraph gdata["Governance plane, part 1: data and models"]
direction LR
labels{{"Evidence labels, data quality (C03, D13)"}}
calib{{"Calibration gates per model class (C44, D14)"}}
reg{{"One model registry, human-gated promotion (D9)"}}
sus{{"Sustainment: coverage drift, PSI, re-ID (C47)"}}
end
subgraph gauth["Governance plane, part 2: authority and record"]
direction LR
saf{{"Predictive safety filter (D15)"}}
pol{{"AutonomyPolicy, operating envelope (section 5.6)"}}
msg{{"Message budgets, disposition (D16)"}}
audit{{"Audit: hash-chained write_log, episode_id"}}
end
gdata ~~~ gauth
subgraph layers["The layers"]
direction LR
L2["② Context"]
L3["③ Analytics"]
L4["④ Decision"]
L5["⑤ Action"]
L6["⑥ Value"]
L2 ~~~ L3 ~~~ L4 ~~~ L5 ~~~ L6
end
labels -.-> L2
calib -.-> L3
reg -.-> L3
saf -.-> L4
pol -.-> L5
msg -.-> L5
audit -.-> L5
sus -.-> L6
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 labels,calib,reg,pol,saf,msg,audit,sus govc
3.6.8 Fast loop at the plant#
How to read it.
- Every second the Plant Box reads, checks quality, estimates state and decides under the policy in force.
- The edge copy of the safety filter checks the move; the operator sees it on the local display.
- The writer acts only after Verification of Request, inside limits, and reads the value back; the watchdog or the operator can stop it at any moment.
- State and the write log sync outbound to the cloud.
Build now: the whole loop in shadow, logging what it would have written; AL1 messages live. Later: AL2, then AL3.
View Mermaid source
flowchart TB
%% house-style: fast-loop
subgraph pbox["Plant Box, seconds (shadow first)"]
direction LR
r["Fast read 1 s"] --> q["Data-quality gate,<br/>evidence labels"] --> s["State estimate<br/>(twin_state, D3)"] --> d["Decision under<br/>standing policy"] --> f{{"Safety filter (edge copy)"}} --> w["Writer: VoR checks,<br/>limits, read-back"]
end
wd{{"Watchdog: heartbeat, clock skew, operator touch"}}
disp["Local display and card"]
op["Operator: confirms at AL2, can stop at any time"]
ret(["↩ Set point back to the PLC; the next reading closes the loop"])
up(["↩ Outbound sync to the cloud: readings, twin_state, write_log (section 7.3)"])
f --> disp --> op
op -->|"confirm or stop"| w
wd -.->|"stop"| w
w --> ret
s --> up
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 f,wd govc
class op agentc
class ret,up loopc
3.6.9 Slow loop in the cloud#
How to read it.
- Synced data flows through analytics, prescriptions, cards and experiments into the value ledger.
- Ledger results pass a human review gate before any model or parameter changes.
- Approved updates feed the next cycle and go into a signed bundle; new grants also need a plant approver's signature.
- The Plant Box pulls the bundle; the cloud never pushes into the plant.
Build now: the whole slow loop live for the first three plants.
View Mermaid source
flowchart TB
%% house-style: slow-loop
subgraph cloud["Cloud, minutes to weeks"]
direction LR
in["Sync in: one ingest path,<br/>sequence numbers, replay"] --> a["Analytics: MSPC, causal,<br/>forecasts (Layer 3)"] --> p["Prescriptions, schedules,<br/>policy drafts (Layer 4)"] --> c["Cards and experiments<br/>(Layer 5)"] --> v["Value ledger<br/>(Layer 6)"]
end
rev{{"Review gate: no auto-promotion (D9)"}}
u["Model and parameter updates in the registry"]
person["Plant approver signs the AutonomyPolicy at the plant"]
bundle(["↩ Signed bundle pulled by the Plant Box: grants, parameters, model versions"])
v --> rev --> u
u -->|"next cycle"| a
u --> bundle
p --> person --> bundle
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 rev govc
class person agentc
class bundle loopc
Page history: last 5 changes
- docs(research): retire stale research to archive/research-2026-10 with a register
ab84821 - docs(technical): rewrite fast-loop/; all architecture diagrams in house style
7330f47 - docs(technical): archive archify; add SYSTEM_VIEWS.md house diagrams; check_docs --min
1e190b6 - docs(technical): carry product sections; rewrite README and pointers
ee1e818 - docs(technical): split decision board into DECISIONS.md
b4db9d4