The Digital Twin as Integration Spine
The working architecture is not "AI wired to a PLC" — it is a synchronized twin with models hanging off it. The twin is where the models live; it grants none of them authority. A live data mirror is not a behavioural twin, and the two synchronization directions are separate engineering problems.
This page is part of the AI & ML Integration section; read the authority gate first. The twin does not relax any ceiling in the method register or any boundary in Safety & Security Boundaries: a learned model inside a twin holds exactly the authority the register assigns it, and no safety function routes through the twin. This page’s review basis is under audit as of Phase 55.0; the canonical corpus note remains a Draft.
What a digital twin is — and the distinction that matters
A published framework already defines the term, though only at second hand here. A NIST government publication summarising ISO 23247 (Digital Twin Framework for Manufacturing) describes a digital twin as a digital representation of an observable manufacturing element, scoped to a particular purpose rather than built as a general-purpose replica, that stays synchronized with the element it represents. Gap: NIST’s summary of the ISO 23247-1 definition, not the licensed clause text itself — Phase 55.1. Two words carry the weight: synchronization (the digital side is kept current with the physical side) and fit for purpose (the twin is scoped to a use case, not a general-purpose replica).
The distinction the rest of this page turns on is the direction and richness of that synchronization:
- A live data mirror — dashboards, tags, historian trends — has one-way synchronization: it receives data and shows it. It is useful, and it is not a behavioural twin. (NIST’s summary of the literature notes that long-standing jet-engine monitoring “twins” receive data from the physical object but give no control feedback — one-way synchronization.)
- A behavioural twin adds asset identity and relationships, calibrated behavioural models (estimation, simulation, prediction, diagnosis, optimisation), lifecycle history, and validated use cases on top of the synchronized state. It answers “what is happening that I cannot measure” and “what happens next,” not only “what does the sensor read.”
A dashboard becomes more twin-like as it gains those properties — it is a spectrum, not a badge.
Honest caveat. The field has no single agreed definition. ISO 23247 is a manufacturing framework and a reference architecture — not a functional-safety or model-validation standard. Synchronization is not authority: being current says nothing about being correct, and nothing in ISO 23247 lets a learned model hold a safety function. (The ISO body was not read; the definition and reference model here are verified via a NIST government publication that cites the standard.)
The framework’s shape — named seams, not a product
ISO 23247 is a four-part series (2021) — Part 1 overview, Part 2 reference architecture, Part 3 digital representation, Part 4 information exchange — extended by Part 5:2026 (digital thread). Its reference model is organised as four domains, and the seam that matters for AI safety is the one that can turn a digital output into a physical action.
flowchart TB
subgraph OME["Observable manufacturing domain"]
P["Equipment · material · process · personnel
(the thing being twinned)"]
end
subgraph DC["Device communication domain — the seam that matters"]
SYNC["Data exchange + synchronization
…and command / actuation signals"]
end
subgraph DT["Digital twin domain"]
STATE["Synchronized state + models
(CNN · PINN · LLM)"]
end
subgraph USER["User domain"]
U["Applications · operators"]
end
P -->|"physical → digital
(telemetry)"| SYNC
SYNC --> STATE
STATE --> U
STATE -.->|"digital → physical
(gated by the envelope)"| SYNC
SYNC -.->|"approved / bounded action"| P
X["Cross-system entity
data translation · assurance · security"]
X -.- DC
classDef phys fill:#f2f2ef,stroke:#a0a09a,color:#1e1e1e
classDef seam fill:#fdf6e3,stroke:#8b6914,color:#1e1e1e,stroke-width:2px
classDef digi fill:#e8eff8,stroke:#2b5797,color:#1e1e1e
class P phys
class SYNC seam
class STATE,U digi
class X phys
The device communication domain carries data exchange and synchronization, and — per the NIST summary of the framework, not a reading of the licensed clause text — also transfers commands and signals for control and actuation. Gap: attributed to ISO 23247 via NIST summary; licensed text not read — Phase 55.1. That is where the authority question lives, and where the interfaces & result contract mechanics apply.
Two directions, two different problems
Treating “the twin” as one bidirectional pipe hides the two hardest questions. Split it.
Physical-to-digital — getting the twin honest. This is a data-integrity problem, not a modelling one: identify each input’s asset/unit/range/meaning; preserve source and acquisition timestamps, quality, and missing-data state; align to scan, trigger, batch, recipe, and mode; reject or mark stale, substituted, frozen, impossible, and out-of-sequence data; record which twin values are measured, derived, or predicted — never let a prediction silently read as a measurement; and monitor residuals and drift between predicted and observed state.
Digital-to-physical — letting the twin act, carefully. A twin’s model output is not privileged by living in a twin. It is capped at the register ceiling for that model family, and an independent non-learned layer holds the veto:
| Level | Twin / model output | Control-system treatment |
|---|---|---|
| 0 | Offline analysis | No online interface |
| 1 | Monitoring result | Read-only visualisation and logging |
| 2 | Advisory recommendation | Operator evaluates and acts separately |
| 3 | Proposed command / setpoint | Operator confirms through a governed workflow |
| 4 | Bounded supervisory output | A non-learned layer independently checks enable, range, rate, mode, freshness, permissives |
| 5 | Direct learned control | Not assigned to any learned twin output here |
Regardless of level, independent trips, interlocks, safety functions, equipment limits, and manual fallback stay effective when the twin or its models are wrong, stale, unavailable, or compromised. This is the same envelope architecture as the gate — the twin is where the models live; the envelope is still what protects the plant.
Twin maturity — a ladder of synchronization, not authority
Two different questions get confused whenever someone calls a twin “advanced”. Maturity describes how much the twin computes and how tightly it tracks the plant. Authority describes what the plant lets its output do. They are orthogonal, and only one of them is a permission. A maximally mature twin holds exactly the authority the method register assigns its composing models — advisory for twin state synchronization, read-only for the physics-informed families feeding it. Nothing on this page raises a ceiling.
The functional progression below is NIST’s published five-category twin ladder (descriptive → diagnostic → predictive → prescriptive → intelligent, ordered by “increasing complexity, more decision support, and greater value”). The synchronization grading — what the data link and state estimation actually do at each level — is this project’s engineering judgement, not any standard’s; no standard we have read defines a graded synchronization scale. M0 sits below NIST’s scale, which presumes a live twin.
| Level | Name | Synchronization character | What it answers | Prerequisites | NIST category |
|---|---|---|---|---|---|
| M0 | Offline model | No live link; snapshot or historical data | “What would happen, in principle?” | Step 1 | (below NIST’s scale) |
| M1 | Connected shadow | One-way, live telemetry inbound; no return path | “What happened, or is happening?” | Steps 1–4 | Descriptive |
| M2 | Synchronized twin | State estimation reconciles model with plant; measured / derived / predicted labelled distinctly | “What is wrong, and why?” | Steps 1–6 | Diagnostic |
| M3 | Predictive twin | Validated forward prediction over a stated horizon, with residual and drift monitoring | “What is likely to happen?” | Steps 1–7 | Predictive |
| M4 | Bounded closed-loop twin | Twin output crosses the seam under the full gated envelope | “How can we make it happen?” | Steps 1–7, the data contract, and an independent non-learned gate | Prescriptive / Intelligent |
flowchart LR
M0["M0
Offline model
no live link"]
M1["M1
Connected shadow
one-way telemetry"]
M2["M2
Synchronized twin
reconciled state"]
M3["M3
Predictive twin
validated horizon"]
M4["M4
Bounded closed-loop
described, not authorized"]
M0 --> M1 --> M2 --> M3
M3 -.-> M4
GATE["Authority is set by the method register at every level —
maturity is never an authority argument"]
GATE -.- M2
classDef live fill:#e8eff8,stroke:#2b5797,color:#1e1e1e
classDef off fill:#f2f2ef,stroke:#a0a09a,color:#1e1e1e
classDef future fill:#fdf6e3,stroke:#8b6914,color:#1e1e1e,stroke-width:2px,stroke-dasharray:4 3
classDef note fill:#ffffff,stroke:#a0a09a,color:#4a4a4a
class M0 off
class M1,M2,M3 live
class M4 future
class GATE note
M4 is described here, not authorized. No method row grants a twin-composed learned output more than advisory authority, so reaching M4 needs a new evidence case at the register — not a reinterpretation of this page. The published ladder agrees: NIST states intelligent twins are “envisaged to” control their physical counterparts, in the future tense. The internal register and the external source describe the top rung the same way — somewhere the field intends to go, not somewhere it is.
Two rules follow. Declare the target maturity per use case at concept design, and refuse features belonging to a higher level than the data-integrity work supports — a twin asked for M3 answers on M1 plumbing is not ambitious, it is unvalidated. And a maturity claim never appears in an authority argument: “the twin is mature enough to close the loop” is not an engineering statement. The register row is the only authority statement, and it is reached through evidence, not capability.
The data contract across the seam
Because the device-communication seam can carry an action, its payload must be self-describing enough to be gated: asset and signal identifiers; a request/correlation ID; source and inference timestamps; input and output quality; value, class, prediction horizon, and uncertainty; model, feature-pipeline, and calibration versions; a valid-until / maximum-age; twin synchronization state; service health and fallback state; the requested authority level and action type; and acknowledgment, rejection reason, and audit identity. The last items are what let a verifiable non-learned layer accept, clamp, or veto a proposal — and let an audit reconstruct the decision afterwards.
→ Download the twin data-contract schema (JSON Schema draft 2020-12) · worked example payload
Both are generated from the same field definitions the toolkit’s cst twin-validate check enforces, so
the published schema cannot drift from the check. The companion cst twin-sync measures whether the
telemetry feeding the twin actually has the synchronization properties M1–M3 above claim — gaps,
out-of-order arrivals, staleness, and clock drift. See the
engineering toolkit.
Neither tool acts: a clean result means a proposal is well-formed enough for a gate to judge, never
that it is safe or authorized. The gate itself is plant-side engineering.
The model families inside the twin
The twin is a spine; the models hanging off it are the same families the register scores, at the same ceilings (see Model Families & Fit):
- CNN / perception turns images, thermal frames, and 1-D signals into features or classes — advisory only; a classification must not silently become a plant fact.
- PINN / physics models connect sparse measurements to unmeasured state (parameter/field estimation, calibration, surrogates) — the physics term constrains learning but does not prove accuracy, stability, real-time performance, or validity outside the calibrated regime; never close a loop on it.
- LLM / knowledge operates over the twin’s semantic and historical context through read-only, allow-listed tools — curated twin context, not raw tag streams, with schema validation and (where required) human confirmation on any proposal.
What this means for design
- Say which state is measured, inferred, simulated, or manually entered, and keep predictions visibly distinct from measurements in the twin’s own state.
- Design the two directions separately — solve staleness, aliasing, and provenance on the way in before trusting any model output on the way out.
- The twin grants no authority. A model’s rung comes from the register and the safety boundary, not from living in a twin; the device-communication seam is gated by the non-learned envelope.
- Match synchronization tightness and prediction horizon to the process, and define what happens when AI output is late, missing, low-confidence, or contradictory.
- Own model change control — who approves a model change, and who approves a change to its allowed authority, before either happens.
Review status
Distilled from a corpus-owned Draft note. This page’s review basis is under audit as of Phase 55.0. The twin definition and reference model are grounded in ISO 23247 (verified via a NIST government publication; the ISO body was not read). Return to the authority gate, Model Families & Fit, Interfaces & Handshakes, or Safety & Security Boundaries.
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.