What is an Industrial AI Platform? The Two Layers Buyers Confuse

One of them sells you a prediction. The other sells you the data underneath it. They don't belong on the same scorecard.

Somewhere in every Industrial AI evaluation there is a spreadsheet. Vendors across the top, criteria down the side, weighted scores along the bottom.

The spreadsheet is usually fine. The vendors on it are the problem — not because any of them are bad, but because at least two of them are selling things that can't be scored on the same axis.

One of them sells a model that looks at a packet on a filling line, decides in under 100 milliseconds whether the seal is good, and tells you it found a 5mm wrinkle on the top-left seal, probably from heater temperature drift. That's a product. It demos beautifully. It scores well.

Another sells nothing that produces an answer at all. It connects to your PLCs, works out what each tag actually means, attaches it to an asset and a shift, and hands the result to whatever wants to consume it. There's no prediction in the demo. Against criteria built around model breadth and use case libraries, it looks thin.

Both are Industrial AI platforms. Analysts describe them that way, they describe themselves that way, and the search that produced your shortlist treated them as interchangeable. And the second one is very often the thing you're actually short of.

Here's how it usually goes. The pilot works. The model performs, the numbers hold up, someone presents it internally and gets budget to roll it out. Plant two starts. And plant two's data doesn't look like plant one's. Different tag naming. Different asset structures. Sampling at a different frequency. Sometimes a different make of machine doing the same job. The model is fine — it just has nothing recognizable to eat.

The first deployment proves the use case. The second reveals that tags, context and structures differ at every site. What happens next is predictable and expensive. The team rebuilds the pipeline for plant two, which takes most of a quarter. Then plant three arrives and it turns out plant two's pipeline doesn't transfer either. Six months in, the AI programme has become an integration programme with an AI logo on the slide.

There's a milder version of the same problem that shows up earlier. You buy three point solutions — vision here, machine health there, energy somewhere else — and one morning someone notices all three report a different OEE for the same line. Nobody is wrong. Each tool brought its own pipeline and its own definition of what counts as downtime. That's not a reporting problem to be reconciled in a dashboard. It's the data layer, arriving in disguise.

The application layer produces an answer: a prediction, a classification, a recommendation, an action taken by an agent. Vision inspection, predictive maintenance, process optimisation. This is the layer everyone means when they say "AI."

The data layer produces something less exciting and harder to skip — operational data that a model can be trusted on. It reaches into the control systems, figures out that tag FT_1042_PV is the flow rate on filler three measured in litres per minute, ties it to the asset and the shift, and keeps a record of every transformation between the sensor and the number on the screen.

Two variations sit around them. Automation vendors extend their own control systems upward into analytics and agents, which works well inside their estate and less well outside it. Enterprise suites embed copilots where the workflow already lives, which is fast to adopt because the data is already in the building — as long as the data you need is transactional rather than coming off a PLC.

The distinction matters for one practical reason: it determines what you still have to buy after you sign. An application-layer platform assumes the data arrives usable. If it doesn't, that gap doesn't go away. It becomes a project nobody scoped, staffed by whoever is available.

Ask each vendor these, and ask for evidence rather than a yes.

Three of those are worth treating as pass-or-fail rather than scored: context, multi-site reusability, and governance. Each one decides whether the work you do at the first site survives the second, and a platform that fails any of them doesn't become acceptable by scoring well on the rest.

The multi-site question is the one people skip, because pilots are single-site by nature and there's nothing to test yet. It's also the one that most reliably predicts how the next two years go.

Litmus is the data layer. That's a deliberate scope rather than a gap in the roadmap.

Litmus Edge connects natively to PLCs, DCS, SCADA, historians and MES, turns the signals into reusable models for assets, lines and facilities, and runs analytics and inference inside the plant — GPU-accelerated vision at line speed, small language models hosted locally where nothing is allowed to leave the site. Litmus Edge Manager rolls that out from templates and manages model versions across the fleet. Litmus Data Catalog keeps the lineage. Litmus MCP Server hands live operations to agents as callable tools, so an agent reasons over the asset hierarchy instead of guessing at tag names.

What we don't sell is the application layer. The use cases run on top — built in-house, bought from a specialist, or already sitting in your ERP.

The argument for doing the foundation first is just arithmetic. Traditional Industrial AI deployments take twelve to eighteen months to reach production, and most of that is data work rather than model work. Do it once and the next use case takes days. One food and beverage manufacturer got to 95 global sites in 18 weeks on template-based rollout. Niagara Bottling standardised across more than 50 plants, normalising at the edge and streaming to Databricks. Jaguar Land Rover is running 126 edge deployments.

Work out which layer you're short of. It's usually obvious once you ask. Pilots that work and won't repeat: the data layer. Clean, governed data and no use cases: the application layer. Three tools that can't agree on OEE: the data layer again. Then check the constraints that disqualify rather than deduct. Sub-second latency. Air-gapped plants. Sites where the connection drops for an afternoon and nobody notices until the reports are wrong.

Then count the plants. One plant will run on almost anything, which is exactly why a single-plant pilot tells you so little. Most manufacturers end up with software from both layers, plus whatever AI came free with something they already own. That's fine. The only thing that decides whether it works together is whether all of it is reading from the same governed source.

Software that lets manufacturers build, deploy and operate AI on operational data from plant systems. The category spans two layers: platforms supplying models and applications, and platforms supplying and governing the operational data those models depend on.

The terms are used interchangeably. "Manufacturing AI platform" is more common among operations teams; "Industrial AI platform" is broader and covers adjacent asset-intensive sectors such as energy and oil and gas.

IIoT platforms were built for connectivity, device management and monitoring. An Industrial AI platform additionally contextualizes signals into asset models, governs lineage so output is traceable, and runs inference where the latency budget requires it — under 100 milliseconds for closed-loop decisions.

Standardized data models common to every site, template-based rollout, centralized model and version management, and governance that holds across plants.

Usually yes, for plant-floor use cases. Embedded ERP AI operates on transactional and planning data. It does not solve acquisition and contextualization of OT data from control systems.

Yes. Litmus Edge runs local ML and GPU-accelerated inference and supports locally hosted small language models, including in fully air-gapped environments.