Every MES vendor briefing this year has the same slide. A chat window sits on top of the dashboard. Someone types “why was Line 3 down yesterday afternoon,” and the copilot answers in a friendly paragraph instead of forcing you to click through a downtime Pareto. It’s a genuinely nice interaction model. It’s also, in a lot of implementations right now, answering a question the underlying data was never built to support.
That’s the part getting lost in the rush to ship AI features. The bottleneck isn’t the language model. Large language models are commodity infrastructure at this point — every serious MES vendor has access to roughly the same class of models, wrapped in roughly the same retrieval-augmented-generation architecture. The differentiator, and the risk, sits one layer down: whether your MES actually exposes clean, structured, contextualized data for the copilot to reason over. If it doesn’t, you haven’t bought an AI copilot. You’ve bought a very confident guessing machine wearing your plant’s color scheme.
Plausible is not the same as verifiable
This distinction matters more in manufacturing than almost anywhere else AI copilots have shown up. A copilot that hallucinates a marketing headline is annoying. A copilot that hallucinates a root cause for a scrap event, or nudges an operator toward a quality disposition based on a misread reason code, is a different category of problem — because someone downstream may act on it, and MES data has a way of becoming the system of record for regulatory and customer audits.
The failure mode isn’t usually the model inventing facts from nothing. It’s the model doing exactly what it’s designed to do — pattern-match and summarize — over data that’s ambiguous, unlinked, or missing the context a human would normally supply from memory. A copilot summarizing “why was Line 3 down” needs more than a timestamp and a downtime code. It needs to know whether that reason code means what the operator who logged it thought it meant, whether the code taxonomy changed six months ago, whether the equipment ID maps cleanly to a single asset in your ISA-95 equipment hierarchy or to three renamed lines that share a history table. If any of that context is missing, the model won’t say “I don’t know.” It’ll produce a fluent, plausible-sounding answer anyway. That’s the nature of the technology, and it’s exactly why the data layer underneath it deserves more scrutiny than it’s getting.
What “AI-ready” MES data actually looks like
Before letting a copilot near downtime summaries or quality recommendations, it’s worth auditing your MES data model against a few concrete criteria — not vendor claims about the model, but the actual state of your contextual data.
- Units and normalization. Are quantities, cycle times, and rates stored with explicit, consistent units across lines and sites, or does the copilot have to infer that Line 3 reports in parts-per-minute while Line 7 reports in seconds-per-part? Silent unit mismatches are one of the oldest MES integration headaches, and an AI layer will paper over them with confident-sounding math rather than flagging the inconsistency.
- State model clarity. Does your equipment state model distinguish planned stop, unplanned stop, starved, blocked, and changeover with clean, non-overlapping definitions — ideally aligned to something like ISA-95 or a documented internal standard? If “idle” is used as a catch-all bucket by three different shifts for three different reasons, a copilot summarizing idle time will average together things that shouldn’t be averaged.
- Reason code governance. Are downtime and scrap reason codes controlled, versioned, and mapped to a stable taxonomy, or has the list grown organically for years with duplicates and free-text overrides? A copilot is only as good as the categorical data it’s summarizing, and reason codes are frequently the messiest table in the whole MES.
- Genealogy and traceability links. Can the system trace a finished unit back through the specific machine, operator, lot, and parameter set that touched it, with actual foreign-key integrity — or is genealogy reconstructed after the fact through timestamp proximity? Quality disposition recommendations are only trustworthy if the genealogy chain behind them is real, not inferred.
- Context linking across ISA-95 levels. Does the data model connect a Level 2 control event to a Level 3 work order to a Level 4 quality spec, or do these live in separate silos that a copilot bridges with fuzzy matching? Fuzzy matching is fine for a dashboard filter. It’s not fine for an answer someone might put in a deviation report.
- Audit trail and provenance. When the copilot cites a number, can you click through to the exact source record, timestamp, and the person or system that entered it? If the copilot can’t show its work, it shouldn’t be trusted with anything beyond casual exploration.
None of this is exotic. It’s the same data-quality discipline plants have owed themselves since MES first got connected to ERP and historian systems. AI just raises the stakes, because a bad join used to produce a wrong number on a report someone might catch. Now it produces a wrong number wrapped in a sentence that sounds like it came from a colleague who checked.
Test it like you’d test a new hire
The practical move before rollout — and before renewal, if your vendor is bundling a copilot into the next contract — is to run the tool against known-answer scenarios, the way you’d probe a new engineer’s judgment before trusting their call on the floor.
Pull three or four downtime events, quality holds, or genealogy questions where you already know the ground truth cold, including the messy edge cases: a reason code that was recently redefined, a changeover that spans a shift boundary, a lot that was partially reworked and split across two work orders. Ask the copilot the same questions a supervisor would ask. Then check not just whether the answer is right, but whether it’s traceable — can you follow its reasoning back to source records, and does it hedge appropriately when the data is genuinely ambiguous, or does it confidently pick a lane anyway?
A copilot that says “I can’t determine the root cause with confidence — the reason code changed definitions in this period” is more trustworthy than one that always has a tidy answer. If your evaluation never produces an “I don’t know,” that’s not a feature. That’s a tell.
Where this leaves plant IT teams right now
If you’re mid-evaluation or facing a renewal where the copilot is the headline feature, the honest framing to bring into that conversation is that you’re not really buying an AI capability — you’re buying a reflection of your own data hygiene, wrapped in a chat interface. Vendors will demo the copilot on clean reference data, and it will look great. The real test is your production reason codes, your renamed assets, your years of organic drift in the state model.
That’s not an argument against these tools. Contextualized well, an MES copilot genuinely can compress the time it takes to triage a downtime event or scope a quality investigation, and that’s real value worth pursuing. But the order of operations matters. Fix the context layer first — the units, the state model, the reason code governance, the genealogy links — and the copilot becomes a faster way to query a system you already trust. Skip that step, and you’ve just made it easier to be confidently wrong, faster.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
