Knowledge graph

A knowledge graph stores facts as connections: this pump feeds that exchanger, appears on this P&ID, is specified by that datasheet, belongs to this system. Where tables hold records and files hold documents, the graph holds the relationships between them as first-class data — which suits engineering information unusually well, since a facility is a network of typed connections, and most hard questions about one ("what does this isolation affect", "which documents change if this line is resized") are questions about paths through that network.

Built over an asset's documents and registers, a graph becomes the queryable form of what the documentation collectively knows — with each fact ideally traceable to its source document, since an unverifiable graph is folklore at scale.

Its quality ceiling is set at ingestion: the graph knows only what was extracted, resolved and linked correctly, so tag-identity mistakes and missed connections propagate into every downstream query. And like any structured store, it needs a maintained vocabulary of entity and relationship types — an ontology — or five years of incremental additions produce a graph that disagrees with itself about what its own edges mean.