Construction, temporal evolution and implementation practice

How nodes and relationships are created, how assertions are retired and superseded, and what separates knowledge graphs that survive contact with an operating plant from those that do not.

1. Executive summary

Knowledge graphs have moved from research curiosity to enterprise infrastructure. In asset-intensive industries they now underpin equipment master data, engineering handover, reliability analytics, digital twins and, increasingly, the retrieval layer beneath generative AI assistants. The technology is mature. The failure rate of knowledge graph programmes, however, remains high — and the causes are consistent.

The difficulty is almost never graph traversal. Modern graph engines handle multi-hop queries over hundreds of millions of edges without drama. Programmes fail on three problems that sit above the database: establishing durable identity for things that appear under different names in a dozen systems; capturing where every assertion came from and how much it should be trusted; and representing the fact that the world changes, that records of the world are frequently wrong, and that these are two different situations requiring two different responses.

This paper sets out how a knowledge graph is actually constructed and maintained. It covers the representational choice between resource-description and property-graph models, the mechanics of node and relationship creation, the identity-resolution layer that most implementations underinvest in, and — at length — the temporal model that governs how relationships are retired, superseded and corrected. It closes with an implementation architecture, a governance model, a measurement framework and the failure modes most commonly encountered in industrial deployments.

The recurring theme is stated plainly at the outset: identity is harder than structure, time is harder than identity, and governance is harder than all of it. Programmes that budget accordingly succeed. Programmes that treat the knowledge graph as a database selection exercise do not.

2. Why the hard parts are not the graph

A knowledge graph is a data structure in which entities are represented as nodes, the relationships between them as edges, and both are described by a formally defined vocabulary — an ontology — that constrains what may be said and licenses inference over what has been said. That definition is uncontroversial and largely unhelpful, because it describes the easy part.

Consider a single centrifugal pump in an operating refinery. It appears as a symbol with a tag number on a piping and instrumentation diagram. It appears as an equipment record and a functional location in the maintenance management system. It appears as a set of tags in the process historian. It appears as a line item in a vendor data book, as a class instance in the handover deliverable, as a cost centre allocation in the finance ledger, and as a subject in eleven years of work orders, inspection reports and incident narratives. Each representation uses a different identifier, a different attribute set and a different notion of what constitutes "the pump".

Building a graph that connects these is not primarily a modelling exercise. It requires deciding what makes two records the same thing, recording why that decision was made and how confident one is in it, and preserving the ability to reverse it. It requires representing the fact that the pump was replaced during the 2024 turnaround, that the tag number was reassigned in a subsequent re-lettering exercise, and that a data entry error in 2021 attributed three years of vibration history to the wrong unit. A graph that cannot express these situations is a diagram, not an operational asset.

2.1 What a knowledge graph is genuinely good at

Before committing to the effort, it is worth being precise about the return. Knowledge graphs earn their cost in four situations:

•    Connecting across silos without a canonical schema. Relational integration requires agreement on a single schema before value is delivered. A graph accepts partial, overlapping and locally inconsistent models and reconciles them incrementally, which matches how enterprise data actually arrives.

•    Questions whose shape is not known in advance. Where the analytical question involves traversing an unknown number of relationships — root cause tracing, impact analysis, contamination pathways, supply chain exposure — a graph expresses in one query what relational modelling expresses in a stored procedure.

•    Machine-interpretable semantics. An ontology lets software reason about meaning rather than matching column names, which is what makes automated validation, classification and inference possible at all.

•    Grounding generative AI. Retrieval over a governed graph gives a language model structured, provenance-bearing context, and gives the enterprise an audit trail explaining why an answer was produced. This has rapidly become one of the strongest business cases for graph investment.

If none of these apply, a well-designed relational warehouse is cheaper and easier to operate. The technology should be selected against the question, not the fashion.

3. Representational foundations

3.1 Triples, quads and property graphs

Two mainstream representations dominate, and the choice between them constrains almost every subsequent design decision.

