Building a Data Foundation for AI-Native Industrial Intelligence

Your ERP is only accurate for about fifteen minutes after data entry. After that, everything drifts out of sync with reality.

That observation from my conversation with Craig Scott, founder and CEO of Fuuz, captures something most manufacturing leaders already feel but rarely articulate. We've spent years accumulating enterprise systems, edge devices, and data historians, yet we still struggle to get reliable, contextual information when we need it. Now, with AI initiatives multiplying across the industry, this foundational gap is becoming an expensive liability. Craig's thesis is straightforward: before you can extract value from AI, you need a persistent, governed data layer that connects shop floor reality to enterprise systems. Without that, you're feeding garbage into increasingly sophisticated tools and wondering why the output isn't trustworthy.

‍

‍

Why Does the Traditional Manufacturing Data Architecture Fail AI Initiatives?

The standard architecture most manufacturers run today was designed for a different era. You have real-time streaming data on the plant floor, typically flowing through SCADA systems like Ignition. You have enterprise systems in the cloud—ERP, PLM, CRM—holding structured business data. And between them? Nothing persistent. As Craig describes it, there's been a missing shim between the shop floor and enterprise systems for decades.

The problem compounds when data moves through point solutions. You can collect data at the edge, reshape it, and hand it off to your ERP. But that ERP will reshape it again according to its own schema. The data no longer looks like what you intended. It's not deterministic. These tools help move data from point A to point B, but there's nothing persistent about the transformation. Every handoff introduces drift.

This is why so many manufacturers have lost faith in the concept of a single source of truth. Their ERP was supposed to be that source. But as Craig points out, it's only a reliable source for a small window of time—those first few minutes after data entry. Once the shop floor starts generating real-time signals, the ERP is already out of sync. The historian captures telemetry, but it never flows back to update the business systems. Production rates entered two years ago are still being used for estimates, even though actual performance data exists somewhere in the infrastructure.

Why Are Companies Spending Money on AI Without Seeing Results?

The pattern Craig sees repeatedly is companies launching AI initiatives without doing the hard work first. They spin up data lakes, throw Copilot at the problem, and wait for insights to emerge. But the fundamental issue remains: the AI is only as good as the information you give it. The same garbage in, garbage out principle that's been true for decades hasn't been suspended because we have more sophisticated tools.

Many companies are building their own AI agents that are deterministic in the wrong way—they only understand the data available within a single application. You end up with fragmented intelligence that can't see across the operation. Meanwhile, abstractions like Snowflake and Databricks have emerged as data platforms, which Craig acknowledges are useful but represent a level of abstraction too far removed from what's actually happening on the manufacturing floor.

The companies that come to Craig often haven't defined the problem they're trying to solve. They say they need an MES, but when you peel back the layers, they actually want OEE visibility—something achievable without a full MES deployment. The real question should be: what data problem are we actually solving, and what foundation do we need to solve it?

What Hidden Costs Does a Fragmented Data Architecture Create?

The aging workforce problem is actually a data problem. When experienced maintenance technicians who can diagnose equipment failures in minutes retire, their knowledge leaves with them. The newer team members are flipping through manuals. When skilled estimators who understand how to translate CAD designs into manufacturing processes move on, that expertise disappears. All of this institutional knowledge could be captured and made accessible, but only if you have a data infrastructure designed to hold it.

There's also the complexity burden that IT leaders carry. Craig encounters CIOs managing sixty to a hundred different applications across global enterprises. Different regional ERPs, different MES implementations, different warehouse management systems. Each site that gets added requires reimplementing integrations from scratch. The promise of best-in-class point solutions starts to lose its appeal when you're maintaining fragile architectures of six, eight, ten, or more interconnected systems—none of which share a common data foundation.

The cost isn't just technical complexity. It's the inability to act on information. You can build a beautiful data lake for reporting and analytics, but that abstraction doesn't help you run operations. If you need access to contextualized data in real time—to make decisions about warehousing, manufacturing lines, quality interventions—the data lake approach falls short. You've created a reporting layer, not an operational intelligence layer.

What Does a Model-Driven Approach to Manufacturing Data Look Like?

The alternative Craig advocates is a model-driven architecture where the data model is defined first, persistence is built in, and every system reads from and writes to a single governed layer. Instead of reshaping data repeatedly as it flows through various systems, you define the model once. Every enterprise system connects to that consistent interface. When you move from one site to the next, the model travels with you. It's a once-and-done implementation rather than a perpetual reimplementation at each facility.

This approach requires a balancing act between enterprise governance and plant-level flexibility. Craig describes this as the tension between red and blue data—the highly unstructured data from the shop floor versus the structured data in enterprise systems. The solution is what he calls the purple namespace: enterprise defines the core model, and individual plants extend it with additional metadata and context. They can add information, but they can't break the underlying structure. Everyone stays aligned while retaining the autonomy to address local needs.

What makes this approach AI-ready is the governance it provides. When you connect an AI tool to a well-structured data graph, the AI can't hallucinate your OEE. It can't imagine production rates. The data model dictates what the AI sees and calculates. You're building deterministic constraints into the system, which is the only way to move toward trusted autonomous decision-making. As Craig puts it, the AI has governance implied by the data model it's reading from.

How Fast Can This Foundation Actually Be Built?

The objection Craig hears most often is that modeling takes too long. Leaders have been burned by multi-year data warehouse initiatives that never delivered. The reality with modern tools is different. Craig recently built an entire MES system—all the data models included—in less than a week, using Claude to accelerate the development. Compare that to teams that spend more than a week building a single data pipeline.

The time investment isn't in building the model; it's in connecting to existing data sources and applying the right business rules. But even that effort pays dividends quickly. Fuuz is running wall-to-wall deployments at an automotive OEM where an entire car plant operates on just two platforms: their ERP and Fuuz. A green steel mill in Arkansas—completely solar powered with an 800-acre solar farm—runs MES, WMS, and process quality monitoring through the same platform. These aren't pilot projects in controlled environments. They're production systems handling real operational complexity.

How Should Manufacturing Leaders Evaluate Their AI Readiness?

The question most leaders are asking is: how do we implement AI in manufacturing? Craig would reframe that entirely. The right question is: do we have a data foundation that allows us to trust what AI tells us? If the answer is no, then AI initiatives will continue to disappoint—not because the technology isn't capable, but because you're asking it to work with unreliable inputs.

The practical first step is to take inventory of where your valuable data lives—spreadsheets, SQL tables, historians, ERP systems—and understand which sources matter most to the problems you're trying to solve. Data is currency. If you can turn it into actionable, trustworthy insights, you can generate measurable returns. But you need the infrastructure that makes trustworthiness possible.

Craig's advice for preparing is pragmatic: define the problem you're actually solving, assemble a cross-functional IT/OT team that can represent both perspectives, and recognize that you need a tool or platform that bridges the gap between them. You can start small. Solve a narrow problem with a model-driven approach, and you'll likely expose larger problems that the same foundation can address once they reveal themselves.

‍