What is i3X? The Standard That Makes Factory Data AI-Ready

i3X (Industrial Information Interoperability eXchange) is CESMII’s open, vendor-agnostic API specification for querying contextualised manufacturing data through a single interface. Version 1.0 was tagged on GitHub on 9 June 2026 and announced on 18 June 2026, supported by 44 manufacturing technology providers. It is designed to end the API chaos that keeps factory data from being AI-ready. If you already run OPC UA or Kepware-based connectivity, i3X adds the AI-ready query layer on top. It does not replace what you have.

Part of our AI for Manufacturing series. Related reading: Unified Namespace · Predictive AI vs GenAI in manufacturing

Let me start with the moment that made this real for me. Eight systems connected, live dashboards everywhere, and I still could not say which order was running when the tool drifted. Connected, and blind. That gap, between having data and being able to answer a question with it, is exactly what i3X is built to close. If you already run OPC UA or a Unified Namespace, the useful question is not what i3X is in the abstract. It is where i3X fits in what you already have. That is what the rest of this covers.

The API Chaos Problem: Manufacturing Data Silo Proliferation

i3X exists because a plant running five data platforms and five IT or AI applications can face up to twenty-five separate custom integrations, the n-by-m problem often described as „API chaos.” Every historian, MES, quality system and maintenance tool speaks its own proprietary API. Connect five sources to five consumers and you are maintaining twenty-five brittle, hand-built bridges, each one breaking whenever a vendor changes their interface. i3X is an open, common API initiative addressing a growing interoperability challenge in modern manufacturing architectures, where a wide array of platform vendors and solution providers each ship their own interface. For application developers working across multiple vendors, every new system adds integration complexity that slows innovation.

The industry keeps getting one thing wrong here. It blames the protocols. Wrong target. Protocols were solved years ago. A decent team reads data off almost any PLC, historian or database in a week. The reason connecting a machine still takes months is not the cable. It is that every application needs the data shaped, named and contextualised differently, and nobody agreed on a common way to ask for it.

„Connecting a machine still takes months, and the whole industry keeps blaming the protocols. Wrong target. Protocols were solved years ago.”

This is precisely what blocks AI. A large language model or an autonomous agent is only as good as the data it can reach and trust. When each source exposes raw, uncontextualised tags behind a bespoke API, your AI strategy runs on a data foundation that was never designed for it, which is why so many manufacturing AI projects stall in pilot purgatory. Manufacturing data silo proliferation across heterogeneous software stacks is not an inconvenience. It is the thing standing between your factory and application portability, and between your factory and AI.

Connections also behave differently from most business cases assume. They do not add up, they multiply. The tenth integration beats the first, because it has nine others to join against. Chase raw coverage instead and you get a wall of green lines that answer nothing.

What Is i3X? The Industrial Information Interoperability eXchange

i3X, the Industrial Information Interoperability eXchange, is an open, vendor-agnostic common API definition from CESMII (The Smart Manufacturing Institute) that standardises how any application accesses contextualised manufacturing information, whatever platform sits underneath. CESMII drove it to a finalised 1.0 in June 2026, and the specification and its tooling live at the official i3X site and on GitHub. Because i3X is vendor agnostic, an application written to it keeps working across platforms, enabling scalable interoperability instead of a pile of one-off integrations.

CESMII is unusually direct about the intent. In its own words, the common API exists to commoditise access to data, while leaving platform vendors free to differentiate on their capabilities. The expected result is a proliferation of portable apps, in the way common device APIs produced app stores rather than a library of drivers.

The fastest way to understand i3X is by what it is not:

• It is not a transport protocol. It does not move bytes off a PLC. OPC UA, MQTT and their peers already do that well.
• It is not a message broker. It does not replace your event bus or your Unified Namespace.
• It is not a historian or a database. It does not store your data.

i3X is the standardised query layer that sits above all of those. Connect your dashboard, BI tool or AI agent once to the i3X standard, and it keeps working when you swap the middleware or the broker underneath. Connect it to a vendor’s proprietary format instead, and you reconnect every time that vendor changes their mind. That single shift, from many proprietary APIs to one open and contextualised one, is the whole point.

How i3X Works: A Vendor-Agnostic Common API

i3X defines a base set of server primitives, grouped into four capabilities: exploratory, query, update and subscribe. Exploratory, query and subscribe methods are mandatory for a compliant server, while update is optional. Together they are the core capabilities that give an application a predictable, typed way to work with a plant’s information model:

• Discover the namespaces a server exposes.
• Explore object type definitions, so you know what a „work order” or a „machine” actually looks like.
• Retrieve specific instances of those objects.
• Navigate the hierarchical relationships between them.
• Query values, both current and historical.
• Subscribe to changes and events.
• Update current or historical values, where the server supports it.

This primitive set is the technical reason i3X is called „AI-ready.” An AI agent does not want a firehose of anonymous tags. It needs to discover what exists, understand the type and meaning of each object, walk the relationships between them, and pull both the live value and its history, all through one consistent contract. Structured, discoverable, typed access is what turns raw data into something a model can reason over instead of hallucinate around. The missing piece was never the wiring. It is the edge, the link that turns a reading into a fact, and only meaning adds that.

One boundary is worth stating plainly, because it shapes every project. The update primitive writes values, current or historical. The specification defines no operations to create, modify or delete object types, objects or relationships. Authoring the model is left entirely to the platform, which is why the question of who writes your model matters more than which platform serves it.

i3X also carries where a type came from. Every object’s metadata includes typeNamespaceUri and sourceTypeId, both required fields, so a client can trace a type back to its originating definition, whether that is an OPC UA companion specification, an ISA-95 namespace or a vendor’s own. The pointer is standardised. What no part of the specification does is oblige two sites to point at the same definition, or check that the referenced definition was honoured.

i3X Explorer and Developer Tooling

Around the specification sits real tooling. ACE Technologies publishes the official cross-platform i3X Explorer, a GUI client for browsing the address space of any compliant i3X server. There is a public demo endpoint with a Swagger page, an open-source MCP server (more on that below), and the 1.0 release ships with an OpenAPI specification, a Python client library and a Conformance Test Suite that grades an implementation with one of four verdicts: Full 1.0 Compliance, 1.0 Compliance with Immature Type System, 1.0 Compatible or Not Compliant.

That second verdict is the interesting one. An implementation can pass every test in the suite and still be marked as carrying a thin type system, which is CESMII acknowledging in its own tooling that a compliant API and a modelled one are two different things. The specification and its reference material live in CESMII’s public GitHub, which is where the governance and the open-source contribution model live too.

i3X vs OPC UA: Where Each Standard Fits

i3X does not replace OPC UA. OPC UA moves data off machines at the edge, and i3X standardises how IT and AI applications query already-contextualised data above it. They operate at different layers and solve different problems.

	OPC UA (and Kepware)	i3X
Domain	OT / edge	IT / application
Job	Get data off PLCs, devices, historians	Query contextualised information across systems
Pattern	Client/server plus pub/sub	Pull / query (current and historical)
Consumer	SCADA, historians, edge	Dashboards, BI, analytics, visualisation, AI agents
Latency	Real-time, sub-second	Query-time, request and response

If you run OPC UA connectivity today, very often through Kepware, the question you will actually ask is whether i3X replaces your existing OPC UA layer. It does not. It complements it. OPC UA keeps doing what it is good at, which is reliable, real-time acquisition from the shop floor. i3X sits above as the application-facing query interface, so the analytics stack and the AI agents stop caring which historian or broker the data came from. Your edge investment stays exactly where it is.

The Data Access Model: Where i3X Sits in the Stack

CESMII places i3X inside what it calls the Data Access Model, comparing the i3X tech stack to the one behind an ordinary web browser. That comparison is worth keeping. A browser does not fetch bytes off a disk controller, it asks a well-defined layer above for a document. i3X plays the same role for manufacturing information. OPC UA and MQTT do the heavy lifting at the lower, edge-facing layers, and i3X operates above them, where data has already been given structure and meaning. The specification is explicit that information reaching the API is assumed to have been processed by contextualisation functions first. Seen this way, the „i3X versus OPC UA” framing dissolves. They are neighbours in the same stack rather than rivals for the same rung.

i3X and the Unified Namespace: The Missing Query Layer

A Unified Namespace handles real-time, event-driven pub/sub over MQTT or NATS. i3X adds the standardised pull/query interface that a UNS was never designed to provide for IT and analytics systems. The two are complementary, but there is a subtlety here that most explanations skip, and it matters enormously for AI.