The resource-description model represents every fact as a triple of subject, predicate and object, each identified by a globally unique identifier. Adding a fourth element — a named graph — turns the triple into a quad and provides a natural container for provenance, versioning and access control. The model is standardised end to end: a query language, a schema and constraint language, and formal semantics that support automated reasoning. Because identifiers are globally unique, two organisations can merge their graphs without collision, which is precisely the property that engineering interoperability standards depend upon.

The labelled property graph model represents entities as nodes and relationships as edges, and permits both to carry arbitrary key-value properties. This is the decisive practical difference: metadata about a relationship — when it became true, who asserted it, how confident the assertion is — attaches directly to the edge, with no additional modelling machinery. Traversal performance is generally superior, developer ergonomics are better, and the query language is more approachable for teams without a semantics background.

A recent standard extension to the resource-description model narrows the gap by allowing statements to be made about statements without the four-way expansion that classical reification requires. Where the chosen platform supports it, this removes the strongest practical argument against the resource-description approach.

The practical recommendation is unglamorous. Where the graph must interoperate with published reference data libraries and be exchanged across organisational boundaries, use the resource-description model. Where it is an internal model consumed by internal applications, use a property graph. Hybrid architectures — a canonical resource-description store with a property-graph projection for application access — are viable but double the operational surface, and should be adopted only when both requirements are genuinely present.

3.2 The layered architecture

Whichever representation is chosen, the graph must be layered. Collapsing these layers into a single undifferentiated store is the most common structural error, and it makes every subsequent governance problem harder.

Two rules follow from the table. First, inferred content must live in its own container so that it can be discarded and regenerated whenever the rules change — inference that cannot be cleanly reversed becomes indistinguishable from asserted fact within a year. Second, an ingestion pipeline may never create a class. Classes originate only from the governed ontology change process. Pipelines that mint their own classes produce a vocabulary that grows without bound and means nothing.

4. Creating nodes: identity before structure

The mechanics of node creation are trivial in every platform. The identity problem underneath them is not, and it is where the majority of remediation effort is eventually spent.

4.1 Identifiers must be stable and meaningless

Every node requires a primary identifier that is opaque — a generated value carrying no embedded semantics. Natural keys must never serve this role. Equipment tag numbers are re-lettered during revamps. Functional locations are restructured whenever the maintenance hierarchy is reorganised. Vendor serial numbers are reused. Document numbers change when a project transfers between contractors. Every one of these is a business identifier with a lifecycle of its own.

Business identifiers are therefore modelled as properties or as separate identifier nodes, each carrying its own validity period and issuing authority. This costs a little structure and buys the ability to answer "what was this called in 2019?" — a question that arises constantly during incident investigation and historical data reconciliation, and that is unanswerable once a natural key has been overwritten.

4.2 Entity resolution is a permanent layer, not a load-time step

The same physical asset arrives from several systems under several identities. Resolving them is a continuous process with three components:

•    Deterministic matching on governed keys where they exist. A properly applied reference designation standard gives an unambiguous structural address for an item within a plant, and where such a designation has been maintained it should be the first resolution attempt.

•    Probabilistic matching across attribute vectors for the remainder — manufacturer, model, rating, service description, location, installation date. Scores must be recorded, not just thresholds applied.

•    Human adjudication for candidates in the uncertain band, routed through a review queue with the evidence attached.

4.3 Typing and classification

Nodes are typed against the domain ontology, and instance-level classification should be validated at write time against the constraint shapes that the ontology defines. Where a published class library exists for the domain, instances should be classified against it rather than against locally invented types — the classification is then meaningful to any party that recognises the standard, which is the entire point of using one.

Where classification is uncertain — a common situation when ingesting legacy records with free-text descriptions — the node should be typed to the nearest confidently known superclass rather than guessed at the leaf level. An asset correctly typed as a rotating machine is useful; an asset incorrectly typed as a specific pump variant is worse than useless, because downstream logic will trust it.

5. Creating relationships

5.1 Four origins, and why they must remain distinguishable

Relationships enter a graph from four sources, and the graph must be able to tell them apart at query time:

1.   Structured mapping from relational and hierarchical sources, using a declarative mapping specification rather than bespoke transformation code. Declarative mappings are inspectable, testable and re-runnable; hand-written extraction code becomes the undocumented authority on what the graph means.

