Manufacturing has been talking about interoperability for decades. OPC UA, MQTT, Sparkplug, the Unified Namespace, and dozens of other approaches have each promised to connect the disconnected. And yet, most manufacturers still struggle to get information out of their operational systems and into the applications that need it. A new open specification called i3X, developed under CESMII (the Smart Manufacturing Institute), takes a more IT-centric approach rooted in OT requirements, and the early signs suggest it may actually work.
The Communication Problem No One Has Fully Solved
LNS Research has studied the information-sharing challenge across hundreds of manufacturers. Our Intelligent Supply Network (ISN) research consistently shows that the companies achieving the best operational outcomes are not the ones with the most sophisticated individual systems. They are the ones with coherent information flow across their operations. The differentiator is the architecture and how it is used.
The data supports this. ISN Leaders, companies that are successfully implementing an Intelligent Supply Network, are 2.2 times more likely than Followers to frequently integrate best-of-breed software internally, and 2.4 times more likely to consolidate plant operations into a single integrated platform. These companies have figured out that the value is in how systems connect and share information. (Source: LNS Research Intelligent Supply Network Survey, 2024)
Despite these clear performance gaps, most manufacturers remain stuck in application-centric thinking. They optimize individual systems (MES, historian, SCADA, ERP) but struggle to connect them in ways that enable cross-functional intelligence. The reason is straightforward: the existing communication standards that manufacturers rely on were designed to solve different problems, and the gap between those problems and the information-sharing challenge remains open.
OPC UA has delivered significant value in device connectivity and remains foundational to industrial automation. It provides a reliable framework for reading, writing, and browsing data across control systems, and its companion specifications address real domain-specific needs. Where OPC UA struggles is at the information platform layer. Its specification is broad, its companion specs are difficult to combine, and the adoption of richer capabilities like aligned information models and consistent alarm handling varies widely between implementations. For applications that need to consume contextualized information from multiple platforms, OPC UA was not designed to solve that problem.
MQTT has similarly earned its place in industrial architectures. As a lightweight telemetry protocol for moving data from devices to applications, it is effective and widely adopted. The challenge arose when the industry extended MQTT beyond its original scope. The Unified Namespace concept layered on top of MQTT provided a useful naming convention, but it is not an information model. Late subscribers receive incomplete data, there is no built-in mechanism to discover what information is available, and vendors have added proprietary payload structures to fill the gaps. MQTT continues to work well for what it was designed to do, but it was not designed to be the application interoperability layer.
What Makes i3X Different
i3X takes a deliberately narrow approach. Rather than trying to solve every connectivity problem in the factory, it focuses on one specific challenge: connecting an application to information. It operates at the layer between information platforms (historians, contextualization engines, industrial data hubs) and the applications that consume that information (analytics, AI, reporting, custom tools).
Figure 1: The LNS Research Intelligent Supply Network Reference
Architecture. i3X targets the Standard Interfaces layer between
Platforms & Infrastructure and Industrial Applications.
The specification requires JSON as its default serialization over HTTP/REST, the same technologies that power virtually every service-oriented web application. A developer who has built a REST API understands i3X immediately. There is no membership fee required to read the specification. It is hosted on GitHub as an open-source project where anyone can submit issues or pull requests.
What i3X exposes is also well-scoped: current and historical data values, object models and metadata, and relationships between objects. Critically, the API includes exploratory methods that allow a consuming system to discover available namespaces, browse object type definitions, and navigate relationships, all without prior knowledge of the underlying platform’s data model. This introspection capability is what makes i3X particularly interesting for AI agents, which could use these methods to understand what information is available and how it is structured before querying for values.
This introspection capability matters more than it might seem at first glance. The most important interface for a software application used to be the user interface, because the users were humans. That is changing. As AI agents become the primary consumers of operational data, the API becomes the primary interface. It must be self-explanatory so that automated systems can understand what is available by examining the API itself.
That direction is already visible in the tooling. Alongside the 1.0 release, the project published an i3X connector for the Model Context Protocol (MCP), the emerging standard AI agents use to reach external tools and data. It is an early, concrete example of software reaching operational data through the API itself, exactly the change this section describes.
Timing and the AI Acceleration Effect
i3X is launching at a moment that no previous industrial standard has experienced. AI tools, particularly code-generation capabilities, dramatically reduce the effort required to implement a standard, build applications on it, and create educational content about it.
Vendors who participated in early pilots reported implementing i3X endpoints in one to two days. Several did so using AI-assisted coding against the alpha specification. This creates a positive feedback loop that previous standards never achieved: the standard is simple enough to implement quickly, AI tools make implementation even faster, and the same tools make it easy to produce articles, demonstrations, and tools that spread awareness.
At the recent ProveIt! conference, a live demonstration showed Ignition, HighByte, Siemens, Flow Software, Ace Technologies, and AWS IoT SiteWise interoperating through i3X. Post-conference, organizations from France, Germany, the US, and Canada began creating content, tools, and implementations around i3X without any prompting from CESMII. Momentum has since accelerated. By the June 2026 release of version 1.0, platform vendors and end users, including GE Appliances and Georgia-Pacific, had lined up behind the specification.
Why the Information Platform Layer Is the Right Target
Previous interoperability standards aimed at the device and controller layer, where the installed base is enormous and change cycles are measured in decades. Manufacturers do not want to update the firmware on a PLC that has been running reliably for fifteen years just to support a new standard.
i3X targets a different layer. The specification was written by industry participants experienced with the major manufacturing information platforms, including those from Rockwell Automation, AVEVA, ThinkIQ, ThingWorx, Inductive Automation, and HighByte. Inductive Automation and HighByte, along with AWS, have already demonstrated working i3X implementations. Because information platforms are updated regularly as part of normal software maintenance, vendors can add i3X support without requiring their customers to replace or upgrade hardware. This is a pragmatic advantage that device-layer standardization efforts do not have.
OPC UA and MQTT continue to serve their roles at the device and connectivity layer. i3X does not replace them. It sits above them, exposing the contextualized information that those protocols help collect. This layered positioning avoids the “standards war” dynamic that has consumed so much energy in the industrial automation community.
Figure 2: The ISN Landscape describes the characteristics of a successful Intelligent
Supply Network: openness, a common data layer, industry-relevant applications,
and flexibility per plant. Source: LNS Research
What This Means for Manufacturers
For COOs and CIOs evaluating their operational architecture, i3X addresses a gap that LNS Research has identified in our Intelligent Supply Network work. ISN Leaders prefer unique MES systems for each plant (48% vs 23% of Followers), but they do so to enable faster innovation and flexibility while still prioritizing integration across those systems. In fact, it is the most-cited reason, named by 81% of Leaders who choose unique systems. (Source: LNS Research ISN Survey, 2024)
Deploying unique systems while maintaining consistent integration across plants is exactly the pattern i3X enables. Today, achieving it requires custom integration work at each plant. A standard API at the information platform layer would let manufacturers deploy different systems per plant while maintaining a consistent way for applications to access information across all of them.
i3X provides a mechanism for that architectural standardization. If every information platform in a manufacturer’s portfolio exposes data through a common API, then consuming applications (whether purchased or built internally) can access information from any plant without custom integration for each source system.
The build-versus-buy equation is also changing. In conversations with manufacturing COOs, LNS Research is hearing consistent stories about engineers using AI tools to build application functionality that previously required enterprise software purchases. One consumer products company spent over a year rolling out a next-generation MES, only to have a single engineer use AI coding tools to rebuild the specific functionality their plant needed in under a month. Whether that prototype can mature into a supportable production application remains an open question, but the speed at which purpose-built solutions can now be created is changing how manufacturers think about software procurement. When applications can be assembled this quickly, the integration layer becomes the bottleneck. A standard API for accessing operational information removes that bottleneck.
What to Watch
As of mid-2026, i3X has moved quickly from concept to stable release. CESMII published a public beta in April 2026 and released version 1.0 on June 9, 2026. The specification is available on GitHub, with general information at i3x.dev, a live demonstration endpoint at api.i3x.dev, and conformance tests that let implementers check their endpoints against the specification. ACE Technologies also publishes a cross-platform i3X Explorer client for inspecting any compliant endpoint. CESMII has said it will hold 1.0 stable and begin planning the next version later in 2026.
A note of caution is warranted. Manufacturing has seen waves of enthusiasm about new interoperability approaches before, and many have faded without achieving the critical mass needed to matter. OPC UA, MQTT, Sparkplug, and the UNS all generated genuine excitement in their early days. Some delivered real value in specific use cases; none became the universal answer their advocates predicted.
It is also worth acknowledging that many system integrators and forward-thinking manufacturers already use JSON REST APIs to connect their systems without waiting for an industry standard. The pattern works. The question is whether formalizing it through i3X creates enough additional value (portability, discoverability, reduced vendor lock-in) to justify the effort of standardization, or whether the industry continues to solve these problems one project at a time.
The early signs around i3X are encouraging: organic community growth, rapid implementation cycles, and participation from both major platform vendors and sophisticated end users like GE Appliances and Toyota Motors North America. But encouraging early signs are not the same as sustained adoption. The critical success factor is whether enough vendors implement i3X endpoints that application developers can count on the API being available across the platforms their customers use. Without that critical mass, i3X becomes another interesting idea that did not cross the finish line.
LNS Research will continue tracking i3X as part of our Intelligent Supply Network and Industrial DataOps coverage. Manufacturers who are evaluating their operational architecture should add i3X to their watch list. For those already working with information platforms that support the specification, piloting an i3X endpoint is a low-risk way to test whether standardized information access can accelerate their Industrial Transformation initiatives.
Niels Andersen is a Principal Analyst and Research Director at LNS Research covering Intelligent Supply Networks and Operational Architecture. Connect with him on LinkedIn.
All entries in this Industrial Transformation blog represent the opinions of the authors based on their industry experience and their view of the information collected using the methods described in our Research Integrity. All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.