A Unified Namespace is genuinely good for telemetry: a temperature, a machine load, a cycle count, where the newest value simply replaces the old one. The trouble starts when the same single tree is treated as the one source of truth for transaction data too, meaning work orders, recipe versions, batch records and quality results. That data has a life. A shift booked as good gets scrapped two days later when quality catches up. The record is created, corrected, sometimes reversed, and its history is the entire point (more on this in From Signal to Structure). Pour both kinds of data into one last-value namespace and the telemetry looks fine while the transaction data quietly rots.

„MQTT keeps only the latest value. An order is not a latest value. Its history is the entire point.”

There is a deeper issue too. Even when a broker delivers a value perfectly, it cannot tell you the value is right. Two systems publish. One says the lot was 100, the other 240. The broker hands both over with a tidy timestamp and never says which is wrong. Delivery was solved long ago. Truth was not. Clean is not the same as true, and a diagram that wins a keynote still has to survive a purchase order on a Tuesday.

This is why i3X matters as more than a convenience. It gives IT, analytics and AI a standardised query interface over contextualised data, current and historical, with relationships intact, sitting above the message broker rather than instead of it. A single-tree UNS is an excellent telemetry bus and a poor source of truth. Read from top to bottom, the stack looks like this: IT and AI clients, then the i3X API layer, then the message broker at the core of your UNS, then data harmonisation and protocol converters, and finally the OT layer.

i3X and AI: The Connection to MCP (Model Context Protocol)

If MCP is the grammar that lets an AI agent connect to a data source, i3X is the vocabulary of the factory: the shared definitions of what a work order, a batch or a machine actually is. Together they make manufacturing data usable by AI agents. The Model Context Protocol is an open standard for connecting AI agents to tools and data, and i3X is what gives that connection something meaningful to talk about.

The two fit together deliberately. i3X 1.0 ships with an official MCP server, published on GitHub and npm, that works against any compliant i3X endpoint. A natural-language question can be answered against a real plant: the agent discovers the model, queries the data and returns an answer grounded in the plant’s own context. HighByte has shown a similar result from another angle. In its public demonstration, an agent built in Microsoft Foundry connects to the i3X Server in HighByte Intelligence Hub using only the i3X OpenAPI specification, and works with modelled plant data without any bespoke integration.

This is also where discipline matters, and where I use the term DefensibleAI. Get the layer underneath wrong and the AI on top gives fluent, confident answers on data that quietly disagrees with itself, and the first time someone challenges a recommendation there is no way to show how it was reached. Put AI on top of a system that logged the what but never the why, and the agent inherits the same blind spot. The order I insist on is simple. Separation first, discovery second, intelligence third. i3X is what makes the discovery layer trustworthy, so the intelligence layer is answerable.

„The AI on top gives fluent, confident answers on data that quietly disagrees with itself. And the first time someone challenges a recommendation, there is no way to show how it was reached. Separation first. Discovery second. Intelligence third.”

From Beta to i3X 1.0: Version History and What’s Included

i3X moved from beta in April 2026 to a complete 1.0 specification, tagged on 9 June and announced on 18 June 2026. That release date matters. A lot of material still circulating online describes i3X as „alpha” or „pre-release.” It is not. It is finalised and implementation-ready today.

The 1.0 package delivers the full toolkit needed to build and verify a real implementation:

• Implementation Guide
• OpenAPI Specification
• Conformance Test Suite
• Updated i3X Explorer
• Python Client Library
• MCP Server
• SDK documentation

There is one more thing worth knowing before you plan around it. CESMII has said the API definition is now stable, and that until a new charter is established in late 2026 to begin work on vNext, only documentation and demo issues will be addressed. Specification changes and new features go to vNext. For a project starting now, that means the interface will not move under you this year, and there is a named window for the things you wish it did differently.

So 1.0 goes well past a whitepaper. It is a specification with the tooling, tests and reference clients to put it into production. For an emerging standard, that is unusually complete, and it is what makes building on i3X a reasonable bet.

Who Is Adopting i3X? Vendors, Ecosystem and Real-World Deployments

The 1.0 announcement lists 44 manufacturing technology providers behind the standard. The specification’s own background names the platforms its contributors came from: HighByte, Inductive Automation, Rockwell Automation, Siemens and ThinkIQ, with more than fifty years of combined experience in manufacturing information software. The working group also includes AWS, Microsoft, Georgia-Pacific and GE Appliances, which is what keeps it from being a single vendor’s marketing layer. In working implementations, HighByte exposes an i3X Server from its Intelligence Hub, letting applications browse, read, write and subscribe to modelled data through the standard. ACE Technologies’ i3X Explorer, covered above, gives developers a ready client to test those servers against.

