What Is a Manufacturing Knowledge Graph?

Most manufacturers with a serious digital program have already built some version of a facility model. An asset framework in the historian. A tag hierarchy in SCADA. A digital twin project that got as far as the pilot site. The model exists, the data flows into it, and the dashboards render. Then something happens that the model was supposedly built for. A batch fails QC and the investigation team needs to know what was running upstream. A shared utility trips and operations needs to know which lines are exposed. An AI pilot kicks off and the data science team asks for "context" and gets a folder structure.

In each case the same frustration surfaces: the model is there, the data is there, but the system cannot answer the question being asked. The usual diagnosis is that the model is incomplete, so more tags get added and more naming conventions get enforced. The actual root cause is usually different. The organization built one type of model and is asking questions that require another type. A data hierarchy organizes what exists. It was never designed to capture how things relate or why. That sounds academic until an incident review is stuck at 11pm because nobody can say with confidence what CIP Circuit B actually touches.

What a data hierarchy is, and what it does well

A data hierarchy organizes assets into a tree. Enterprise at the top, then site, area, line, unit, and finally the tags themselves. Every data point gets an address: Site2/Fermentation/Line3/Tank-101/Temperature. Tools like AVEVA Asset Framework and OSI PI Asset Framework are built on this principle, as are the asset modeling features in most historians and SCADA platforms.

The hierarchy earns its keep in several ways. It gives navigation: an engineer unfamiliar with a site can browse to the right tag instead of searching a flat list of forty thousand cryptic names. It gives aggregation: energy consumption rolls up from unit to line to site because containment defines what belongs to what. It gives consistency: templates define what a "fermentation tank" looks like once and stamp it across every instance. This was a genuine advance over raw tag soup, and it still delivers real value every day. Reporting, KPI rollups, and template-driven configuration all rest on hierarchical structure, and nothing in this article argues otherwise. The hierarchy is doing exactly what it was designed to do. The problem is what it was not designed to do.

Where hierarchies break down

A tree permits exactly one structural relationship per node: parent and child. Tank-101 belongs to Line 3, which belongs to Fermentation, which belongs to Site 2. That single relationship type is the entire expressive vocabulary of the model.

Real facilities are not trees.

A plate heat exchanger serves three process lines that sit in different branches of the hierarchy. The compressed air system feeds equipment across every area of the plant. A CIP circuit touches tanks, valves, and transfer lines that belong, hierarchically speaking, to entirely different departments. A batch recipe moves material through a sequence of physical units, and that sequence changes depending on which product is running this week. None of these fit a parent-child structure. Where does the heat exchanger live in the tree? Under whichever line the original architect happened to assign it to, which means its relationship to the other two lines exists nowhere except in the heads of the people who operate it. The standard workarounds (duplicate nodes, reference attributes, naming conventions that encode relationships in strings) are all ways of smuggling network structure into a tool that cannot represent it, and every one of them becomes a maintenance liability that grows with the plant..

There is a second, quieter failure mode. Hierarchies assume a designer. Someone has to define the structure before anyone can populate it, because in a tree, structure is a global decision. That works tolerably at a single site with one engineering team. At fourteen sites, each with different equipment vintages, different naming conventions, and different engineers who built their slice independently over twenty years, the assumption collapses. Either a central team imposes a structure that flattens real local differences, or each site keeps its own structure and the "enterprise model" is fourteen models wearing a trench coat. Both outcomes produce the same result: a model that requires constant negotiation to change, so it slowly stops changing, and then slowly stops matching reality.

The benefits of a knowledge graph

A knowledge graph is not a replacement for hierarchy so much as a different kind of model, one in which relationships are first-class objects rather than a side effect of position in a tree. A node in a graph can have any number of named relationships to any other node. Tank-101 is part of Line 3, and it also feeds Reactor-3, is cleaned by CIP Circuit B, shares a utility header with Tank-104, and is interchangeable with Tank-102 for products that do not require jacketed heating. The containment hierarchy is still in there. It is simply one relationship type among many, instead of the only one the model can hold.

