Explained
What is a knowledge graph for industrial operations?
Not a search index, and not a vector store. A model of the plant in which the things and their relationships are the data, and every claim can be traced back to a sheet.
The definition
The two halves matter equally. The nodes make the graph an inventory: every pump, valve, transmitter, and procedure exists as a distinct thing, not a mention in a file. The edges make it a model: the graph knows that this relief valve protects that vessel, that this line connects that exchanger to that column, that this procedure references that pump. Take the edges away and you have a parts list. The edges are what let the graph answer engineering questions.
How it differs from search, and from vector retrieval
Document search finds files that mention a term. Vector retrieval, the machinery behind most “chat with your documents” products, finds passages of text that resemble the question. Both work on resemblance. A graph works on relationships, and that is a different kind of answer.
| The question | What retrieval returns | What a graph returns |
|---|---|---|
| What is upstream of this exchanger? | Passages that mention the exchanger. | The upstream equipment and lines, traced hop by hop, each hop cited to its sheet. |
| What does this relief valve protect? | Text that discusses the valve, if any document happens to say it plainly. | The protected equipment, read from the topology, whether or not any prose ever wrote it down. |
| Which procedures reference this pump? | Documents lexically similar to the pump's tag. | The exact set of procedures with an edge to that pump. A list, not a likelihood. |
The pattern in the right-hand column: structural questions have exact answers. Resemblance can only approximate them, and the most important facts about a plant, what connects to what, are usually written nowhere as prose. They exist only as topology. A system that reads text can never retrieve what was never written; it has to be compiled from the drawings.
A graph built once is an archive
Plants change. Management-of-change files land, drawings get revised, instruments are added, lines are rerouted. A knowledge graph that was built during an implementation project and left alone begins to disagree with the plant on day one, and the disagreement compounds quietly. An engineer who catches the graph being stale once will not trust it twice.
So freshness is not a feature of a knowledge graph; it is a requirement of the category. The graph must rebuild as the plant's data changes, on the same order of time as the change itself. Our own bar: a plant compiles in under 48 hours, and a new source system goes from connection to queryable in 18 hours. Whatever the number, ask any vendor the same question: when a drawing is revised, when does the graph know?
Citations make it checkable
Every node in the graph carries its provenance: the P&ID sheet the valve was read from, the document a procedure came from, the revision it reflects. When the graph answers a question, the answer arrives with its sources, and an engineer can open the sheet and check.
This is not decoration. Engineers do not extend trust to systems; they extend it to claims they have verified, one at a time. A graph with citations earns trust at exactly that pace. A graph without them asks to be believed, which in a plant is the same as asking to be ignored.
The claim
If you cannot ask what is upstream, you do not have a model of the plant. You have a library.
Libraries are useful. But the questions that decide isolations, investigations, and turnarounds are structural, and structural questions need a graph: current, connected, and cited.