# AI in Manufacturing Podcast — Show Notes
## Episode: Scaling Industrial Intelligence with the I3X Common API
**Podcast Name:** AI in Manufacturing Podcast (Industry40.tv)
**Episode Title:** Scaling Industrial Intelligence with the I3X Common API
**Guest Name:** Matthew Parris
**Guest Title/Role:** Director of Quality Test Systems, GE Appliances; Leading Contributor to the I3X Specification
**Host:** Kudzai Manditereza
---
## 1. Episode Summary
This episode explores how the Industrial Information Interoperability Exchange (I3X) common API is poised to become the universal interface for accessing manufacturing data across software platforms. Matthew Paris, Director of Quality Test Systems at GE Appliances and a leading contributor to the I3X specification, explains why the manufacturing industry has lacked a standardized way to retrieve information from Level 3 and Level 4 software systems — and how I3X solves this by leveraging simple, proven IT technologies: HTTP and JSON. Paris draws a compelling analogy between I3X and the early web browser revolution, comparing the I3X Explorer tool to Netscape's role in breaking down walled-garden internet portals. The conversation covers how I3X differs from OPC UA and MQTT, why a vanilla MQTT broker is insufficient for a true Unified Namespace, and how standardized interfaces accelerate AI deployment in manufacturing. Listeners will gain a clear understanding of where I3X fits in modern industrial architectures and why now is the time to get involved with the specification while it's in beta.
---
## 2. Key Questions Answered in This Episode
- What is I3X and what problem does it solve for manufacturers?
- How is I3X different from OPC UA and MQTT?
- Why is an MQTT broker alone not sufficient for a Unified Namespace (UNS)?
- How does I3X enable manufacturers to scale from data visibility to operational AI?
- Where does I3X fit in a modern industrial architecture alongside UNS and MQTT brokers?
- Why does I3X support OPC UA Part 5 information models, and how should manufacturers think about data typing?
- How will I3X achieve vendor adoption without a chicken-and-egg problem?
---
## 3. Episode Highlights with Timestamps
**[0:00]** — **Introduction & Guest Background** — Matthew Paris introduces his role at GE Appliances, where his team functions as an internal OEM, system integrator, and end user simultaneously.
**[3:12]** — **The Origin of I3X** — Paris describes the frustration of learning unique REST APIs for every software product and the "data access model" stack that manufacturers must navigate.
**[8:55]** — **The Shifting Risk in Manufacturing Software** — Discussion on how the real risk has moved from picking the right vendor to maintaining the ability to adapt as technology evolves.
**[10:23]** — **Monoliths Breaking Apart** — Why specialization and the proliferation of vendors demand a stable architectural foundation with standardized interfaces.
**[14:37]** — **Claude and AI as Software Developers** — How AI coding assistants make standardized interfaces even more critical — it's easier to tell Claude to build against one standard than 20 proprietary APIs.
**[16:21]** — **From Dashboards to AI Intelligence** — Paris explains the journey from visibility (polling/dashboards) to subscription-based intelligence and why AI agents need structured, typed, and related data.
**[24:35]** — **What I3X Actually Is** — A concise breakdown: HTTP + JSON + a handful of standard methods (explore, read current value, read historical values, subscribe). The 80/20 rule applied to data access.
**[34:49]** — **I3X vs. OPC UA** — Why OPC UA's own cloud reference architecture still just says "HTTP REST," and how I3X fills that gap with a defined, common contract.
**[41:50]** — **I3X and the Unified Namespace** — Paris explains why an MQTT broker is "woefully insufficient" for a UNS and how I3X wraps around information sources including brokers like HiveMQ Pulse.
**[50:23]** — **OPC UA Information Models in I3X** — How I3X is silent on which types you must use but enables you to leverage OPC UA companion specs, custom namespaces, or both.
**[58:22]** — **Adoption Strategy & Vendor Momentum** — Why I3X avoids the chicken-and-egg problem: software-level deployment, minimal lift for vendors, and early adoption from Ignition, HiByte, Microsoft Azure, AWS, HighByte, FlowSoftware, and others.
---
## 4. Key Takeaways
- **I3X is the "web browser" for manufacturing data:** Just as Netscape eliminated walled-garden internet portals, I3X provides a single, standard interface to connect to any manufacturing software and retrieve information — using nothing more than HTTP and JSON.
- **REST alone is not enough:** Having a REST API does not guarantee interoperability. Without standardized methods, encoding (JSON), and capability definitions, every software product's API is still a bespoke integration project.
- **An MQTT broker is not a UNS:** A vanilla MQTT broker lacks the ability to serve current values on demand, enforce data governance, advertise data types, or represent multi-dimensional relationships. Products like HiveMQ Pulse exist precisely because a broker alone is insufficient.
- **AI agents need structured, typed, related data:** Moving from dashboards to operational AI requires more than raw data visibility. AI agents are like new employees — they need onboarding via object types, relationships, and knowledge graphs to reason effectively.
- **I3X is deliberately minimal and opinionated:** The specification covers roughly 20% of possible capabilities but addresses 80% of real-world data access use cases: explore what's available, read current values, read historical values, and subscribe to changes.
- **The specification is in beta — now is the time to contribute:** I3X moved from alpha to beta ahead of Hannover Messe 2025. Manufacturers and vendors can influence the spec by engaging on GitHub and providing feedback on missing capabilities.
- **Vendor adoption is accelerating organically:** Because I3X requires minimal implementation effort for vendors already running HTTP/JSON endpoints, companies like Microsoft, HighByte, FlowSoftware, Inductive Automation (Ignition), and AWS are already building or demoing I3X support.
---
## 5. Notable Quotes
> "I3X Explorer is the equivalent of that Netscape experience — eliminating the proprietary interfaces and letting you access any software's information in a standard way." — Matthew Paris, Director of Quality Test Systems at GE Appliances
> "An MQTT broker is woefully insufficient to achieve the goals of what a UNS should be." — Matthew Paris, Director of Quality Test Systems at GE Appliances
> "Think of AI agents as new employees, and what you want to do is reduce as short as possible what that onboarding process looks like." — Matthew Paris, Director of Quality Test Systems at GE Appliances
> "It's embarrassingly simple — HTTP and JSON. The technology was probably hardened 10 years ago. We're 10 years too late having a standard definition for manufacturing." — Matthew Paris, Director of Quality Test Systems at GE Appliances
> "Chicken and egg is just an excuse thrown around when something is struggling to take adoption. If you're not solving the problem the right way, that's the real issue." — Matthew Paris, Director of Quality Test Systems at GE Appliances
---
## 6. Key Concepts Explained
### **I3X (Industrial Information Interoperability Exchange)**
**Definition:** I3X is a lightweight, common API specification built on HTTP and JSON that standardizes how applications query, read, and subscribe to data from Level 3/Level 4 manufacturing software systems.
**Why it matters:** It eliminates the need for manufacturers to learn and integrate against dozens of proprietary REST APIs, dramatically reducing the time and cost of software interoperability.
**Episode context:** Paris described I3X as the "web browser" equivalent for manufacturing — a universal client interface that works the same regardless of which software platform serves the data.
### **Unified Namespace (UNS)**
**Definition:** A UNS is an architectural pattern that provides a single, unified view of all operational and business data across an enterprise, organized with contextual relationships and governed data types.
**Why it matters:** A true UNS enables cross-functional data access, AI reasoning, and enterprise-wide analytics — but is frequently conflated with simply deploying an MQTT broker.
**Episode context:** Paris argued that a vanilla MQTT broker is only the first step toward a UNS, lacking data governance, type definitions, multi-dimensional relationships, and on