Why Industrial AI Fails at the Data Layer — and How IRIS Foundry Solves It Architecturally

We were grateful to learn that IRIS Foundry was awarded the BIG 2026 AI Excellence Awards. It validates the hard work we have been doing to support our customers around the world and the core of how we built our product.

1. The real bottleneck in industrial AI

We have spent enough years in industrial operations to know where AI projects actually fail. It is rarely the algorithm. It is almost always the data.

In a typical plant, the data landscape looks something like this: vibration data in one historian, process variables in another, work orders in a CMMS, engineering documents (P&IDs, datasheets, FMEAs) in a file share that may or may not be current, and ERP data in SAP or similar. Each system was implemented independently, often by different teams, sometimes decades apart.

The consequence is that engineers spend the majority of their time locating and assembling data rather than analyzing it. Every new AI use case — predictive maintenance, OEE dashboards, connected worker tools — requires its own data integration project. Predictive maintenance connects to the historian one way. The OEE dashboard connects differently. The connected worker app uses a third integration path. There is no shared context, no common data model, and no reuse between initiatives.

This is the DataOps problem. Until you solve it, every AI project is building on an unstable foundation. Models trained on fragmented, inconsistent industrial data do not just underperform. They produce outputs that operations teams learn not to trust — and once that trust is lost, the initiative stalls regardless of how sophisticated the underlying model is.

2. Where generic AI platforms fall short

It is important to be specific about what generic AI platforms were and were not designed to do.

Platforms like Databricks, Snowflake, or hyperscaler AI services are excellent at what they do: data lake management, model training infrastructure, and API-based model access. They were built primarily for IT data — structured, clean, well-documented enterprise data. They handle batch and streaming workloads effectively in that context.

Industrial data is fundamentally different. Tag names are inconsistent across systems and equipment replacements. Historian gaps span years. Sensor readings require physics-based context to interpret — a temperature reading on a compressor discharge means something entirely different than the same numerical value on a cooling water return. The relationship between assets, failure modes, and process conditions is hierarchical and domain-specific, not flat and generic.

When enterprises attempt to build industrial AI on a generic platform, they end up spending 6–12 months constructing a domain-specific data model from scratch — entity resolution across asset names, tag normalization, hierarchy mapping, failure mode classification. That work is highly specialized, poorly documented, and almost impossible to transfer between sites. It is also where most projects stall or are abandoned.

3. IRIS Foundry’s DataOps architecture

IRIS Foundry was designed to solve the DataOps problem as its primary function, not as a secondary capability bolted onto an analytics layer. The architecture has three core components.

3a. Data Connectivity and Ingestion

Over 300 prebuilt connectors handle ingestion from OT systems (historians, PLCs, SCADA, Modbus), IT systems (SAP, IBM Maximo, MES, ERP, LIMS, CMMS), engineering sources (P&IDs, CAD files, datasheets, equipment manuals), and edge/IoT devices (vibration, thermal, acoustic, and visual AI sensors).

This is a non-trivial engineering problem. Industrial protocols are heterogeneous, often proprietary, and frequently require edge-level translation before data can be consumed. The connectors are designed to work with existing infrastructure without requiring modification — no rip-and-replace of historians or control systems.

3b. Data Contextualization and the Cortex (Knowledge Graph)

Raw connectivity is necessary but insufficient. The critical step is contextualization: transforming raw data streams into a structured, queryable representation of the plant.

IRIS Foundry builds a living Cortex, or Knowledge Graph, that maps equipment hierarchies, failure modes, maintenance history, process relationships, and real-time sensor readings — all linked. The graph is assembled through automated tag normalization, asset hierarchy extraction from P&IDs and CMMS work orders, and engineering document parsing. Manual tagging is minimized.

The Cortex is what separates IRIS Foundry from a data lake with dashboards on top. When the system detects a vibration anomaly on Compressor C-204, it does not simply fire a threshold alert. It traverses the graph to understand that asset’s maintenance history, connected upstream and downstream systems, current load schedule, and which specific failure mode the observed pattern predicts based on the FMEA library. That traversal is what turns a generic alert into actionable intelligence.

The graph also serves as the shared context layer for every downstream application. Predictive Asset Intelligence, OEE dashboards, connected worker tools, and the Industrial Copilot all query the same graph. When you deploy a second use case, it inherits the full context of the first — no separate data integration, no duplicate hierarchies, no reconciliation effort.

3c. Unified Data Model and the Edge-Cloud Relationship

