What is the difference between a historian and an MES data model?

A historian stores tag values over time and is built for trending high-frequency signals. An MES data model stores events tied to business entities like work orders, lots, and people. Most plants need both: the historian feeds signals into the event model, which adds the context the historian lacks. See what a historian database is for the full picture.

Why do AI agents need structured context instead of raw data?

Because language models infer whatever is missing, and inference on plant data produces confident wrong answers. If the relationship between a count and its work order is explicit in the data, the AI retrieves it. If it is implicit in timestamps and tribal knowledge, the AI guesses. Structure is what turns AI from a demo into a tool.

What is lot genealogy in manufacturing?

The recorded chain linking finished goods back to the material lots, equipment, people, and process events that produced them, and forward from any input lot to everything it went into. It is the core of traceability and recall readiness, and it only exists if production is recorded as linked events rather than isolated logs.

Do I need to replace my historian to get an AI-native data model?

No. The historian keeps doing what it does well: dense time-series storage and trending. The event model sits alongside it and references it. What changes is that the historian stops being treated as the system of record for operations, because it never had the context to play that role.

Where does paper-based data fit in an event model?

Digitized paperwork becomes events like everything else. A signed quality check, a changeover sheet, or a shift note lands on the same timeline as machine counts and fault codes, with the who and when attached. If paperwork stays outside the model, roughly half of the plant's events are invisible to it.

The AI-Native MES Data Model

Q: What is an AI-native MES?

An MES designed so that AI can read and act on its data directly. In practice that means an event-and-context data model: every production fact is stored with links to the order, machine, material lot, and person involved, so AI systems answer questions by lookup instead of guessing at joins across disconnected tables.

Tag historians store values with timestamps. AI needs events with context: the order, the lot, the person, the when. Here is the difference, one pallet at a time.

An AI-native MES data model stores production as events with context: what happened, to which order, lot, machine, and material, done by whom, and when. That structure, not a pile of tag values, is what lets AI answer real questions like "which pallets came from the flagged batch?"

Most plant data systems were built to store numbers over time. A temperature every second. A motor speed every 500 milliseconds. That design is fine for trending, and it is exactly what a historian database does well. But it cannot answer the questions a plant manager actually asks, because those questions are about orders, lots, people, and causes, not about tags. This post explains what an AI-native data model looks like, why events plus context beats tags plus timestamps, and how the genealogy of a single pallet shows the difference.

What is an AI-native MES data model?

It is a way of recording production so that every fact carries its own context. Instead of storing "line 3 counter = 4,812 at 14:02," an AI-native model stores "operator M. Reyes completed 4,812 units of work order 7741, lot 22-B, on line 3, between 06:00 and 14:02, consuming material lots R-118 and R-121, with two quality holds." Same underlying activity, completely different usefulness.

A traditional MES holds some of this in relational tables, and a historian holds the time-series side. What makes a model AI-native is that the two are joined by design. Every event is linked to the entities it touched: the order, the machine, the material lots, the person, the shift, the work instruction revision. When an AI system reads that record, it does not have to guess what "tag FT-301.PV" means or which order was running at 14:02. The context is already attached.

That matters because large language models and AI agents are only as good as the structure they can read. Ask an AI a question against raw tag data and it will hallucinate the joins. Ask it against an event-and-context model and the answer is a lookup, not a guess. This is the difference between agentic AI in manufacturing that works and AI demos that fall apart on contact with a real plant.

Why is a tag historian not enough?

Because a historian records values, not meaning. A historian is a superb instrument for what it was designed to do: compress and store millions of tag samples so you can trend a pressure over six months. But three things are missing from the tag model, and all three are what AI needs most.

First, identity. A tag says a counter incremented. It does not say which work order those units belong to, which customer they ship to, or which lot of raw material went into them. Second, actors. Tags do not know who was running the line, who approved the quality check, or who signed the changeover. Third, boundaries. Production is made of episodes: a batch starts and ends, a shift starts and ends, a hold is opened and released. Tag streams have no native concept of an episode, so every downstream system has to reconstruct them, badly, from timestamps.

A historian row stores a value and a time. An event stores the same fact linked to the order, lot, line, operator, and quality record it belongs to.

None of this means historians are obsolete. Keep the historian for high-frequency signals and long-term trends. The point is that a historian alone cannot be the system of record for operations, and pointing an AI at one does not change that. The historian is one input into the event model, alongside machine connectivity, quality checks, and the paperwork your operators fill out every shift.

What does "events plus context" actually mean?

It means two layers working together. The event layer is an append-only log of things that happened: batch started, pallet completed, hold opened, changeover finished, check signed. Each event has a timestamp, a type, and a payload. The context layer is the set of entities those events reference: work orders, material lots, machines, people, products, locations, and documents. Events point at entities; entities accumulate history from the events that touch them.

