AI & ML Integration — the authority gate
Start with the decision and its allowed authority—not the model. Every method must beat a named deterministic alternative, survive validation, and fail without defeating independent protection. This page is the gate; the method register and the pages below are scored against it.
Safety boundary: no learned method in this register is assigned direct closed-loop authority (level 5) or a safety function. Every row now carries an evidenced ceiling — as of Phase 49c no row is left at “Planned”. For why a learned component cannot hold a safety function today — the deterministic standards, the guidance-only AI documents, and the EU law that already caps it — see Safety & Security Boundaries.
The idea in plain terms
“AI/ML integration” in industrial automation means putting a model — something that classifies, estimates, predicts, or optimises from data — somewhere in the path between plant measurements and plant actions. The engineering question is not whether the model is impressive; it is how much the plant is allowed to act on the model’s output without a person or an independent check in between. This page calls that permission authority, and grades every method by the highest authority the evidence currently supports.
Two kinds of method appear throughout:
- A deterministic method computes the same answer from the same inputs by an explicit, inspectable rule — PID control, a Kalman filter, an interlock, a mass balance. Its behaviour can be verified.
- A learned method gets its behaviour from training data — a neural network, a boosted tree, a reinforcement-learning policy, an LLM. Its behaviour can be tested, but not exhaustively verified, and it can fail in unfamiliar conditions without signalling that it has.
That difference is why this page keeps repeating three demands: a method must beat a named deterministic alternative (otherwise use the simpler thing), it must survive validation designed to catch its specific failure modes, and independent protection must keep the plant safe when it is wrong.
Terms used throughout
| Term | Meaning here |
|---|---|
| Authority | The highest level of plant action allowed on a method’s output. |
| Deterministic method | Rule-based, verifiable computation (PID, interlock, balance, solver). |
| Learned method | Behaviour comes from training data; testable, not exhaustively verifiable. |
| Must beat | The named simpler method a candidate has to demonstrably outperform. |
| Envelope | Hard limits (range, rate, task space) enforced outside the learned method. |
| Veto | The non-learned check that can reject or replace any proposed action. |
| Independent protection | Interlocks and safety functions that still work when the model is wrong. |
| Safety function | Risk reduction implemented and verified per ISO 13849-1 / IEC 62061 / IEC 61511. |
| Planned | Evidence supports discussing the method, not an operational authority claim. No register row currently carries it. |
The question to answer before proceeding
What decision will this method influence, at what maximum authority, and what independent protection stays effective when its result is wrong, stale, unavailable, or compromised?
If those three parts cannot be answered and tested, keep the method offline. If a deterministic alternative meets the requirement, prefer it unless the proposed method demonstrates a specific, validated advantage.
flowchart TD
A{"Can you answer and test all three?
the decision it will influence · its maximum authority ·
the independent protection that stays effective when the result
is wrong, stale, unavailable, or compromised"}
A -->|No| E["Keep the method offline
authority 0"]
A -->|Yes| B{"Does a deterministic
alternative meet the requirement?"}
B -->|Yes| C{"Specific, validated advantage
demonstrated over that alternative?"}
C -->|No| D["Use the deterministic method
(the register's 'must beat' baseline)"]
C -->|Yes| F{"Survives the register's validation
requirements for this method?"}
B -->|No| F
F -->|No| E
F -->|Yes| G["Assign the lowest authority level
that delivers the claimed value"]
G --> H{"Learned method?"}
H -->|Yes| I["Ceiling: level 4 — bounded supervisory.
The safety function stays in a
verified non-learned layer"]
H -->|No| J["Authority per validation evidence
and the applicable safety lifecycle"]
classDef q fill:#e8eff8,stroke:#2b5797,color:#1e1e1e
classDef stop fill:#faeeec,stroke:#a33327,color:#1e1e1e
classDef go fill:#eef4ed,stroke:#3a6b35,color:#1e1e1e
classDef warn fill:#fdf6e3,stroke:#8b6914,color:#1e1e1e
class A,B,C,F,H q
class E stop
class D,J go
class I warn
class G q
Authority ladder
Authority is climbed, not granted — each level up demands more evidence. The diagram is generated from the same register data as the table below it.
flowchart BT
L0["0 · Offline
No live plant input or action"]
L1["1 · Read-only
Observes live data but cannot request action"]
L2["2 · Advisory
Recommends; a person decides"]
L3["3 · Operator-approved
Prepares an action that requires explicit approval"]
L4["4 · Bounded supervisory
Acts only inside independent limits and vetoes"]
L5["5 · Direct closed-loop
Direct control; no learned method is assigned this level here"]
L0 --> L1 --> L2 --> L3 --> L4
L4 -.->|"no learned method is assigned level 5 in this register"| L5
classDef ok fill:#e8eff8,stroke:#2b5797,color:#1e1e1e
classDef ceiling fill:#fdf6e3,stroke:#8b6914,color:#1e1e1e,stroke-width:2px
classDef reserved fill:#faeeec,stroke:#a33327,color:#1e1e1e,stroke-dasharray:5 4,stroke-width:2px
class L0,L1,L2,L3 ok
class L4 ceiling
class L5 reserved
linkStyle 4 stroke:#a33327,stroke-width:2px
| Level | Name | Meaning |
|---|---|---|
| 0 | Offline | No live plant input or action |
| 1 | Read-only | Observes live data but cannot request action |
| 2 | Advisory | Recommends; a person decides |
| 3 | Operator-approved | Prepares an action that requires explicit approval |
| 4 | Bounded supervisory | Acts only inside independent limits and vetoes |
| 5 | Direct closed-loop | Direct control; no learned method is assigned this level here |
Level 4 is not permission for learned safety control. It means bounded supervisory action inside independently implemented constraints and vetoes. Project risk assessment, applicable standards, verification, cybersecurity, and management of change still apply.
Level 4 here is an architectural ceiling for a learned method placed behind an independently verified envelope — not an authority any learned row is currently assigned. Every method presently at level 4 in the register (Kalman filter, model predictive control, first-principles numerical model) is deterministic or model-based; no learned row in this register exceeds level 3.
One task up the ladder
To make the levels concrete, here is the same job — condition monitoring and control on a critical pump — at every level. The scenario is illustrative; each level names a method that can actually hold that level in this register.
| Level | What it looks like on the pump |
|---|---|
| 0 · Offline | Exported vibration data is analysed at a desk; findings go into a report. Nothing on the plant changes. |
| 1 · Read-only | A live dashboard shows spectra and health indicators. People look; nothing acts. |
| 2 · Advisory | A diagnosis model (a 1D CNN, for example) flags “bearing wear likely — inspect at next stop.” A person decides. This is the register’s current ceiling for learned diagnosis. |
| 3 · Operator-approved | The system prepares a specific action — reduce speed to 80 % — and it runs only after the operator confirms it. |
| 4 · Bounded supervisory | A model predictive controller trims the flow setpoint on its own, but only inside hard limits and rate clamps enforced by logic it cannot modify. |
| 5 · Direct closed-loop | The PID loop holding the flow — deterministic, verified control acting every scan. No learned method is assigned this level here. |
The envelope architecture
In plain terms: the model may adjust how the plant runs, inside a fence it cannot move — and keeping the plant safe does not depend on the model at any point. This is the pattern the register’s placement and independent-protection fields point at: the learned policy holds operational authority inside an envelope; a verified non-learned layer holds the safety function and the veto. The safety-function path never routes through the learned layer.
flowchart LR
S["Sensors /
process state"]
subgraph LL["Learned layer — operational authority ≤ 4 (architectural ceiling)"]
M["Learned policy
(model, optimiser, soft sensor)"]
end
subgraph VL["Verified non-learned layer — holds the safety function"]
ENV["Envelope check
range · rate · task space
freshness · plausibility"]
VETO["Veto / clamp /
defined failure response"]
end
SIS["Safety functions
ISO 13849-1 · IEC 62061 · IEC 61511
(independent of everything above)"]
ACT["Actuators"]
S --> M
M -->|"proposal +
result contract"| ENV
ENV -->|in envelope| VETO
ENV -.->|"out of envelope:
reject, alarm, log"| VETO
VETO --> ACT
S --> SIS
SIS --> ACT
classDef learned fill:#e8eff8,stroke:#2b5797,color:#1e1e1e
classDef verified fill:#fdf6e3,stroke:#8b6914,color:#1e1e1e
classDef safety fill:#faeeec,stroke:#a33327,color:#1e1e1e,stroke-width:2px
classDef io fill:#f2f2ef,stroke:#a0a09a,color:#1e1e1e
class M learned
class ENV,VETO verified
class SIS safety
class S,ACT io
The veto layer as code. On a failed check it applies the application’s hazard-analysis-derived failure response — which may be bumpless transfer to a base controller, a controlled hold with a bounded lifetime, manual takeover, a defined safe state, or shutdown. A deterministic fallback is more amenable to specification and verification, but it is not automatically safe: the correct response is whatever the risk assessment requires for that loop.
# Verified, non-learned layer. Runs unchanged when the model misbehaves.
# on_fail() is the application's hazard-analysis-derived response, NOT a
# universal default — bumpless transfer, bounded-lifetime hold, manual
# takeover, a defined safe state, or shutdown, per the risk assessment.
def gate(proposal: Setpoint, state: PlantState) -> Setpoint:
if not fresh(proposal, max_age_ms=500):
alarm("model result stale")
return on_fail(state, reason="stale")
if not in_task_space(proposal, ENVELOPE):
alarm("proposal outside envelope") # the envelope vetoes every
return on_fail(state, reason="out_of_envelope") # unsafe or out-of-scope action
return clamp(proposal, RATE_LIMIT, RANGE_LIMIT)
# The safety functions (e-stop, interlocks, SIF) do not pass through here.
# They act on the actuators regardless of what this gate returns.
Method register
The full comparison — 42 methods across nine families, each with the deterministic alternative it must beat, its authority ceiling, required validation, and failure modes — now lives on its own page so it can be scanned by problem type without scrolling past the gate above.
→ Open the AI & ML Method Register — the full family-by-family comparison.
Every row is scored against the ladder and the envelope architecture on this page: no learned method is assigned level 5 or a safety function. The chemical and biological rows moved off Planned in Phase 49c to conservative evidenced ceilings: conservation of mass and energy and the deterministic feed recipe reach operator-approved; every fitted closure inside a governing model — kinetics, property methods, transport closures, fitted growth laws, the flux-balance objective — is treated as soft and capped at advisory; and the learned and hybrid rows cap at advisory, or read-only where the calibration does not transfer.
Model families and fit
The register scores individual methods; the families behind them — convolutional/temporal perception, physics-informed networks, and large language models — each have a genuine fit and a poor fit that is easy to miss. A CNN belongs on an advisory, not a trip; a PINN belongs on inverse problems, not a control-loop estimator; an LLM belongs behind a compiler and a human owner, not in the loop.
→ Model Families & Fit shows each family as capability and poor fit, including the train/test-leakage trap in the fault-diagnosis literature and the FP64/FP32 precision trap that can break a PINN on edge hardware.
The digital twin as integration spine
The working architecture is a synchronized twin with these model families hanging off it — not “AI wired to a PLC.” The twin is where the models live; it grants none of them authority. A live data mirror (one-way synchronization) is not a behavioural twin, and getting data in honestly is a different problem from letting the twin act out.
→ The Digital Twin grounds the twin vs data-mirror distinction in ISO 23247, treats the physical-to-digital and digital-to-physical directions as separate problems, and shows the device-communication seam still gated by the envelope.
Validation, drift, and the model lifecycle
The authority a method holds is perishable: a learned model degrades as the plant drifts away from what it learned, and nothing about its output announces the change. So authority must be re-earned — data lineage, honest test sets, uncertainty, drift detection, a defined failure response, rollback, and change control — or dropped when the evidence lapses.
→ Validation & Lifecycle maps those demands onto the NIST AI RMF Govern/Map/Measure/Manage functions (with the Generative AI Profile for LLM components) and provides a downloadable model-evidence ledger.
Worked architectures
Four end-to-end examples pull the whole section together — a vision inspection cell, a predictive-maintenance pipeline, a PINN soft sensor, and a read-only LLM copilot — each walked through the ladder: which rung the evidence supports, and what stays independent when the model is wrong.
→ Worked Architectures shows the envelope pattern applied concretely: three of the four top out at advisory, none holds a safety function, and every result crosses as a gated contract.
Interfaces and high-rate data
Analyse the fast signal where it is measured; send the verdict — not the waveform — across the network. Neither OPC UA nor Sparkplug assigns an AI result a standard meaning or authority, so the inference service stays publish-only and you define the result contract explicitly.
→ Interfaces & Handshakes covers the four constraints that put inference at the edge (not “the protocol is too slow”), what OPC UA and Sparkplug do and do not give you, write-authority separation via the OPC UA Observer role, and the result-contract payload.
Domain limits
- Chemical and process models: conservation is a hard engineering check; kinetics, equilibrium, transport closures, and properties still need application-specific validation. Phase 49c set their authority ceilings: the conservation layer holds a real ceiling, but a fitted closure sitting inside a governing model does not inherit that hardness and is capped at advisory.
- Biological models: classical PI/PID, recipes, and open-loop feed profiles are the reality baseline. Advanced models and soft sensors remain research or pilot patterns, and their Phase 49c ceilings sit at advisory or below — never a safety function.
- PINNs: compare against established numerical solvers. Low training loss is not evidence of a correct field, parameter, boundary condition, or safe extrapolation.
- Generated code and agentic workflows: remain offline drafts. Compilation is necessary but does not establish requirement completeness, correct abnormal behaviour, or safety suitability.
Review status
This page is generated from a corpus-owned Draft register and is Review pending. It is intended to make the next engineering question explicit, not to replace hazard analysis, detailed design review, or the applicable safety and cybersecurity lifecycle.
This site is an independent educational reference for industrial automation standards. It paraphrases and organizes guidance in original language; it is not a substitute for the official published standards, professional engineering judgment, or legal review, and content has not been independently verified against current published editions.
Items marked Review pending await technical review against the identified edition. Items marked Planned have no reviewed source material behind them. Do not rely on this site for compliance determinations, safety-critical design decisions, or legal interpretation.