A common source of confusion in industrial DataOps is the relationship between Unified Namespace (UNS) and Unified Data Model (UDM). I have written about this distinction in detail previously, but the key point is relevant here: these are complementary architectural layers, not competing approaches.

The UNS sits at the edge — a real-time, event-driven data structure built on MQTT and Sparkplug B that provides a consistent view of live operational data. It prioritizes latency, reactivity, and device interoperability. Its consumers are edge analytics, local HMIs, and any system requiring immediate operational awareness.

The UDM operates in the cloud or hybrid layer. It ingests streaming data from the UNS (and from historians and batch sources), structures it into governed, versioned schemas, and makes it available for analytics, machine learning, and enterprise-wide reporting.

IRIS Foundry implements both layers and manages the pipeline between them. Edge data flows into the Cortex and UDM continuously. The Industrial LLM and predictive models consume the governed UDM. The result is a DataOps pipeline that spans from sensor to boardroom — real-time operational data at the edge feeding governed analytical data in the cloud, with the Cortex providing the structural context that makes both useful.

This architecture is specifically why site-to-site replication accelerates. When Plant 1 is instrumented and contextualized, the asset templates, tag normalization rules, FMEA mappings, and data model schemas transfer to Plant 2. The second site typically deploys three times faster than the first because the DataOps foundation is portable.

4. The Industrial LLM: domain grounding, not general-purpose wrapper

The Industrial LLM underpinning IRIS Foundry was trained on over 1.2 billion industrial tokens — sensor data, asset information, component types, work orders, reliability records, and maintenance history. It is grounded in 500+ pre-built FMEA templates covering failure modes across air separation, chemicals, oil and gas, metals processing, food and beverage, and pharma.

This distinction matters. A general-purpose LLM can generate plausible-sounding responses about industrial operations. An industrial-domain LLM, grounded in the Cortex, can explain why a specific vibration pattern on a specific compressor predicts a specific failure mode — and recommend a specific maintenance action based on how similar patterns resolved at comparable assets. The difference is not fluency. It is accuracy and domain grounding.

The LLM powers role-based Copilots for plant managers, reliability engineers, continuous improvement teams, and frontline operators. It also integrates with IRIS Flows, which orchestrates 300+ prebuilt AI agents through a visual builder for end-to-end workflows: anomaly detection to work order creation, production scheduling to quality close.

5. Production outcomes

IRIS Foundry runs in over 1,000 plants across 40+ countries, processing 6.7 trillion data points across 80,000+ monitored assets. Customer retention is 97%.

At Nippon Gases, the platform delivers over $3 million in savings per plant per year. Root cause analysis that previously required 24–48 hours now completes in under 10 minutes. Predictive Asset Intelligence provides 15–18 days of advance warning before equipment failures, with 95% forecast accuracy on 4-hour predictive windows for metals processing assets.

In food and beverage, IRIS Forge — the platform’s low-code application builder — has delivered eight purpose-built applications: CIP/SIP optimization, line performance analytics, digital twin simulation, vision-based quality inspection, and predictive maintenance. These are designed specifically for F&B process environments, not adapted from generic manufacturing templates.

The platform was built for continuous process operations first. The physics and thermodynamics engines handle real-time safety constraints and process rate variations that discrete manufacturing benchmarks do not capture. If you operate an air separation unit, a chemicals plant, a refinery, or a food processing facility, the FMEA library, asset templates, and process models were built for your operating environment.

6. Implications for your DataOps and continous improvement roadmap

If you are evaluating industrial AI, we would encourage you to focus the evaluation on the data layer rather than the analytics layer. The AI models themselves are increasingly commoditized. The differentiating factor is how quickly and reliably a platform can connect, contextualize, and govern your industrial data — and whether the second use case deploys faster than the first.

The specific questions we would ask any vendor:

• How do you handle tag normalization across heterogeneous historians?
• How do you build and maintain asset hierarchies without manual tagging?
• Can a predictive maintenance model access the same governed data as an OEE dashboard without a separate integration?
• What happens when I replicate to a second plant — do I start over, or do the templates transfer?

IRIS Foundry was designed to answer those questions architecturally. The 2026 AI Excellence Award recognizes the results of that design across 1,000+ plants. But the questions above are more useful than any award for evaluating whether a platform will work in your specific environment.

If you want to see what IRIS Foundry surfaces on your actual data, connect with an expert to discuss solutions purpose-built for industrial that will provide value in weeks, not months.