Three properties make this combination powerful for AI. First, it is queryable in plain language, because every relationship is explicit. "Show me every pallet that consumed lot R-118" is a graph traversal, not a forensic project. Second, it is auditable, because events are never overwritten; a correction is a new event, so the who-what-when survives. Third, it is complete, because the model has room for human events, machine events, and system events side by side. The reason code an operator types is a first-class event, equal in standing to the fault code from the PLC.

Notice what this model demands from the plant floor: the machines have to feed it. Counts, states, and fault codes need to flow in automatically, which is why machine data collection and an event model are two halves of the same project. Collect data without context and you get a swamp. Design context without live data and you get an empty diagram.

What does the genealogy of a pallet look like?

Follow one pallet backwards and the model proves itself. A finished pallet is an entity. The events that touched it tell its whole story: it was completed at 14:02 on line 3 under work order 7741. That order consumed raw material lots R-118 and R-121, received on two different days from two different suppliers. Operator Reyes ran the line; supervisor Cho released the second quality hold at 11:40 with a note about label alignment. The changeover before the run was done against work instruction revision C.

One pallet traced back through its order, line, operator, quality holds, work instruction revision, and raw material lots. Every link is an event, so the trace is who, what, and when.

Now run the trace forward instead. Supplier A calls about a problem with lot R-118. In a tag-historian world, answering "which pallets are affected and where are they?" takes days of cross-referencing paper logs, spreadsheets, and shift memories. In an event-and-context model it is one query, and the answer includes which customers received which pallets. That forward-and-backward trace is the backbone of traceability, and it is exactly the structure a recall, an audit, or an AI copilot needs.

How do you build an AI-native data model?

You do not need to boil the ocean, and you should not start with a schema debate. The sequence that works on real floors looks like this:

Pick the entities that matter first. Work orders, machines, products, material lots, people. Five entity types cover most plants on day one. Resist modeling everything.
Define a small set of event types. Run started, run ended, count, downtime, quality check, hold opened, hold released, changeover. Each with timestamp, actor, and entity references.
Connect the machines. Get counts, states, and faults flowing automatically from PLCs, sensors, and retrofits so events are grounded in reality, not recollection.
Digitize the paperwork into the same model. A signed quality check should land as an event next to the machine data, not in a separate document silo.
Backfill context as you go. Attach work instruction revisions, supplier lots, and shift rosters when the basics are stable.
Put AI on top last. Search, summaries, and agents only pay off once the events and context they read are trustworthy.

Step 4 is the one most projects skip, and it is the one that decides whether the model is complete. If your quality checks, changeover sheets, and shift notes live on paper, half of your plant's events never enter the model. That is why breaking data silos means digitizing paperwork and connecting machines in the same motion, into the same layer, not running two separate projects that meet someday.

What changes when AI can read your operations?

The questions get answered at the speed they are asked. "Why was line 3 down more this month?" stops being a report someone builds next week and becomes an answer with the downtime events, reason codes, and the two worst changeovers attached. "Which operators have signed off on the new revision?" is a lookup. "What did we run the last time this order came through?" pulls the actual events from the last run, including who ran it and what went wrong.

This is also where an event model quietly beats a dashboard. Dashboards show aggregates someone decided to chart in advance. An event model lets you interrogate anything that happened, in plain English, after the fact. The pattern-finding, the root-cause suggestions, the shift summaries: all of it is downstream of one design decision, which is recording events with context instead of values with timestamps.

Where does Harmony AI fit?

Harmony AI is built on this model. Machines, software systems, and digitized paperwork all write into one operational layer, so a quality signature and a PLC fault code end up as neighboring events on the same timeline. That is what makes plain-English search across all plant data possible, and it is why Harmony AI connects your existing mixed-vintage equipment instead of asking you to replace anything. The CLS deployment is a concrete example: production knowledge that lived on paper and in experienced heads became live, queryable operational data, without ripping out what already worked. Harmony AI engineers deploy in person, on your floor, and wire the model to your actual lines rather than handing you an empty schema.

What do the standards say?

The industry has been converging on structured, context-rich models for years, and the standards back this direction:

The ANSI/ISA-95 series (adopted internationally as IEC 62264) defines the enterprise-to-control-system models that most MES data structures descend from, including materials, equipment, personnel, and process segments.
OPC UA (IEC 62541), from the OPC Foundation, moved machine integration from raw tags toward typed information models that carry structure and meaning with the data.
Eclipse Sparkplug, published as ISO/IEC 20237 in 2023, standardizes how MQTT payloads carry structured metadata such as birth and death certificates for devices, so consuming systems know what the data means.

None of these standards gives you genealogy on their own. They give you clean, structured inputs. The event-and-context model is the layer above, and it is the part an AI-native system has to get right.