In short

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#

Layer model

⑥ Layer 6 · Value

⑤ Layer 5 · Action

③ Layer 3 · Analytics (seven-job chain, jobs 1–5)

② Layer 2 · Context

① Layer 1 · Plant systems (customer-owned)

proposes to the router

context, states, metrics

chosen method, or abstain

proposals

approved only

outcomes

reads layers 2 to 4

④ Layer 4 · Decision (jobs 6–7)

Prescriptions ranked by value and confidence

Optimisation: set-point, scheduling, tariff

Control: rule → advice → BO/EVOP
Later: MPC; shielded RL not in the next 12 months

Governance plane (applies to every layer; no arrows drawn)
• Data quality, evidence labels, calibration gates
• Model registry, evals, sustainment (re-ID, model health)
• Autonomy policy
• Message/alarm budgets and disposition
• Audit trail, intervention log, episode_id
• Predictive safety filter (drawn in the flow below)

PLC, DCS, SIS, historians, meters, MES, ERP, paper

Connectors and fast read, one ingest path

Context store in L2: assets, topology, states, lots, genealogy links with confidence, documents

Semantic metric layer

SPC → MSPC → residuals

Estimation (KF family, twins)

Prediction: soft sensors, forecasts

Causal quality and attribution

Method-selection router with abstain

Predictive safety filter (governance plane): every proposal passes here

Messages and cards

Experiments: step tests, EVOP, switchback

Policy-granted write-back

Operator feedback and overrides

Value ledger: counterfactual M&V per KPI

↩ Back to Layer 1: approved writes only, inside the plant's limits

↩ Learning and sustainment: the ledger updates layers 3 and 4 and the model registry, with review

Agents: read-only tools over layers 2 to 4, propose only

How to read it. Follow the numbers from top to bottom:

  1. 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).
  2. The Analytics layer (layer 3) detects, estimates, predicts and attributes. The router picks the method the evidence supports, or abstains.
  3. 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.
  4. Every proposal, from any source, passes the predictive safety filter before it can act.
  5. Approved proposals become messages, experiments or policy-granted writes (layer 5). Writes go back into the plant's systems, inside its limits.
  6. 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:

ChangeReason
"Edge" removed as a layer; it is a place where layers 2 to 5 runAny 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 planeData 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 actionHistorical 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 layerLearning 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 stackAgents read structured outputs and propose. They never compute a rupee number or a limit themselves (section 8).
Value ledger moved under verification and widenedEnergy-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–4Makes method order and abstain explicit: SPC → MSPC → residuals → estimation → prediction → optimisation → control (C45).
Predictive safety filter in the governance planeOne 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 planeAPC-style decay without upkeep (E11); ISA-18.2 budgets and disposition (E24, E15; C20, C47).
Write path framed by NAMUR OA / NE 178Additive M+O channel with Verification of Request into CPC (C34; D17).
Short layer names: Context, Analytics, Decision, Action, ValueOne word per layer so diagrams, contracts and code comments use the same names (section 1.1).
Shielded RL marked not in the next 12 monthsAL4 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:

  1. SPC
  2. MSPC / multiway and profile monitoring
  3. Residual and innovation diagnostics
  4. State estimation
  5. Prediction (soft sensors, forecasts)
  6. Optimisation
  7. 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#

Two loops

outbound sync: readings, twin_state, write_log, outcomes

pulled by the plant: approved parameters, policy grants, model versions

Slow loop in the cloud, minutes to weeks

Analytics, MSPC, causal, forecasts

Prescriptions, schedules, policies

Value ledger and verification

Model and parameter updates (reviewed)

Fast loop at the plant (Plant Box), seconds

Fast read 1 s

State estimate (twin_state)

Decision under standing policy

Predictive safety filter

Writer: VoR-style verify, limits, watchdog, read-back

Operator message (budgeted)

How to read it.

  1. This is the steady state; section 3.6.8 shows the shadow-first start and the operator step.
  2. The cloud can switch writes off; switching them on needs a person at the plant.
  3. 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 layerNew layerNote