2.   Extraction from documents — engineering drawings, datasheets, inspection reports, incident narratives — using natural language processing or large language models. This is now the highest-volume source in most brownfield programmes and carries the lowest average confidence.

3.   Computation and inference — reasoner entailments, rule engine output, and edges derived from graph algorithms such as connectivity or centrality analysis.

4.   Human curation — subject matter expert assertions, correction of automated output, and the resolution of adjudication queues.

An edge whose origin cannot be determined cannot be trusted, cannot be selectively invalidated when a source is found to be defective, and cannot be excluded from a query that requires only high-assurance data. Origin is not metadata; it is part of the assertion.

5.2 Provenance as a first-class obligation

Every edge should carry, at minimum: the source system or document, the extraction method and its version, the responsible agent, the assertion timestamp and a confidence value. A standard provenance vocabulary exists and should be used rather than inventing local property names, because provenance is precisely the kind of metadata that must survive federation and export.

Provenance coverage should be treated as a first-order quality metric with a published target. In practice, coverage degrades silently: an early pipeline is built carefully, later pipelines copy the parts that produce visible output and omit the parts that do not, and within eighteen months a substantial fraction of the graph has no traceable origin. Nothing surfaces this except explicit measurement.

5.3 The reification decision: edge or node?

The most consequential modelling decision in relationship design is whether a given relationship should be a simple edge or promoted to a node in its own right. The test is straightforward:

•    Does the relationship have attributes of its own?

•    Does it have a lifecycle — does it start, end, get suspended or get revised independently of the entities it connects?

•    Does anything else need to refer to the relationship itself?

If the answer to any of these is yes, the relationship is an entity. The classic industrial example is installation. "Pump P-101 is installed at location L-22" appears to be an edge, but it is in fact an installation event with a commencement date, a removal date, an authorising work order, an installing contractor and a commissioning record. Modelled as an edge, these facts are crammed into edge properties until the model collapses; modelled as a node, they sit naturally and the installation itself can be referenced by the work order, the inspection record and the warranty claim.

The same reasoning applies to custody, certification, calibration, assignment, ownership and contractual relationships — in short, to most of the relationships that matter in an operating enterprise. Getting this wrong is not fatal, but correcting it later requires rewriting every query that traverses the affected relationship.

6. Time: retiring, superseding and correcting

This section addresses the question that separates a knowledge graph that can be operated from one that cannot: how relationships are retired and replaced as the world and our records of it change.

6.1 The append-only principle

A knowledge graph supporting an operating enterprise should be treated as append-only. Deleting an assertion destroys the ability to answer what the organisation believed at a given moment — which is exactly the question that arises during incident investigation, regulatory audit, warranty dispute and any attempt to reproduce a historical analytical result.

Retirement is therefore always a state transition, never a removal. Current-state queries filter on the temporal properties; historical queries do not. This has a modest storage cost and a substantial governance benefit.

6.2 Two independent time axes

A serviceable temporal model requires two distinct and genuinely independent time dimensions:

•    Valid time — the period during which the fact was true in the world. The pump was in service from March 2019 to November 2024.

•    Transaction time — the period during which the graph held the fact to be true. The graph recorded the removal on 2 December 2024, because the handover documentation arrived late.

These are independent because facts arrive late, arrive early and arrive wrong. Without both axes it is impossible to distinguish a late-arriving fact from a fact that changed, or a retrospective correction from a genuine event. Systems that carry only a single "last updated" timestamp collapse all three situations into one and can express none of them.

A bitemporal model allows two distinct classes of question to be answered: "what was true on this date?" and "what did we believe on this date?" In a regulated environment, the second question is frequently the one being asked.

6.3 Correction is not change

The most common and most damaging modelling error in this area is the conflation of a correction with a change. Both look superficially like replacing assertion A with assertion B. They mean opposite things:

If the model carries only a deleted or inactive flag, this distinction cannot be expressed, and every historical query silently returns a blend of the two. The consequence is not abstract: reliability analyses attribute failure history to the wrong equipment, warranty positions are calculated against incorrect service periods, and audit reconstructions cannot be defended.

