Your first factory ontology can map your data without moving it

Someone on your team still carries a batch number from the ERP to the historian to a recipe spreadsheet whenever a customer raises a quality question, asking colleagues where each record is kept. A first factory ontology shortens that trip without a data migration: it records what your products, recipes, equipment and measurements are, how they connect and which system holds each one, while the data stays put.

What is a factory ontology?

A factory ontology is a shared model of the things in your plant, such as products, recipes, process steps, equipment, measured variables and data sources, and of the relationships between them. A first build can hold references instead of copies. The model knows, for example, that a sensor tag measures viscosity in mixing tank 3 and that its readings are kept in the historian.

What your team gains from mapping by reference

• Less chasing. The path from a batch to its recipe version, tank, sensor tag and raw-material lot is written down once. Questions start from the map, not a round of messages.
• More value from the software you already pay for. The ERP, MES and historian keep doing their jobs. The ontology points into them and records how their records relate.
• A bounded first project. One production line, a defined set of entities and no platform migration.
• A picture that later automation can use. An SAP News feature published on 23 September 2026 notes that employees make up for fragmented systems by knowing which spreadsheet to check, and that AI agents do not inherently have that organisational context. A factory map writes that knowledge down, for people now and for automation and agents later.

Functional AI Solutions' foundational ontology work starts at this point. We define the entities with your team, connect each one to the record that already holds it, and test the map against your own questions.

Before and after: tracing one batch

Consider a Taiwan manufacturer of industrial coatings that receives a complaint about one batch. Today the quality team looks up the order in the ERP, asks production which recipe version ran, asks engineering which tank and sensor tags applied, then searches the historian for the time window. Each step depends on someone's memory.

With an ontology for that one line, the quality team starts at the batch and follows its references:

Entity	Where it lives	What the map stores
Production order	ERP	Order number, link to batch
Batch	MES	Batch ID, line, time window
Recipe version	Engineering spreadsheet	Version ID, file and row reference
Mixing tank	MES equipment list	Tank ID, fitted sensors
Viscosity reading	Historian	Sensor tag only; readings stay in the historian
Raw-material lot	ERP goods receipt	Lot number, supplier

The ERP production order and the MES batch remain separate records; the map records how one refers to the other.

Does mapping by reference work in a real plant?

On 7 April 2026, the IPS team in TU Dortmund's Faculty of Mechanical Engineering described the knowledge graph behind its cyber-physical pilot brewery. Its ontology models products, recipes, processes, procedures, equipment and measured variables. Working with Daibe, the team built a data connector that captures operational metadata from existing IT and OT systems and maps it to the ontology's classes and relations.

The brewery graph ingests no measurement values or time series. It links plant structures, process contexts, references to measured variables and the data sources themselves, turning scattered meta-information into context that supports transparency and traceability. For a buyer, this university pilot is a working reference design.

Open tooling supports the same pattern. Ontop, an Apache 2.0-licensed virtual knowledge graph system, answers graph queries by translating them into SQL against the source databases, so the data stays in those sources. Its materialisation tutorial recommends keeping large, constantly updating sensor data virtual while storing richer context in the graph.

How do you scope the first build and judge it?

Build the model from your questions:

1. Choose one production line.
2. Write down about ten traceability questions that are slow to answer today, such as which recipe version, tank and sensor relate to a given batch.
3. Model only the entities and relationships those questions need.
4. Connect each entity to its source system by reference.
5. Count how many of the ten questions the map helps answer without anyone re-keying data.

Identifiers set the pace. If the historian calls a tank TK03 and the MES calls it Mixer 3, the first modelling task is to record that both names mean the same tank.

Keep the map yours, then reuse it

A factory ontology holds your decisions about what things are and how they relate, so your own team should be able to read and extend it. That is how FAIS approaches ontology work. The same map can then support custom automation and agentic software on the line you started with, and give the next line a starting point.

Your step for this quarter: pick one line, write down ten traceability questions and count how many a reference-only map helps answer. If the count points to a worthwhile first build, that is the conversation to have with us.