The practical consequence is that the model can answer questions that require following relationships rather than navigating to an address. Which downstream processes are affected if this pump goes offline? The graph traverses the feeds relationships and returns them. Which batches consumed raw material from this supplier lot? Follow consumed backwards from the lot. What equipment was in what state when this alarm fired? Follow the time-stamped relationships between the alarm, its associated units, and the batch that was running. These are the questions a plant engineer actually asks during an investigation, and they are precisely the questions a tree cannot answer, because answering them requires lateral connections the tree has no way to store.

It is worth being direct about the cost. Those relationships do not exist in any source system today. The historian does not know that Tank-101 feeds Reactor-3. Someone who understands the process has to put that knowledge into the model, and that work is real engineering effort, not a migration script.

A concrete example: three product lines and one CIP circuit

Consider a multi-product batch facility running three product lines through shared utilities and a shared CIP system. The data hierarchy gives you a well-organized address book. Every tank, valve, and transmitter has a path, every line rolls up cleanly, and the site-level OEE report populates without manual work. That is not nothing.

Now the questions change. CIP Circuit B develops a conductivity problem on the final rinse. Which product lines are affected? The hierarchy cannot say, because circuit-to-equipment relationships were never part of the tree; the CIP skid lives under Utilities, and the tanks it cleans live under three different production areas. Someone pulls the P&IDs, someone else calls the engineer who commissioned the skid in 2016, and the answer arrives in hours instead of seconds.

Perhaps a different example; the quality team notices that three of the last thirteen batches of Product-7 failed a stability test. What were the process conditions in the upstream preheat stage during the ten batches that passed versus the three that failed? Answering this from a hierarchy means manually reconstructing which physical units each batch actually ran through (remember, the routing changes by product), then pulling time-series for each unit over each batch window, then aligning it all in a spreadsheet. In a graph where batches are linked to the units they executed on and units are linked to their measurements, that is a single traversal.

The point is not that hierarchies are bad. The point is that this second class of question, the kind that determines whether an investigation takes an afternoon or a month, requires a model of relationships, and a tree does not have one.

Why federation matters

The single-architect assumption fails at enterprise scale for a deeper reason than complexity. The knowledge itself is distributed. The process engineer at Site 4 understands the recipe logic on her lines in a way no central data team ever will. The maintenance planner knows which equipment dependencies actually matter. The QA lead knows how lab results relate to production units. A central team cannot capture that knowledge on their behalf, and every attempt to do so produces a model that the people who know the facility best do not recognize and will not maintain.

A knowledge graph built for federation inverts the workflow. Each domain expert authors their own slice: the process engineer models the recipe structure, maintenance models the equipment dependencies, QA models the lab relationships, and each site works in its own terms. Because the graph does not require a single global tree, those slices compose into a coherent whole through the relationships between them, without anyone designing the entire structure upfront. Hierarchical tools cannot work this way, because structure must be settled before population can begin. That sequencing creates a bottleneck that scales badly across sites and worse across disciplines, and it is the single most common reason enterprise modeling initiatives stall in year two.

How to evaluate what you already have

Three questions provide an honest test of any existing facility model.

First, can it tell you which processes are affected by a failure in a specific shared utility, without custom code or a call to the person who built it?

Second, can it tell you which equipment was in what state during a specific batch three months ago, including how the routing was configured at that time?

Third, can domain experts at different sites and in different disciplines author their own sections independently, without breaking a structure someone else designed?

If the answers are no, nothing is broken. The model is a hierarchy performing exactly as designed. The decision facing the organization is whether that design is sufficient for where it is trying to go, particularly if the roadmap includes multi-site standardization or AI initiatives that will ask relationship questions from day one.

The practical implication

Organizations that invested in data hierarchies did not waste the money. The hierarchy delivered navigation, naming, and aggregation, and it will keep delivering them. The open question is whether the organization now needs a layer above it, one that captures relationships and operational knowledge in addition to structure. At multi-site scale, with AI on the roadmap, the answer for most manufacturers is yes, and it is worth saying plainly that building that layer is real work. It requires the people who understand the facility, not just a new tool, and it rewards organizations willing to treat their operational knowledge as an asset worth formalizing.