By Ian Johnson, Director of IoT Tech Expo
The benefits of AI in the IIoT space are often presented as singular case studies that affect only one area of operations of a particular, homogeneous fleet. The reality of most enterprise-scale deployments is more complex. In a smart city, whole categories of specialized technology coexist and have to interact. Power, CCTV, transport, and utilities each have their own data model, their own hardware, and their own software lineage. The same is true of a mining major running legacy concentrators alongside new digital infrastructure, or a pharmaceuticals group standardizing across continents.
A single-site AI pilot is the easy part. The hard part is deploying AI across a fleet where every site has a different vendor stack, a different data model, and a different tolerance for autonomy, and where the synchronized operational context that makes the AI defensible changes by the second. To get there, a lot of groundwork needs to be covered.
What a digital twin actually is
A digital twin is not a model, a dashboard, or a knowledge base. The Digital Twin Consortium defines it as an integrated, data-driven virtual representation of real-world entities and processes, with synchronized interaction at a specified frequency and fidelity, implemented on integrated and synchronized IT, OT, and ET systems that use real-time and historical data to represent past and present, and to simulate predicted futures.
That synchronization property, which binds live sensor streams, alarm states, process values, and engineering context to a specified frequency and fidelity, is not a peripheral feature. It is the property that distinguishes a digital twin from a static model or a document store. It is also the property that makes any downstream AI decision defensible to an auditor. An AI agent reasoning about a snapshot is not reasoning about an operation.
This matters for how AI is designed on top of the twin. Real-time operational data is a first-class input to an industrial AI agent, not an edge case. A framing that treats “how AI consumes data” as synonymous with “vector database” quietly writes the synchronization property out of the picture. The DTC’s two frameworks are built to keep it in.
Two frameworks, one order of operations
To aid organizations building complex digital twin systems, the Digital Twin Consortium offers two frameworks designed to be used together.
The Digital Twin Capabilities Periodic Table (currently at version 1.2, with YAML and JSON schemas published in the DTC’s public GitHub repositories) defines the abilities needed to design and operate a digital twin without tying requirements to any single vendor stack. It organizes those abilities into six categories: Data Services, Integration, Intelligence and Cognition, User Experience, Management, and Trustworthiness.
The AI Agent Capabilities Periodic Table (AIA CPT) does the same job for agentic systems inside industrial digital twins. It defines 45 capabilities across six categories: Perception and Knowledge, Cognition and Reasoning, Learning and Adaptation, Action and Execution, Interaction and Collaboration, and Governance and Safety.
Considered together, they answer three questions in order: what the digital twin has to do before AI is useful, what the AI has to do once the twin is in place, and where the two layers need the same governance controls applied consistently. That order matters. Most failed industrial AI pilots in 2024 and 2025 inverted it.
The Digital Twin framework in detail
For companies with large and diverse IIoT fleets, the starting condition is usually a shortage of common requirements across messy estates of sensors, PLCs, SCADA systems, data archives, engineering systems, and enterprise applications. The Digital Twin framework assumes that situation as the baseline.
The Data Services category covers acquisition, ingestion, streaming, transformation, contextualization, aggregation, storage, and repositories for twins and AIs. The Integration category covers OT and IoT integration, connection to engineering and enterprise systems, collaboration platforms, and API services. Intelligence and Cognition covers the analytical, modeling, and AI capabilities that reason over that data. User Experience covers monitoring, visualization, and interaction. Management covers lifecycle, orchestration, and operational administration. Trustworthiness covers security, safety, reliability, resilience, and privacy as first-class design properties.
The Digital Twin Consortium distinguishes explicitly between an ability and a technology. An ability is a way to achieve an outcome. Any given product represents one possible way of supplying that ability, and no global fleet is ever standardized on a single vendor or product range. An ability-led method gives central engineering a procurement and design language that does not force every site into the same template.
One plant may run older control systems and bespoke data storage. Another may run cloud brokerages and edge control. Both may need the same underlying abilities, such as streaming, real-time processing, device management, and security oversight, supplied through entirely different technology stacks. Defining capability first lets enterprises draw equivalence across what looks, at the product layer, like incompatible estates.
The AI Agent framework for IIoT
The AI Agent Capabilities Periodic Table provides the same kind of framework for the intelligence layer that sits inside or beside the twin. Its six categories work from input through output:
- Perception and Knowledge: environmental sensing, knowledge bases, structured and unstructured context.
- Cognition and Reasoning: decision-making, planning, problem solving, multi-objective trade-offs.
- Learning and Adaptation: model updating, feedback loops, experiential refinement.
- Action and Execution: tool and API invocation, code execution, content generation, actuation.
- Interaction and Collaboration: human-agent and agent-agent coordination.
- Governance and Safety: explainability, autonomy bounds, ethics, privacy, risk, access control.
One deliberate feature of the Perception and Knowledge category is worth naming. Structured inputs, including ontologies, knowledge graphs, and engineering models, are assets for an industrial AI agent, not liabilities. Retrieval from a vector database is one pattern, and it is useful for unstructured document sources. Structured retrieval from a semantic layer is a different pattern, and for industrial agents acting on synchronized operational context, it is often the pattern that makes a decision defensible after the fact.
A second feature of the AIA CPT is that it provides a disciplined answer to the problem of “agent-washing”. A conversational assistant that answers maintenance questions, a workflow agent that files a work order, and an autonomous agent that adjusts a setpoint are three distinct systems with three distinct risk envelopes. The market frequently uses the same word, agent, for all three. The AIA CPT forces the conversation onto the specific capabilities each one actually has: which decisions it makes, which tools it calls, which limits it respects, and how its decisions are traced. Vendor marketing does not survive that level of resolution for long.
A third feature is the distinction between read-path and write-path agents. A read-path agent proposes: it surfaces an anomaly, recommends a maintenance window, drafts a work order for human approval. A write-path agent acts: it changes a setpoint, opens a valve, commits a procurement. Those are different procurements, different audit requirements, and different autonomy envelopes. The AIA CPT’s Action and Execution and Governance and Safety categories are where that distinction is made concrete.
Substrate first, intelligence second
The Digital Twin framework can be used to specify and define what the DTC calls the substrate: what data comes from the fleet, how it is cleaned and contextualized, where model metadata lives, which engineering and business systems need to connect, and which controls are mandatory for cybersecurity and governance.
The AI framework sits on top of that substrate and decides what intelligence is deployed against it.
- Prediction only makes sense if rich data history exists and is accessible.
- Prescriptive recommendations only make sense if business rules and objective functions are explicit.
- Action and execution only make sense if APIs, workflow controls, and safety limits are solid.
- Multi-agent coordination only makes sense if messaging, protocol support, observability, and conflict handling are reliable.
The frameworks do not remove the engineering work. They force the order of operations. That ordering is the jumping-off point for one of the Learning Hub in-person events at IoT Tech Expo North America in May 2026, where the Digital Twin Consortium’s Pieter van Schalkwyk will run a workshop on using the frameworks to determine the necessary technology for developing viable digital twins with generative AI.
Complex realities
Consider a company running a mixed fleet of pumps, chillers, conveyors, substations, and warehouse systems across several countries. The Digital Twin framework allows it to standardize requirements. Acquisition, streaming, contextualization, OT and IoT integration, and device management become visible as a whole, despite an installed base that spans vendors and generations. The AI framework then helps choose the right AI role for each use case.
One site might need a workflow agent that prepares work orders, fetches manuals, and routes approvals. That is a read-path role with human approval on every action. Another might need a cognitive agent that compares failure scenarios and recommends maintenance windows. That is richer reasoning, still read-path. A third might need a coordinated multi-agent system that routes plant events across message brokers, enterprise queues, and SCADA links, where at least one agent has a write-path capability that hits physical equipment. Those are three different procurements against three different sections of the AIA CPT, not three variants of the same product.
The important point is that these choices are made against explicit capability definitions rather than against marketing materials.
Oversight as a separation principle
Governance benefits from the same symmetry across both frameworks. The Digital Twin framework treats trustworthiness as part of core design, covering encryption, device security, safety, reliability, and resilience. The AI framework mirrors that in AI-specific terms, covering lifecycle management, monitoring and observability, scaling, risk management, access control, and explainability.
But the frameworks do something the market does not yet do consistently: they describe the twin layer and the AI layer in terms that allow an independent governance review. That independence is the point. Industrial safety standards have long required it at the control layer. IEC 61511 calls for the Safety Instrumented System to be separate and independent from the Basic Process Control System, to the extent that SIS integrity is not compromised. The reasoning is structural: a single system cannot be both the actor and the auditor of its own actions without losing the ability to fail safe.
The same logic applies one layer up. The substrate that executes an agent’s decision, and the governance layer that classifies, traces, and approves that decision, need to be independent for the same reason. A vendor whose revenue scales with agent throughput carries an incentive mismatch when asked to rate-limit its own agents against a cross-vendor risk register.
Many industrial AI pilots fail when governance arrives late and collides with the reality of operations. Paired frameworks that describe both the twin layer and the AI layer in language that legal, security, operations, and engineering teams can all review before deployment are a structural answer to that failure mode.
Machine-readable, tooling-ready
The Digital Twin Capabilities Periodic Table v1.2 and the AIA CPT both ship with machine-readable YAML and JSON definitions and reference implementations in the DTC’s public GitHub repositories. That matters for two reasons.
First, capability assessments become reproducible rather than subjective. Architecture reviews, vendor scoring, and maturity tracking can all be automated and visualized against the same reference. Second, the taxonomies can be embedded directly into internal procurement tooling, so every AI pilot in the enterprise starts from the same capability baseline, site by site.
The combination, with discipline
Effective digital twins for large IIoT fleets are not going to come from attaching a large language model to a dashboard and calling the result intelligent. The DTC materials argue that companies need two requirement maps. The first covers data, integration, intelligence, experience, management, and trustworthiness in the twin. The second covers perception, reasoning, learning, execution, interaction, and governance in the AI layer.
The two frameworks describe what is needed. The DTC’s Industrial AI Agent Manifesto, published in 2026 describes the disciplines under which agents should operate inside those capabilities: bounded autonomy, decision traceability, industrial-grade safety, and structured human oversight. Together they give engineering, operations, and compliance teams a common vocabulary before a single line of agent code is deployed.
DTC says its approach has been applied in manufacturing, energy, infrastructure, and healthcare settings to date. For enterprise companies trying to decide where AI should sit inside a digital twin program, the paired frameworks do three things the market is not otherwise doing consistently. They make capabilities comparable across vendors. They make AI claims defensible against a real requirements baseline. And they keep the governance layer structurally separate from the execution layer, applying the same discipline every regulated industrial facility already applies to its safety-instrumented systems.
That is a starting point that ages well.
TechEx is a Digital Twin Consortium Media Partner. Dan Issacs, GM & CTO of DTC, and Pieter van Schalkwyk – CEO and Founder at XMPro, are speaking at IoT Tech Expo. We look forward to seeing you there!