Backing a standard and shipping it are two different counts. Publicly verifiable i3X interfaces are still far fewer than the 44 providers named in the announcement, which is normal a few months after a 1.0 release and worth knowing when you plan around it.

Analyst attention has followed. ARC Advisory Group’s Colin Masson published a detailed piece on how i3X addresses the context-engineering gap in industrial data fabrics, and in the 1.0 announcement LNS Research’s Matthew Littlefield noted that i3X is being implemented by technology providers and deployed by end users at the same time.

Who Is Behind CESMII and the Smart Manufacturing Mindset?

CESMII, The Smart Manufacturing Institute, is the United States’ institute for smart manufacturing. Founded in 2016 and funded by the US Department of Energy, the not-for-profit consortium has a total investment commitment of USD 201 million from DOE funding and public and private contributions. Its programme and administrative home is UCLA, and it is part of the Manufacturing USA network of institutes. i3X is one output of that consortium’s broader Smart Manufacturing programme, which is why it is governed as an open standard rather than owned by any single company. CESMII frames this work through what it calls the Smart Manufacturing Mindset, and i3X is the interoperability piece of it.

Bringing i3X Into Your Existing OT/IT Stack: A Practical Adoption Path

For a manufacturer already running OPC UA connectivity, very often through Kepware, adopting i3X means adding a contextualised query layer on top, not re-architecting the OT stack. This is where most explainers stop and where the practical work actually begins. Here is the path we follow with clients in our digital manufacturing projects:

1. Assess your connectivity maturity. Map what you already have: historians, a Unified Namespace, OPC UA and Kepware-based acquisition. i3X assumes reliable data acquisition already exists. It does not rip it out.
2. Contextualise the data with information models. Raw tags become meaning through models. Use CESMII’s Smart Manufacturing Profiles, or an ISA-95-aligned structure that keeps each production order as three separate records: the product definition (the recipe), the operations request (the plan) and the operations performance (the actual result). Recipe, plan and performance, never mixed.
3. Expose contextualised data through an i3X-compliant server. This is configuration, not code. A connector scans what a system already exposes, maps it to a standard profile with AI help at design time only, and generates a checked configuration your existing middleware runs. It never touches the live stream. The first machine of a type is real work. The hundredth takes minutes.
4. Connect your IT, analytics and AI clients through the standard, including MCP-based agents, against one stable interface.

„Configuration, not code. It never touches the live stream. The first machine of a type is real work. The hundredth takes minutes.”

The strategic point sits underneath all four steps: the schema is the asset. Configuration is data. You version it, review it, roll it back and own it. That is what sovereignty really means. Sovereignty is not about where the servers run. It is about who owns the model that defines what a work order is and what OEE means. You can rent that model inside a vendor’s platform and, the day the contract ends, walk out with the rows and leave the meaning behind. Or you can keep it as your own standard-based schema. When Schneider Electric announced an agreement to acquire Cognite for USD 3.1 billion on 30 June 2026, buying the layer that sits on top of factory data, that choice stopped being abstract. Own the brain, do not rent it. i3X is what makes owning it practical. The same logic applies to your audit trail. If the history that proves what happened can be quietly edited, or lives in a store the vendor controls, it is not really yours.

When i3X Is (and Isn’t) the Right Choice

i3X is a strong fit for multi-vendor environments, portable application development, brownfield integration, and multi-site analytics or OEE dashboards where consistency across plants is the goal. It is not the right tool for hard real-time control loops, very high-throughput event streaming, or a single-platform shop where there is nothing to interoperate with yet. Knowing where it does not belong is part of using it well.

If you mapped your own plant tomorrow, which single connection would unlock the most answers you cannot get today?

About the author

Tobias Lante is an AI Agent Architect for Manufacturing at Transition Technologies PSC, where he works on making factory data usable, and defensible, for AI. On LinkedIn he writes a running series on Industrial DataOps and i3X, including From Signal to Structure, What Each Connection Is Worth and The Graph Comes Out of the Schemas. His commentary on the i3X beta launch was also highlighted in the Hannover Messe 2026 episode of the Frenus podcast Best of LinkedIn: Smart Build & Manufacturing. Follow his work on LinkedIn.