The vendor comes in with a laptop and a plant simulation. Every machine talks to every system. Defects surface in real time. The scheduling engine reacts. The CFO sees yield at a glance. The demo works.
Then you sign the contract and spend 18 months mapping your process into their data model.
The factory operating system promise — one unified platform to run the plant — is the most seductive pitch in manufacturing technology right now. It is also the wrong unit of analysis. Your factory is not a monolith to be managed by a single OS. It is a federation of distinct operational domains, each with its own process logic, data semantics, and decision cadence. An architecture that treats them as one system will eventually fail all of them.
What a manufacturing domain actually is
Think of the production floor not as a single system but as a set of specialized domains: the process domain (what are we making, to what specification, in what sequence?), the equipment domain (what is the line's current state and capability?), the quality domain (what does the product measurement history tell us?), the planning domain (what does the schedule say should be happening right now?).
Each domain has different time horizons, different consumers, and different standards governing what the data means. ISA-88 defines the process model — recipe, phases, unit operations. ISA-95 defines the equipment hierarchy and the interfaces between manufacturing and business systems. These standards don't describe a single system. They describe a federation of boundaries with defined handoffs between them.
A platform that collapses these domains into one data model isn't simplifying the architecture — it's hiding the boundaries. Hidden boundaries are where integration debt accumulates.
The standard interface is the architecture
The right alternative is not a different platform. It is to standardize the interface between domains and let each domain use whatever technology fits its process logic.
This is the problem CESMII's i3X — Industrial Information Interoperability eXchange — was designed to solve. Released in early 2026 with endorsement from Rockwell Automation, Siemens, Inductive Automation, and major industrial end users including Georgia-Pacific, i3X defines a single vendor-agnostic REST API for querying contextualized manufacturing data across any conformant platform. CESMII's own analogy is accurate: i3X is JDBC for industrial data. Applications build against one API contract and run on any conformant backend. The integration layer becomes a commodity.
This matters because the N×M integration problem — five platforms times five applications equals 25 bespoke connections, scaling quadratically — is precisely what the manufacturing OS pitch claims to solve by consolidating everything into one vendor. i3X solves it differently: by making the interface standard, not the platform mandatory. One API, many conformant implementations, no lock-in.
The correct role of UNS and MQTT
A Unified Namespace built on MQTT is the right transport layer within and between these domains for real-time data. It solves the integration mess at the event layer — every producer publishes to one broker, every consumer subscribes to what it needs. That is a real and significant improvement over the point-to-point custom adapter sprawl it replaces.
But the UNS is a pub/sub layer. It delivers events; it doesn't answer queries. It addresses where data comes from, not what it means in the context of the process currently running on that line. i3X fills that gap — the query interface that lets an application ask what the process state was on Line 4 during Tuesday's yield drop, and get a contextualized answer regardless of which platform holds the data.
UNS and i3X are plumbing in service of the domain model. Neither is the architecture.
High-resolution data follows from the domain design
When you design by domain, the right data infrastructure follows from the decisions each domain needs to make. Process-domain events need to be captured at the cadence of the process — not at polling intervals set by a historian's default configuration. Anomaly detection that needs to act at process speed belongs at the edge, where inference latency is bounded by the local network, not a cloud round-trip.
Analysis of AI-ready manufacturing networks makes the point directly: semantic enrichment at the edge — tagging sensor data with process state, phase, and deviation context before it leaves the plant network — is the foundation of scalable industrial AI. Sending raw streams to a cloud endpoint and expecting it to infer context it was never given produces the expensive and underperforming analytics programs that populate most manufacturers' lessons-learned files.
Start with the domain question
The right sequence: define the business domain and the decisions it needs to make. Identify the standards that govern domain boundaries — ISA-88, ISA-95, and i3X for the query interface between them. Build or select technology that serves those standards. Require conformance from every vendor.
That sequence is the inverse of selecting a platform and mapping your process into it. It preserves the firm-specific process model as the asset it is, makes the integration layer a commodity, and leaves you free to substitute any conformant component as the technology evolves.
Your process knowledge has taken decades to build. The right technology stack is the one designed to serve it — not the one that asks it to fit a demo.