6.4 Implementation patterns

Five patterns are in common use. They are not mutually exclusive; most mature implementations combine two or three.

The temporal-parts approach deserves a specific note, because it underpins one of the major engineering interoperability standards and carries a reputation for difficulty that is largely deserved. It handles genuinely hard identity questions with real rigour — whether a pump that has been overhauled with a new impeller, a new casing and a new baseplate remains the same pump is a question the approach answers cleanly rather than dodging. It also imposes a substantial modelling and comprehension burden on every downstream consumer.

The pragmatic position is to apply temporal-parts semantics where identity through change is the actual business question — typically for major rotating equipment, pressure envelopes and certified items — and to use straightforward bitemporal edges everywhere else. Applying the full apparatus uniformly across the graph is a common and expensive mistake.

6.5 Supersession hygiene

Beyond the temporal properties themselves, several practices distinguish a maintainable temporal model:

•    Always write an explicit supersession link from the retired assertion to its replacement, together with a reason code drawn from a controlled list — real-world change, correction of error, source system restructuring, or re-resolution of an entity match. The reason code is what tells a downstream consumer which time axis was closed and therefore how to interpret the pair.

•    Decide the cascade policy explicitly. Retiring a node is not the same as retiring its edges. Whichever behaviour is chosen, it must be encoded and documented; implicit cascade behaviour is a silent data-loss mechanism that surfaces months later as unexplained gaps.

•    Preserve the retracted assertion. A retraction records that the organisation once believed something incorrect. That is itself valuable — it is the evidence base for diagnosing a defective source system or a mis-tuned extraction model.

•    Do not overload validity with lifecycle state. An asset that is out of service is not an asset whose existence assertion has ended. Operational state belongs in a state model with its own temporal history, distinct from the validity of the assertion that the asset exists.

6.6 Deprecating ontology elements

Retirement in the instance layer is routine. Retirement in the ontology layer is a change programme, and should be run as one.

A class or property that is in use is never deleted. It is marked as deprecated, given an explicit replacement pointer, and subjected to impact analysis that establishes how many instances, queries, applications and downstream extracts depend on it. Instance migration is then executed under change control, and the deprecated element remains in the ontology permanently as a resolution target for anything that still refers to it — including historical exports and partner systems outside the organisation's control.

Ontology releases should be versioned semantically, with a published policy stating what constitutes a breaking change and what notice period consumers can expect. Without this, every ontology improvement becomes a negotiation, and the ontology stops improving.

6.7 Handling contradiction

Two authoritative sources will assert incompatible facts. The instinct is to resolve the conflict at ingestion and store the winner. This is the wrong instinct.

Store both assertions with their provenance and resolve at read time against a declared trust policy — source precedence, recency, confidence threshold, or an explicit curation decision. Write-time resolution destroys the evidence that a disagreement existed, and that evidence is one of the most valuable outputs a knowledge graph produces: a systematic pattern of disagreement between two systems is a data quality finding worth acting on, and it is invisible if one side is silently discarded at the door.

Where a conflict must be resolved definitively, the resolution is itself an assertion — curated, attributed, timestamped and reversible — sitting above the conflicting inputs rather than replacing them.

7. A reference implementation architecture

The following arrangement has proven durable across industrial deployments. It is described functionally; each function maps to several product categories.

7.1 Ingestion and staging

Source data lands first in a staging container, never directly into the trusted graph. Staging is where extraction, mapping, entity resolution and constraint validation occur, and where low-confidence assertions wait for adjudication. Promotion from staging to the trusted graph is an explicit, logged operation with defined criteria.

7.2 The identity service

Entity resolution is exposed as a service rather than embedded in individual pipelines. Every pipeline calls the same resolver, which means matching logic is improved in one place, resolution decisions are logged uniformly, and the confidence distribution across the whole graph can be measured. Pipelines that each implement their own matching produce a graph whose identity quality varies unpredictably by source.

7.3 The ontology and reference data repository

