When CESMII showed i3X at ProveIt! in February, I followed from afar. Watched the talks, read the RFC, looked at the GitHub.
I was skeptical. We've all seen this script before. Strong start. Then years of vendor extensions. Then back to custom adapters.
But i3X is different. It's small.
The whole spec is one API: how applications read contextualised manufacturing data, no matter what's underneath. It doesn't define your data model. It doesn't replace OPC UA. It doesn't try to solve every interop problem.
That restraint is what makes me believe it has a chance.
Why standards keep failing on the shopfloor
The standard pitch always sounds the same. Universal data model. Plug-and-play interoperability. One spec to rule them all.
A few years in, the model has thousands of types. Every vendor adds extensions to fit their existing products. The "compliant" stamp becomes a marketing badge. Every integration project still starts with custom mapping work.
OPC UA is the most disciplined attempt manufacturing has made. It works. But the Companion Specifications grew into their own ecosystem of slow-moving committees. Most plants we walk into still rely on hand-written PLC tags, custom historian schemas, and bespoke ETL.
It's not that standards are bad. It's that big standards are slow, and slow doesn't survive contact with shopfloor reality.
What i3X actually defines
i3X scopes itself ruthlessly. From the RFC:
- A REST API surface for explore, query, subscribe, and update
- A small set of resource types — namespaces, objects, signals, events
- Value-Quality-Timestamp (VQT) envelopes — quality is one of
Good,GoodNoData,Bad, orUncertain - A subscription mechanism for change streams
That's it.
It deliberately doesn't tell you how to model your factory. Your assets stay where they are — in the historian, in the MES, in OPC UA, in MQTT. i3X is a contract for how an application asks for them, not what they are.
The working group reflects that pragmatism: Highbyte, Inductive Automation, Rockwell, ThinkIQ, Siemens, AWS, Microsoft. Plus two manufacturers who lived with the silos: GE Appliances and Georgia-Pacific. Vendors who would normally each push their own model agreed on the smallest thing they could all live with.
What it took to add i3X to PREKIT
PREKIT already exposes its data through an open REST API and an MQTT-based Unified Namespace. So adding i3X was less of an integration and more of a translation.
A new Django app under edge-api/src/i3x/, mounted at /api/i3x/v1/, with the standard endpoint groups:
GET /api/i3x/v1/namespaces
GET /api/i3x/v1/objecttypes
GET /api/i3x/v1/objects
GET /api/i3x/v1/objects/value
GET /api/i3x/v1/objects/history
POST /api/i3x/v1/subscriptions
GET /api/i3x/v1/subscriptions/stream
Around 1,900 lines of Python. One new database table — for subscription state — and nothing else added to the persistence layer.
The i3X concepts map cleanly onto PREKIT's existing model:
| i3X concept | PREKIT model |
|---|---|
| Namespace | EdgeNode / HubNode |
| Object type | SystemElement, DataTag, Resource, Service |
| Signal | Signal |
| Event | Annotation |
| Property | Metadata |
| History | historian_metric table |
Relationships are derived from existing foreign keys and the system-element hierarchy on the fly. Authentication reuses our existing reader/writer permissions, and PREKIT's namespace-scoped authorization applies unchanged — i3X clients only see the parts of the namespace their token grants. Writes route through PREKIT's hub smart-write logic, which already handles edge-vs-hub ownership correctly.
If your platform already has an open API and a clean internal model, i3X is mostly a wrapper. That's the spec doing its job.
Connecting a generic client to a PREKIT hub
We pointed CESMII's reference i3X Explorer at one of our hubs to verify the contract. It connected on the first try.
On the left, the Explorer enumerates the namespace and the object types our hub exposes — SystemElement, Signal, HubNode, EdgeNode, Resource, DataTag, Service, Computation, Annotation, Metadata. None of those are i3X concepts. They are PREKIT's existing entities, surfaced through the i3X object-type contract.
On the right, the Explorer reads the namespace metadata directly: a stable URI (urn:prekit:i3x:hub:...), a display name, raw JSON. Below it, the same Explorer drills into the hierarchy — prekit-hub → Abfüllerei and so on into the actual production assets, history, and live subscriptions.
The interesting part: we wrote no code for the Explorer. It's a generic client. It only had to speak i3X. That's the whole point of the spec.
What i3X is not
If you want a standard that defines your asset hierarchy, pick ISA-95 or an OPC UA Companion Spec. i3X won't do that.
If you want guaranteed semantic compatibility between two factories, you still need to agree on naming. i3X will tell you both factories expose Signal objects with value, quality, and timestamp. It won't tell you that one calls a value Cycle Time and the other calls it Taktzeit.
And i3X is young. Tooling, conformance tests, and ecosystem support are still thin. The first wave of adoption will be vendors writing it because it's cheap to write, not customers demanding it because it's everywhere.
That's fine. That's how small standards spread.
Will European manufacturers care?
A historian in Stuttgart has the same lock-in story as one in Houston: vendor variants, custom adapters, ten different shapes of "give me the last hour of data for asset X." Most of the early i3X energy is American, but not all of it — Prosys, the Finnish OPC UA tool vendor, has demoed their Forge platform speaking i3X, pairing Smart Manufacturing Profiles with an i3X-compatible interface for Unified Namespace use cases. That's a useful signal. The risk is the one OPC UA Companion Specs faced — every regional ecosystem invents its own dialect before the small standard can travel. A Signal in Germany should look like a Signal in Texas. If we wait too long, it won't.
That's why we added it now. Not because customers are asking for it yet — they aren't. Because the cost of supporting it while the spec is small is low, and the cost of supporting fifteen vendor variants later is high.
Getting started
If you run PREKIT, the i3X endpoints are available in beta in the current hub release, mounted at /api/i3x/v1/. Your existing reader and writer tokens already authenticate against them. Nothing in your data model has to change.
If you don't run PREKIT, the spec itself is worth an afternoon of your team's time. Read the RFC. Stand up the reference Explorer. Point it at whatever IIoT platform you have. The shape of the gap will tell you a lot about that platform.
Credit to CESMII and everyone who contributed to the i3X working group. Small, focused, shippable — they nailed the brief.
Worth a look before vendor variants start showing up.
For deeper background, see our earlier post on What Exactly Is a Unified Namespace?, and on the difference between schematic and semantic data contracts — the naming-convention gap i3X deliberately doesn't try to fill.