L0 platform pack (SE)Contracts for allOwns the ten contracts in section 5
L1 connectorsLayer 2 (connectors) and Plant BoxFast read and writer land here (ADR-034, ADR-035)
L2 universal-repositaryLayer 2 (context store, metrics)Store of record, including lots and twin state
L3 intelligence-core, rulepacks, evalsLayer 3 and governance (registry)Twin runtime per ADR-033
L4 knowledge-reasoningLayer 4 and agentsDecisionRuntime, scheduling, Ask
L5 closure-verificationLayers 5 and 6, plus autonomy policyCard machine, verification packs, gate
L6 experience-integrationPresentation of layers 5 and 6UI 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#

Layer 1 plant

How Stamped reads (read-only)

① Customer-owned systems: they stay in charge

readings, events, records

readings, events, records

PLC and DCS
basic control loops

Energy meters,
check-weighers

Historians, SCADA

MES, ERP, lab results,
paper logs

SIS and interlocks: outside every Stamped envelope, never read as a target, never written

edge-agent: Modbus, OPC UA, MQTT,
historian SQL, files

Connectors and uploads
for orders, lots, documents

② Layer 2 · Context

↩ The only way back: an OPC UA write to an operator-settable set point,
through the Plant Box writer, inside a signed operating envelope

How to read it.

  1. The plant's own control, metering, historian and business systems stay in charge of the plant.
  2. The edge-agent and the connectors only read, and pass readings, events and records to Layer 2.
  3. Safety systems and interlocks sit outside every envelope; no arrow touches them.
  4. 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#

Layer 2 context

② L2 store of record: Postgres + TimescaleDB (D1, D20)

One ingest path

At the plant

metrics with versions

edge-agent
buffer, drift watcher

Plant Box fast read, 1 s
fast-loop tags only

CLOUD ingest: Envelope, sequence
numbers, dedupe, replay (section 7.3)

Quality codes and evidence labels (C03, D13)

Readings
compressed hypertables

Assets, topology,
operating states

Lots, events, genealogy links
with method and confidence

Context records
and documents

Semantic metric layer: versioned metrics and baselines (C08, C10)

Read-only graph views for L3 and KR

③ Layer 3 · Analytics

How to read it.

  1. Slow tags come through the edge-agent and fast-loop tags through the Plant Box; both use the same ingest path.
  2. Every reading gets a quality code and an evidence label before it is stored.
  3. One store holds readings, assets, lots, genealogy links and documents, protected by one security model.
  4. 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#

Layer 3 analytics

③ Seven-job chain, jobs 1–5

chosen method

② From Layer 2: readings, states, lots, metrics

1 SPC

2 MSPC and profiles

3 Residuals and
innovations

4 State estimation
Kalman family, twin (C14)

5 Prediction
soft sensors, forecasts

Causal quality and attribution (C18)

Calibration gate (C44): coverage and NIS per model class (D14)

Method-selection router (C45): climbs only as far as the evidence allows

↩ Abstain: say which data or test is missing

④ Layer 4 · Decision

How to read it.

  1. Context data enters the chain at job 1 and the causal engine in parallel.
  2. Each job adds understanding: control charts, multivariate monitoring, residual checks, state estimates, then predictions.
  3. Nothing passes on until the calibration gate shows the intervals are honest for that model class.
  4. 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#

Layer 4 decision

④ Jobs 6–7

approved only

③ From Layer 3: chosen method and calibrated outputs

Rank prescriptions by value,
confidence and evidence tier

Set-point optimisation
BO or EVOP inside the envelope

Scheduling repair (CP-SAT)
proposes a near-term sequence

Control ladder: rule, advice, BO/EVOP
Later: MPC

A named person accepts any sequence before write-back

Predictive safety filter: every proposal passes here

⑤ Layer 5 · Action

How to read it.

  1. Calibrated outputs become ranked prescriptions; hold is always one of the options (section 5.3).
  2. Optimisation proposes settings, scheduling proposes a sequence, and the control ladder proposes moves.
  3. A sequence change goes to a named person first; Stamped never changes priority, routing or the full dispatch sequence on its own.
  4. 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#

Layer 5 action

⑤ Layer 5 · Action

Action records

Action records

④ From Layer 4: proposals

Predictive safety filter (L5 autonomy, D15): operating envelope, operating state, FMEA refs

L5 card machine (ClosureState)
budgets and suppression (D16)

Experiments: step test, EVOP,
switchback, under their own policy