The ontology, its constraint shapes, the reference data libraries and the inference rules are held under source control with the same discipline applied to application code: branches, review, automated testing against a regression suite of competency queries, and versioned release. An ontology maintained by direct editing of the production store is an ontology with no change history and no rollback.

7.4 Serving and projection

Applications should generally not query the canonical graph directly. A serving layer — materialised views, projections into search indices, or a property-graph projection of a canonical resource-description store — decouples application performance requirements from the canonical model, and allows the canonical model to be restructured without breaking every consumer.

7.5 Time-series and document stores remain separate

This deserves its own statement because it is the single most common architectural failure in industrial knowledge graph projects. The graph holds the asset model, the sensor identity, the measurement context and a pointer to the historian tag. The historian holds the values. Graph engines are catastrophically inefficient at high-frequency numeric data, and a programme that loads process history into the graph will spend its second year removing it.

The same principle applies to documents. The graph holds the document entity, its classification, its relationships to assets and projects, and the assertions extracted from it. The document repository holds the file.

8. Implementation practices

8.1 Scope by competency question

Before any modelling begins, write down the questions the graph must answer, in business language, with the name of the person who will ask each one. Twenty to forty questions is a normal range for an initial scope. The ontology extends exactly as far as those questions require and no further.

This constraint is the difference between an ontology programme that delivers and one that runs indefinitely. Ontology work has no natural stopping point — there is always another distinction that could be drawn — and the competency question set is the only reliable mechanism for declaring a scope complete. The same set doubles as the regression test suite for every subsequent ontology release.

8.2 Reuse published standards aggressively

Every term invented locally is a term that must be defined, documented, governed, explained to each new team member and mapped to whatever the organisation eventually needs to exchange data with. Published vocabularies exist for most of what an industrial graph needs to express:

•    Process industry reference data libraries and lifecycle information models for equipment classification and integration

•    Capital facilities information handover specifications for the class and attribute sets exchanged at project completion

•    Process engineering data exchange formats for diagram topology and connectivity

•    Reference designation standards for structural addressing of items within a plant

•    Horizontal vocabularies for provenance, units of measure, sensors and observations, and temporal intervals

The correct posture is to adopt the standard, extend it where the organisation genuinely differs, and document every extension with a justification. Organisations that begin by building their own vocabulary invariably end up mapping it to the standard later, having paid for both.

8.3 Validate at ingestion, but treat violations as signals

Constraint validation should run on every write. The response to a violation, however, should rarely be rejection. A violation usually means the source system contains an error, and discarding the record destroys the evidence while leaving the underlying problem in place.

Route violations to a quality queue with the source attribution attached, and report violation rates by source system. This turns the graph into a continuous audit of upstream data quality — frequently the first tangible benefit a knowledge graph programme delivers, and often the one that secures its funding.

8.4 Choose deliberately between materialised and runtime inference

Materialised inference is fast and reproducible but goes stale when rules or inputs change. Runtime inference is always current but expensive and harder to explain. Either is defensible; drifting between them without deciding is not.

Whichever is chosen, every inferred edge should be stamped with the identity and version of the rule that produced it, so that a rule change can invalidate exactly the affected edges rather than forcing a full rebuild — or worse, leaving stale entailments in place indefinitely.

8.5 Model perspective, not consensus

As-designed, as-built, as-maintained and as-operated are four legitimately different views of the same facility. They will never fully agree, and the disagreements are informative rather than erroneous. A design basis that differs from the as-built condition is a finding.

Represent these as distinct perspectives, each with its own provenance and authority, connected by explicit reconciliation relationships that record where and by how much they diverge. Programmes that attempt to force a single reconciled truth stall in exactly this argument, usually for a year, and frequently do not recover.

8.6 Govern machine-generated assertions

Large language models have made document extraction dramatically more productive and have not made it reliable. The governance response is structural rather than exhortative:

•    Extracted assertions land in a staging container, never directly in the trusted graph

•    Confidence thresholds are set per assertion type, not globally — a class assignment and a safety-critical relationship warrant different bars

•    Assertions below the threshold enter a review queue with the source passage attached

•    Extraction model identity and version are recorded on every assertion, so that a model found to be defective can have its output selectively invalidated

