- One connected view of each asset: hierarchy, failures, work orders, sensors and documents
- Investigations start from a linked history instead of manual cross-referencing
- Answers from the assistant cite the work orders, readings and drawings they rely on
- A shared asset vocabulary that engineering, reliability and data teams maintain together
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
An energy operator ran a large estate of rotating equipment, vessels, pipework and instrumentation. When something failed, the reliability team asked the obvious questions: has this happened before, on this unit or on similar ones, what did the sensors show beforehand, and what did we change last time? Answering meant searching the maintenance system, exporting historian trends, finding the right revision of a drawing and reading free-text work order notes. Each investigation rebuilt the same picture from scratch.
The data existed. The connections between it did not.
What had to be true
- One identity per asset, reconciled across the register, the maintenance system, tag lists and documents.
- A shared vocabulary for equipment classes, failure modes and maintenance actions, so "similar assets" and "same failure" mean something consistent.
- Systems of record untouched: link to them, don't replace them.
- Answers with evidence, because engineers will not act on an unexplained answer.
- Owned by the business: reliability engineers, not just the data team, maintain the model.
Architecture
The ontology borrowed its structure from ISO 14224, which organises reliability and maintenance data into equipment, failure and maintenance categories with a defined equipment taxonomy1. Sensor concepts followed the W3C and OGC Semantic Sensor Network ontology, with SOSA as its lightweight core2, rather than inventing our own model of observations.
Curated tables sat in Apache Iceberg, whose snapshot-based metadata gives versioned, reproducible inputs to every graph build5. See lakehouse catalog strategy and ontology vs knowledge graph vs semantic layer.
The data flow, end to end
- LandRegister, work orders and document metadata land as versioned tables
- ResolveMatch tags, IDs and names to one asset identity, with confidence scores
- ClassifyMap equipment classes and failure modes to the shared vocabulary
- ValidateSHACL shapes reject records that break the model before load
- LinkAttach sensor series and document revisions by reference
- AskEngineers query directly or through the assistant, with citations
SHACL let us express the rules ("every pump has exactly one parent system", "every work order references a resolved asset") as shapes that are validated on every build3. More in SHACL validation for knowledge graphs.
The hard part: deciding that two things are the same asset
Entity resolution took more effort than the graph itself. The same pump appeared under a tag number in the register, a slightly different tag in the maintenance system, a description in free-text notes and a drawing number in the document store. Some tags had been reused after equipment was replaced.
- Deterministic rules first (exact tag matches within a site), probabilistic matching second.
- Every match carries a confidence and a method, so low-confidence links are visible, not hidden.
- A review queue where reliability engineers confirm or reject uncertain matches; their decisions train the rules.
- Equipment replacement modelled explicitly, so history follows the functional location and the physical unit separately.
The patterns are described in entity resolution for knowledge graphs.
A knowledge graph is only as good as its identities. Spend the first weeks on what counts as "the same thing", not on the database.
How the engagement ran
- Bring real investigations
- Confirm uncertain matches
- Own failure mode vocabulary
- Land and version sources
- Run resolution and validation
- Publish graph builds
- Translate question to queries
- Answer with citations
- Log questions it couldn't answer
- Investigation walkthroughs
- Source inventory
- Competency questions
- Asset ontology
- SHACL shapes
- One unit end to end
- Entity resolution
- Sensor and document links
- Review queue
- Engineer assistant
- Further units
- Ownership model
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Align to ISO 14224 and SOSA/SSN | Bespoke model | Recognised structure; easier to extend and explain |
| Pointers to time series | Copy readings into the graph | Graphs are poor at high-volume time series |
| SHACL validation on every build | Trust the sources | Breakages caught before engineers see them |
| Graph-first retrieval for the assistant | Vector search over documents only | Questions are about relationships, not just text |
| Human review of uncertain matches | Fully automatic resolution | Wrong links destroy trust faster than missing ones |
The assistant combined graph traversal with document retrieval. GraphRAG research shows graph-based indexes help with broad, corpus-level questions that plain vector retrieval handles poorly4; here the graph already existed, so retrieval followed its edges. See when GraphRAG beats vector RAG.
What I'd do again, and differently
Again: write competency questions with engineers before modelling anything, and make every link explainable. Differently: put the review queue in front of engineers sooner. Their corrections improved resolution more than any tuning we did.
If you're connecting operational data like this, the ontology and knowledge graph page describes how I run these engagements, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3Shapes Constraint Language (SHACL)W3C Recommendation · 20 Jul 2017
- 4From Local to Global: A Graph RAG Approach to Query-Focused SummarizationEdge et al., Microsoft Research (arXiv) · 2024
- 5Iceberg Table SpecApache Iceberg