WriteRequest (section 5.8)
Verification of Request flow

One sender: WhatsApp

Plant Box local display (D7)

Plant Box writer: limits, watchdog, read-back

Operator or owner: acts, overrides, stops

↩ To Layer 1: OPC UA set point inside the operating envelope

⑥ Layer 6 · Value

How to read it.

  1. Approved proposals become one of three things: a card, an experiment or a write request.
  2. Cards go out through one sender and the Plant Box display, inside message budgets.
  3. A write request passes every Verification of Request step before the writer touches a set point, and the writer reads the value back.
  4. 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#

Layer 6 value

⑥ Layer 6 · Value

⑤ From Layer 5: actions, outcomes, overrides

Normalise: output,
mix, shift, ambient

Method per action class (D5):
switchback, else adjusted baseline;
power analysis first

ValueRecord per KPI:
energy, scrap, throughput, quality

Tier from evidence labels: measured, confirmed, modeled, unknown

Customer sign-off (status signed_off)

↩ Sustainment: re-identify models, update the registry, widen or narrow AutonomyPolicy, with review

How to read it.

  1. Outcomes are normalised for output, product mix, shift and weather before anything is compared.
  2. The method depends on the action: switchback where the action can alternate, adjusted baseline otherwise, sized by a power analysis first.
  3. Each ValueRecord carries a tier derived from its weakest evidence label, then waits for the customer's sign-off.
  4. 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#

Governance plane

The layers

Governance plane, part 2: authority and record

Governance plane, part 1: data and models

Evidence labels, data quality (C03, D13)

Calibration gates per model class (C44, D14)

One model registry, human-gated promotion (D9)

Sustainment: coverage drift, PSI, re-ID (C47)

Predictive safety filter (D15)

AutonomyPolicy, operating envelope (section 5.6)

Message budgets, disposition (D16)

Audit: hash-chained write_log, episode_id

② Context

③ Analytics

④ Decision

⑤ Action

⑥ Value

How to read it.

  1. 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.
  2. Dotted lines show the layer that calls it most often. In practice every layer calls labels and audit.
  3. 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#

Fast loop

Plant Box, seconds (shadow first)

confirm or stop

stop

Fast read 1 s

Data-quality gate,
evidence labels

State estimate
(twin_state, D3)

Decision under
standing policy

Safety filter (edge copy)

Writer: VoR checks,
limits, read-back

Watchdog: heartbeat, clock skew, operator touch

Local display and card

Operator: confirms at AL2, can stop at any time

↩ Set point back to the PLC; the next reading closes the loop

↩ Outbound sync to the cloud: readings, twin_state, write_log (section 7.3)

How to read it.

  1. Every second the Plant Box reads, checks quality, estimates state and decides under the policy in force.
  2. The edge copy of the safety filter checks the move; the operator sees it on the local display.
  3. 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.
  4. 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#

Slow loop

Cloud, minutes to weeks

next cycle

Sync in: one ingest path,
sequence numbers, replay

Analytics: MSPC, causal,
forecasts (Layer 3)

Prescriptions, schedules,
policy drafts (Layer 4)

Cards and experiments
(Layer 5)

Value ledger
(Layer 6)

Review gate: no auto-promotion (D9)

Model and parameter updates in the registry

Plant approver signs the AutonomyPolicy at the plant

↩ Signed bundle pulled by the Plant Box: grants, parameters, model versions

How to read it.

  1. Synced data flows through analytics, prescriptions, cards and experiments into the value ledger.
  2. Ledger results pass a human review gate before any model or parameter changes.
  3. Approved updates feed the next cycle and go into a signed bundle; new grants also need a plant approver's signature.
  4. 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
  1. 2026-10-07 docs(research): retire stale research to archive/research-2026-10 with a register ab84821
  2. 2026-10-07 docs(technical): rewrite fast-loop/; all architecture diagrams in house style 7330f47
  3. 2026-10-07 docs(technical): archive archify; add SYSTEM_VIEWS.md house diagrams; check_docs --min 1e190b6
  4. 2026-10-07 docs(technical): carry product sections; rewrite README and pointers ee1e818
  5. 2026-10-07 docs(technical): split decision board into DECISIONS.md b4db9d4

Diagram

100%

Search the architecture