•    Sampled audit of above-threshold assertions runs continuously, because extraction quality drifts as document types vary

The rule that admits no exception: low-confidence machine assertions never auto-promote to the trusted graph. Once they do, no downstream consumer can distinguish an extracted guess from a curated fact, and the trust value of the entire graph collapses to that of its weakest pipeline.

9. Governance and operating model

Technically excellent knowledge graphs fail on governance far more often than on technology. The minimum viable governance structure has four components.

9.1 An ontology change authority

A standing body — small, and containing genuine domain authority rather than only architects — that approves additions, deprecations and structural changes to the ontology and reference data. It meets on a fixed cadence, works from a published backlog, and issues versioned releases. Without a standing authority, ontology decisions are made ad hoc by whoever is building the current pipeline, and the model fragments.

9.2 Stewardship by domain

Each domain within the graph has a named steward accountable for the quality, coverage and currency of that domain's content. Stewardship is a role with allocated time, not an honorific added to an existing job description. Graphs without named stewards degrade quietly, because no individual is accountable for the degradation.

9.3 A published change and deprecation policy

Consumers need to know what constitutes a breaking change, how much notice they will receive, how long deprecated elements remain resolvable and how they will be notified. Publishing this converts the ontology from a shared risk into shared infrastructure.

9.4 Mandatory impact analysis

No ontology change proceeds without an assessment of affected instances, queries, applications and external extracts. This is mechanisable — the graph knows what depends on what — and automating it removes the principal objection to ontology evolution, which is that nobody can predict what will break.

10. Measuring a knowledge graph

Node and edge counts measure nothing. The following indicators track whether the graph is actually fit for its purpose, and each should have an owner and a target.

Provenance completeness and retraction rate by pipeline deserve particular attention, because both degrade without producing any visible symptom until the graph is already untrusted.

11. Common failure modes

12. A phased adoption path

Phase 1 — Narrow and demonstrable (one quarter)

Select a single high-value question set — typically equipment master reconciliation across two or three systems, or handover completeness verification. Model only what those questions require. Establish the identity service, the provenance discipline and the temporal model from the outset, even at small scale, because retrofitting any of the three is far more expensive than building them in.

Phase 2 — Broaden the instance base (two to three quarters)

Extend to further source systems within the same domain. This is where the identity layer is genuinely tested and where resolution quality measurement becomes essential. Stand up the ontology change authority before the second domain is added, not after.

Phase 3 — Extend the domain (ongoing)

Add adjacent domains — maintenance history, process conditions, documents, projects — each with its own competency question set and its own steward. By this stage the ontology release process, the impact analysis mechanism and the measurement framework must all be operating, or the graph will begin to fragment under its own growth.

Phase 4 — Consumption and inference

Serving projections, retrieval for generative AI, inference rules and analytical products. It is tempting to begin here because this is where visible value sits. Programmes that do so consistently discover that inference over an ungoverned graph produces confidently wrong answers at scale, which is considerably worse than producing none.

13. Closing observations

A knowledge graph is not a database selection. It is a commitment to maintaining a shared, formal, evidenced account of what an organisation knows — including what it once believed and has since revised. The technical mechanisms described in this paper exist to make that commitment operable: opaque identifiers and an equivalence layer so that identity survives change; provenance on every assertion so that trust is calculable rather than assumed; two independent time axes so that a correction can be told apart from a change; and a governance model so that the vocabulary improves rather than fragments.

None of these is exotic. All of them are routinely omitted from initial implementations on the grounds that they can be added later. They cannot be added later at acceptable cost — each of them touches every assertion in the graph. The organisations that get durable value from knowledge graphs are, with striking consistency, those that built the unglamorous layers first.

Identity is harder than structure. Time is harder than identity. Governance is harder than all of it. Budget accordingly.

About this paper

This paper forms part of an ongoing whitepaper series on industrial digitalisation, covering operational technology architecture, cybersecurity, sustainability and the energy transition. It is vendor-neutral: product categories are described functionally, and no specific platform is recommended. Readers evaluating platforms are encouraged to test candidates against their own competency question set rather than against feature comparisons.