1. Introduction

2. The Three Roles at a Glance

3. Knowledge Graph: Governed Meaning

4. Memory Graph: Retained Experience

5. Context Graph: The Decision-Time View

6. How the Three Roles Work Together

7. One Graph Database or Several Data Stores?

8. When Agent Memory Becomes an Enterprise Capability

9. Summary

10. References

1. Introduction

Enterprise AI architecture is acquiring graphs at an impressive rate.

We already had knowledge graphs. We now have memory graphs, context graphs, reasoning graphs and decision graphs. Put them into one architecture diagram and it can look as though every AI agent needs several new graph databases before it can answer a useful question.

From a Labelled Property Graph, LPG, practitioner’s point of view, this is the wrong place to start.

Knowledge graph, memory graph and context graph should first be understood as three architectural roles:

A knowledge graph represents governed enterprise knowledge.

A memory graph represents retained experience around that knowledge.

A context graph represents the information selected for one task, actor, purpose and point in time.

The three roles share connected entities, relationships, time and provenance. They differ in authority, write path, lifecycle, scope and persistence.

Agent memory is also broader than a memory graph. It may include session state, source events, documents, vector indexes, workflow checkpoints, procedures and executable skills. A memory graph is the connected representation used when identity, relationships, time and provenance materially affect retrieval or action.

This article develops several ideas from my previous publications. A Practical Architecture for LLM Memory examined the role of an LPG in long-term agent memory [1]. Enterprise Knowledge Graphs vs Applied Knowledge Graphs separated reusable enterprise meaning from application-level decision support [2]. The Ontology Trap argued that generated structure should remain a proposal until it has passed validation and governance [3].

The purpose here is narrower. It is to explain what the three graph roles have in common, where they differ and how to use them without turning three useful terms into three unnecessary platforms.

2. The Three Roles at a Glance

“Context graph” does not yet have one stable industry meaning. It has been used for context-enriched knowledge graphs, operational event graphs and graphs assembled for runtime decisions [9].

In this article, a context graph is a task-specific runtime projection of knowledge, memory, live state and policy. It is a structured decision context, not another enterprise source of truth.

All three roles operate over connected entities and relationships. Each depends on some combination of identity, time, provenance and controlled meaning. Their main differences concern who writes the information, how much authority it carries, how long it remains and how widely it is reused.

What they have in common

The same canonical entity can appear in governed knowledge, retained experience and the current context without being recreated three times.

For example, one LegalEntity node may be connected to:

• accepted ownership relationships in the knowledge graph

• previous screening claims and analyst decisions in the memory graph

• the evidence selected for the current review in the context graph

The shared foundation includes more than the LPG model itself. It also includes governance:

• canonical identity

• controlled relationship meaning

• provenance

• temporal interpretation

• access rules

• lifecycle management

The LPG provides nodes, relationships and properties. It does not decide whether an assertion is governed, unreviewed, rejected or merely relevant to the current task. Those distinctions must be designed into the architecture.

3. Knowledge Graph: Governed Meaning

Within this architecture, the knowledge graph holds governed enterprise meaning.

Governed meaning includes the identities, definitions, relationships and rules that the organisation has accepted for reuse under explicit ownership and lifecycle controls.

That is an assigned architectural role, not a universal definition of every knowledge graph. Some knowledge graphs also contain extracted or disputed information. The approach used here keeps those less certain assertions in the memory graph until a defined governance process accepts them.

The LPG fragments in this article are illustrative patterns rather than complete production schemas.

A simplified beneficial ownership model might contain:

(:LegalEntity)-[:REGISTERED_IN]->(:Jurisdiction)
(:LegalEntity)-[:HAS_BENEFICIAL_OWNER]->(:Person)
(:EntityType)-[:SUBJECT_TO]->(:ComplianceObligation)
(:ComplianceObligation)-[:DEFINED_BY]->(:RegulatorySource)

This structure can support questions such as:

• Which canonical entity does this identifier represent?

• Which person is accepted as a beneficial owner?

• Which obligation applies to this type of entity?

• Which regulatory source defines that obligation?

• During which period was the ownership relationship valid?

The value does not come from representing documents as nodes. It comes from connecting identity, relationships, evidence and applicable rules in a form that several workflows can reuse.

The domain semantic contract

A knowledge graph needs a domain semantic contract.

That contract governs the wider graph model. It may define:

• canonical identifiers

• approved labels and relationship types

• valid source and target patterns

• required provenance

• temporal expectations

• ownership

• validation requirements

• permitted lifecycle transitions

The Minimum Semantic Contract is narrower. It defines the smaller subset of labels, relationships, evidence conditions and temporal rules that a particular runtime is allowed to trust [4].

The distinction is practical.

The domain semantic contract may describe everything the graph can represent. The Minimum Semantic Contract describes what one agent or application may safely use.

Database constraints can enforce part of the model. The ISO GQL standard defines a language for property graphs, while graph products provide implementation-specific constraints and privileges [10][11]. These features help to enforce structure, but they do not decide what the enterprise accepts as true or suitable for use.

Domain rules, runtime policy and access control

Three different forms of control should remain separate.

A domain rule describes subject-matter logic, such as the evidence needed to establish beneficial ownership.

A runtime policy controls how an agent may retrieve, combine or act on information.

An access control determines who may read or write particular information.

A fourth concern, purpose limitation, determines what authorised information may influence a particular task.

An analyst may be allowed to view a document but still be prohibited from using it as the sole basis for an automated ownership decision.

An extracted claim is not governed knowledge

Suppose an extraction agent processes a filing and proposes that a person controls a legal entity.

The document contains a similar name and a shared address. That may justify further investigation, but it does not yet justify this governed relationship:

(:LegalEntity)-[:HAS_BENEFICIAL_OWNER]->(:Person)

The initial result should remain a claim linked to its source and review:

(:OwnershipClaim)-[:SUBJECT]->(:LegalEntity)
(:OwnershipClaim)-[:OBJECT]->(:Person)
(:OwnershipClaim)-[:WAS_DERIVED_FROM]->(:SourceSpan)
(:AnalystDecision)-[:REVIEWS]->(:OwnershipClaim)

An observation records what a source presented. A claim is a proposition extracted or inferred from that observation. Evidence supports or challenges the claim. Only after validation and governance should it become an accepted enterprise assertion.

The accepted claim may remain as the evidence-bearing record. A derived edge can then provide a simpler path for operational traversal.

This avoids a common mistake. An agent-generated relationship and a governed relationship may look identical in an LPG unless their different authority and lifecycle are made explicit.

The operating principle remains:

AI proposes. Systems validate. Analysts decide. The graph records the decision.

Time belongs to the assertion

A relationship may be governed and still be valid only for a defined period.

A legal entity can exist for decades, while one ownership relationship remains valid for six months. Dates therefore belong to the relationship or claim they describe, not only to the entity.

At minimum, the model should distinguish:

• valid time, when the assertion was true or applicable in the domain

• transaction time, when that version was held by the system

This allows the graph to answer both current and historical questions without mixing incompatible states [6].

4. Memory Graph: Retained Experience

A memory graph records experience around governed entities and relationships.

It may connect:

(:Episode)
(:Observation)
(:Claim)
(:Retrieval)
(:ToolCall)
(:AnalystDecision)
(:Action)
(:Outcome)
(:Feedback)

In the beneficial ownership example, the graph might contain:

(:ReviewCase)-[:CONCERNS]->(:LegalEntity)
(:Retrieval)-[:RETURNED]->(:SourceVersion)
(:OwnershipClaim)-[:WAS_DERIVED_FROM]->(:SourceSpan)
(:AnalystDecision)-[:REVIEWS]->(:OwnershipClaim)
(:Outcome)-[:FOLLOWS]->(:AnalystDecision)

The knowledge graph can show the accepted ownership structure and the obligation that applies.

The memory graph can show which source version was retrieved, what claim the agent produced, why the analyst accepted or rejected it, and what happened afterwards.

That additional history helps the system avoid repeating failed or misleading patterns.

Agent memory is broader than the graph

A memory graph is one component of agent memory.

The broader capability may also use:

• session state

• the source event record

• lexical and vector indexes

• documents

• workflow checkpoints

• controlled procedures

• executable skills

Graph structure becomes useful when relationships between events, entities, claims, decisions and outcomes affect later retrieval or action.

A preference such as “show the result as a table” may need only a profile record. A history of disputed ownership claims, source versions and analyst decisions has a much stronger graph shape.

A technical log is not automatically memory

A log may show that a search tool returned ten documents.

Useful memory connects that event to its purpose and outcome:

The graph adds value when these connections improve later retrieval, reconstruction or explanation.

Recent research treats agent memory as a lifecycle that includes writing, storing, retrieving, updating and forgetting [13]. Systems such as APEX-MEM and Zep use temporal graph structures to connect episodes, claims and changing information [14][15].

These systems provide useful patterns, but they do not show that every memory problem needs a graph database.

The source event record

The original interaction history should normally remain available in a source event record.

This record preserves:

• what the agent received

• what a tool returned

• which action was requested

• what the analyst accepted or rejected

• what outcome was observed

It is authoritative for the interaction itself, not automatically for the underlying domain assertion.

A record showing that an ownership claim was retrieved proves that the claim was retrieved. It does not prove that the person was a beneficial owner.

Keeping the source event record independently of the derived memory graph allows the graph to be rebuilt when extraction logic, identity resolution or the semantic contract changes.

A proposed minimum memory contract

There is no universal schema that fits every observation, claim, action and outcome.

A practical proposal would give each durable memory:

• a stable identifier

• a controlled memory type

• authenticated origin

• provenance

• user, case, tenant or application scope

• relevant time information

• lifecycle and validation state

• source authority

• retention rules

• the contract version under which it was created

Different memory types would then add their own fields.

An inferred ownership claim may require confidence, source spans and an extractor version. A directly recorded tool call may not need confidence. An outcome may concern several entities rather than one subject.

The proposal should remain extensible rather than forcing every memory into one flat record.

Lifecycle, validation, source authority, permitted use and retention should also remain separate. A memory can be current but unreviewed, rejected but retained for audit, or historically valid but no longer applicable to the present case.

Compressing all these meanings into one status property usually creates ambiguity.

Remembering rejection and failure

Useful memory includes more than successful actions.

It should preserve that:

• a claim was rejected

• a source version was superseded

• an extraction pattern produced a false match

• a decision required analyst review

• an action was prohibited for the stated purpose

I have described this category as Negative Semantic Knowledge [5].

It is different from missing information. The system explicitly knows that a claim, source or action should not be used in a particular way.

The retrieval layer must enforce that knowledge. Recording a rejection while continuing to return the rejected claim as current information preserves history but does not create reliable memory.

Quality starts at the write boundary

Persistent memory creates a feedback loop. A weak claim stored today may influence many later decisions.

Research has shown that agents often follow retrieved experience even when it is incorrect or only superficially similar [16]. Other work has demonstrated memory-poisoning and privacy risks [17][18].

A controlled write path should therefore preserve source origin, authenticate the writer, distinguish observation from inference and quarantine unreviewed claims.

Repeated retrieval does not turn an uncertain claim into trusted knowledge.

5. Context Graph: The Decision-Time View

A context graph is the structured decision context assembled for the current task.

It combines selected parts of:

• the knowledge graph

• the memory graph

• live operational state

• runtime policy

• access and purpose restrictions

Live operational state means information that may change during the workflow, such as the current case status, the documents already reviewed, the latest screening result or the actions already attempted.

For a beneficial ownership review, the complete environment may contain many entities, filings, claims, previous decisions and regulatory obligations.

The context graph should include only what is:

• relevant to the entity under review

• valid at the review date

• applicable to the jurisdiction and entity type

• available to the analyst

• permitted for the current purpose

It may therefore contain the accepted ownership path, one unresolved claim, the source versions supporting each assertion, a previous rejection reason and the obligation currently in force.

The context graph is not the prompt

The context graph is a structured decision context.

It may be delivered to an agent as:

• selected graph paths

• structured records

• source excerpts

• JSON

• citations

• a concise evidence summary

The prompt or tool response is the delivery format.

GraphRAG creates value through better selection and reconstruction, not by placing a larger graph-shaped payload into the model context [7][8].

Context is usually temporary

Most context graphs exist for one task or run.

Their contents change when the entity, analyst, purpose, time or policy changes. Permanent RELEVANT_TO relationships are therefore often misleading.

A source relevant to one review date may be outdated for another. Information available to one analyst may be restricted for another. A previously useful claim may have been superseded.

Where audit or replay is required, the system can retain a Context Snapshot.

A useful snapshot records:

• the exact source versions and graph assertions selected

• the relevant valid and transaction times

• the runtime policy and Minimum Semantic Contract versions

• the access and purpose decisions

• the retrieval and filtering parameters

• the actor and task

A list of mutable node identifiers is not enough. Historical reconstruction requires versioned or otherwise stable content.

6. How the Three Roles Work Together

The three roles form a lifecycle rather than a simple hierarchy.

Four inputs contribute to context assembly:

Governed sources contribute accepted knowledge. Agent interactions and analyst decisions contribute experience. Live state shows what is happening in the current workflow. Runtime policy and access controls determine what may be retrieved and how it may be used.

Context assembly brings these inputs together without treating them as equally authoritative.

Consider an analyst reviewing the ownership of a legal entity.

The knowledge graph contains an accepted owner and the relevant compliance obligation. The memory graph records that an earlier agent proposed another owner based only on a shared service-provider address. An analyst rejected that claim and recorded the reason.

For the current task, the context graph includes the accepted ownership path, the rejected claim, its supporting source and the previous rejection reason. The agent can then avoid repeating the same weak inference.

The decision creates new experience, which enters the source event record and may update the memory graph.

Most experience remains memory. Some repeated and validated experience may justify a change to governed knowledge.

Suppose several rejected claims show that the same extraction pattern repeatedly treats a service-provider address as evidence of control. After review, the organisation may add a governed rule stating that the address alone is insufficient.

The memory graph reveals the pattern. The knowledge graph records the accepted rule.

7. One Graph Database or Several Data Stores?

Knowledge graph, memory graph and context graph are logical roles. They are not procurement instructions.

A knowledge graph and memory graph can share one graph database when they have:

• common canonical identifiers

• compatible access controls

• manageable write volumes

• similar availability requirements

• compatible retention rules

• clear ownership

One database might contain:

Knowledge:
LegalEntity, Person, Jurisdiction, ComplianceObligation

Memory:
Episode, OwnershipClaim, AnalystDecision, Outcome

Audit:
Run, ContextSnapshot

Labels, relationship types and service APIs can preserve modelling boundaries. They do not create security boundaries on their own.

A label such as :RestrictedClaim does not prevent a database user from reading the node. Security requires explicit authentication, authorisation and graph privileges [12].

Separate data stores become reasonable when operational requirements differ. Memory may have a much higher write volume than governed knowledge. It may require shorter retention, stronger tenant isolation or more frequent deletion. Generated claims may also need to remain quarantined from accepted assertions.

Physical separation does not remove the need for shared identity. Each store should use the same durable business identifiers even when it maintains its own local nodes.

A context graph rarely needs its own database. It is normally assembled for a task and discarded afterwards. When persistence is required, a Context Snapshot can be retained without creating a new enterprise context master.

Some agent memory does not need a graph at all.

A preferred output format may belong in a profile record. A workflow stage may belong in a transactional table. A controlled procedure may remain a versioned document. Conversation history may be stored in an event stream. Lexical or vector retrieval may be sufficient when relationships do not materially change the result.

The presence of an AI agent does not make every persistence problem graph-shaped.

8. When Agent Memory Becomes an Enterprise Capability

Agent memory is becoming an important enterprise capability.

Long-running agents need to preserve observations, recognise corrections, reuse relevant experience and maintain continuity across sessions. They also need controlled ways to write, update and forget memory.

This does not always require an enterprise memory service.

Three decisions should be made independently.

A shared enterprise memory service becomes justified when several agents need the same experience, identity resolution must remain consistent, retention and deletion require common governance, and decisions need cross-application audit.

For one assistant remembering a small set of display preferences, this would be excessive.

A sensible progression is:

1. session state

2. simple durable memory

3. application-scoped memory graph

4. shared enterprise memory service

The architecture should move to the next stage only when the earlier one can no longer meet the requirement.

The graph break-even point

A graph becomes more credible when several conditions are present:

1. Correct retrieval or reconstruction requires multi-hop relationships.

2. Identities vary across systems or sessions.

3. Relevant relationships change over time.

4. Provenance affects whether information can be trusted.

5. Previous actions and outcomes affect the next decision.

6. Several applications reuse the connected experience.

This is a design test rather than a benchmark.

The economic question remains:

Does the improvement justify identity resolution, graph modelling, extraction, governance, security, reprocessing and operational cost?

9. Summary

Knowledge graph, memory graph and context graph use similar connected-data foundations, but they serve different roles.

The knowledge graph represents governed enterprise knowledge. It connects canonical identities, accepted assertions, relationships and domain rules.

The memory graph represents retained experience. It connects observations, claims, actions, decisions, outcomes and feedback. It is one part of the wider agent-memory capability.

The context graph represents the structured decision context selected for one task, actor, purpose and point in time.

They can share canonical identifiers and graph technology. They may even share one database. Their authority, lifecycle and scope should remain distinct.

Five practical rules follow:

1. Keep governed knowledge separate from agent-generated claims.

2. Link memory to canonical identities instead of remastering them.

3. Build context for a task instead of storing permanent relevance.

4. Use separate data stores only when security, workload, retention or ownership requires them.

5. Introduce graph structure only when relationships, time and provenance materially improve the result.

Most organisations do not need three new graph platforms.

They need governed knowledge, trustworthy experience and a context assembly process that knows the difference.

10. References

Previous publications

1. Sergey Vasiliev. A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache. 29 November 2025.

2. Sergey Vasiliev. Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path. 3 December 2025.

3. Sergey Vasiliev. The Ontology Trap: When AI Scales Unvalidated Meaning. 11 June 2026.

4. Sergey Vasiliev. From LPG to GraphRAG: The Minimum Semantic Contract. 10 July 2026.

5. Sergey Vasiliev. The Missing Half of Enterprise Semantics: What the Agent Must Not Do. 31 July 2026.

6. Sergey Vasiliev. Topological and Temporal Aspects of Graphs. 19 January 2026.

7. Sergey Vasiliev. RAG vs GraphRAG vs KAG: A Graph Practitioner’s Perspective. 11 February 2026.

8. Sergey Vasiliev. Why Most GraphRAG Evaluations Are Wrong. 17 April 2026.

Technical references

9. Chengjin Xu et al. Context Graph. arXiv preprint, 2024. DOI: 10.48550/arXiv.2406.11160.

10. ISO/IEC 39075:2024. Information Technology: Database Languages: GQL. First edition, April 2024.

11. Neo4j. Graph Database Concepts and Cypher Documentation. Accessed 16 August 2026.

12. Neo4j. Role-Based Access Control and Graph Privileges. Accessed 16 August 2026.

13. Chang Yang et al. Graph-Based Agent Memory: Taxonomy, Techniques, and Applications. arXiv preprint, 2026. DOI: 10.48550/arXiv.2602.05665.

14. Pratyay Banerjee et al. APEX-MEM: Agentic Semi-Structured Memory with Temporal Reasoning for Long-Term Conversational AI. Proceedings of ACL 2026. DOI: 10.18653/v1/2026.acl-long.749.

15. Preston Rasmussen et al. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. Company-authored arXiv preprint, 2025. DOI: 10.48550/arXiv.2501.13956.

16. Zidi Xiong et al. How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior. Proceedings of ACL 2026. DOI: 10.18653/v1/2026.acl-long.27.

17. Jiachen Qian. Visual Inception: Compromising Long-Term Planning in Agentic Recommenders via Multimodal Memory Poisoning. Proceedings of ACL 2026. DOI: 10.18653/v1/2026.acl-long.954.

18. Bo Wang et al. Unveiling Privacy Risks in LLM Agent Memory. Proceedings of ACL 2025. DOI: 10.18653/v1/2025.acl-long.1227.

1. Introduction

2. The automatic journey from semantics to RDF

3. What RDF solves and what it does not replace

4. Eight signals that RDF may be unnecessary

5. The ontology tax is not one cost

6. When RDF earns the investment

7. The RDF Break-Even Test

8. AI needs trustworthy context, not a preferred syntax

9. Summary

10. References

1. Introduction

Three ideas keep returning in discussions about Resource Description Framework (RDF).

The first is that a proper ontology can only be built with RDF. The second is that RDF already contains everything an enterprise needs for semantics, identity, validation, inference and interoperability. The third is that RDF may cost more at the beginning, but becomes the cheaper option as the number of domains and systems grows.

There is some truth in each of these ideas. RDF has a mature standards ecosystem and remains a strong choice when meaning must be shared across systems, organisations and time. The problem begins when these strengths are turned into universal rules.

Not every ontology needs the same level of formalism. Not every enterprise problem needs every capability available in the RDF stack. And cost does not depend on the data model alone. It also depends on the workload, data quality, change rate, governance, skills and the number of applications that will reuse the result.

This is not an argument against RDF, ontology or formal semantics. It is an argument against treating RDF as the automatic destination of every knowledge graph, semantic layer or enterprise AI initiative.

In previous publications, I separated RDF as a knowledge representation model from an LPG as operational decision infrastructure [1]. I also argued that knowledge graphs can be realised through different graph models, and that semantics is not created merely by choosing a database, query language or ontology technology [2][3][4].

This article begins with a more basic question:

Does your business problem need RDF at all?

2. The automatic journey from semantics to RDF

Enterprise semantic programmes often follow a familiar line of reasoning:

Our data is inconsistent, so we need semantics. We need semantics, so we need an ontology. We need an ontology, so we need RDF.

Each step may be reasonable. The conclusion does not automatically follow.

Inconsistent data may require clearer definitions, stronger identity management, governed data contracts, temporal context, provenance, validation and ownership. An ontology may help formalise some of those agreements. RDF may then be an effective way to represent and exchange them.

These are still separate architectural decisions.

Data inconsistency is not always an ontology problem. It may come from duplicate source systems, incompatible identifiers, missing ownership, weak operational processes or uncontrolled local definitions. Representing these problems as triples does not resolve them.

Choosing RDF also does not make enterprise data meaningful. It makes RDF the chosen representation of that meaning. Definitions still have to be agreed. Identities still have to be reconciled. Mappings still have to be maintained. Changes still have to be approved and tested.

This distinction matters because RDF is sometimes presented as a semantic maturity level. The implied hierarchy is that relational systems are basic, LPGs are practical but limited, and RDF is the mature destination.

That is not a useful architectural hierarchy.

A relational schema can express precise meaning inside a controlled application. An API can define a governed contract between known systems. An event schema can describe the meaning and lifecycle of a business event. An LPG can represent operational relationships, paths, state and decision context.

None of these approaches is semantically empty because it does not use RDF.

The same applies to ontology. As discussed in The RDF Assumption That Meaning Lives in Ontology Is Breaking in the LLM Era, enterprise meaning is also carried by context, policy, evidence, operational state and the conditions under which a fact may be used [5]. An ontology can formalise part of that meaning, but it does not contain the complete enterprise reality.

RDF should therefore be selected because it enables a required capability. That capability may involve interoperability, reusable identity, shared vocabularies, formal entailment or long-term preservation of meaning.

When the business cannot name the capability, RDF may add semantic infrastructure without changing the result.

3. What RDF solves and what it does not replace

Representation, semantics and validation

RDF is an abstract data model for representing information as graphs. An RDF graph contains subject-predicate-object triples, while an RDF dataset may contain a default graph and one or more named graphs. RDF uses Internationalised Resource Identifiers, or IRIs, as a standard way to identify resources and relationships [10].

The wider RDF ecosystem provides additional capabilities, but they should not be confused with base RDF.

RDF Schema and the Web Ontology Language, OWL, can define formal semantic relationships. Formal entailment means deriving a conclusion that logically follows from the asserted information and the declared semantics. In practical terms, it can make implicit knowledge explicit.

SHACL, the Shapes Constraint Language, can validate RDF graphs against declared conditions. PROV-O, the PROV Ontology, provides classes and properties for representing and exchanging provenance information [12][13][14].

These are valuable capabilities, but they are separate choices. An organisation may use RDF without OWL reasoning. It may use SHACL validation without a large domain ontology. It may publish linked data without making RDF its operational system of record.

RDF, ontology, validation, reasoning, storage and governance should not be approved as one indivisible package called semantics.

A modest requirement to align several identifiers can otherwise expand into an enterprise ontology, a triplestore, a reasoning environment, source mappings, specialist tooling and a new governance organisation. Each part may be useful, but each part needs its own justification.

Global naming is not the same as stable identity

IRIs allow identifiers to be expressed in a globally recognisable naming scheme. That is useful when independent systems need to refer to the same resource without sharing one database key.

However, global scope does not guarantee stability.

An IRI is not automatically persistent, correctly assigned or governed. Someone must decide what it identifies, who may create it, whether it can be reassigned, how duplicates are resolved and what happens when the represented entity changes.

RDF supplies a standard identification mechanism. The organisation still has to supply the identity policy.

An unmanaged IRI is not inherently more trustworthy than an unmanaged relational key.

RDF, SPARQL and database products are different things

RDF is the data model. SPARQL is a family of standards used to work with RDF data. Triplestores and other RDF database products implement storage and operational capabilities.

SPARQL 1.1 Query Language defines how graph patterns can be queried and how results may be returned. SPARQL 1.1 Update defines operations that update, create and remove RDF graphs in a graph store [15][16].

Individual database products may add transactions, concurrency control, access management, audit functions, replication, backup and recovery. The details vary between implementations.

This distinction matters when discussing Create, Read, Update and Delete operations, usually shortened to CRUD.

RDF is not technically static. RDF data can be queried and changed. A triplestore may also provide strong transactional behaviour.

The more important question is whether those technical operations capture the business lifecycle.

RDF and the enterprise data lifecycle

Enterprise CRUD is not only about inserting, reading, updating and deleting stored values. It represents the changing life of a business object.

An order may be created, approved, changed, fulfilled, cancelled and retained for audit. A policy may be drafted, approved, made effective, superseded and eventually withdrawn. A payment may be initiated, authorised, settled, rejected or reversed.

These transitions carry operational meaning.

RDF can represent the states, events, actors and evidence involved. It does not, by itself, define which transitions are valid, who may approve them, how conflicting changes are resolved, what must be retained or what a deletion means to the business.

No data model supplies a complete enterprise lifecycle on its own.

A relational model does not automatically know that a payment reversal requires a second approval. An LPG does not automatically know that a cancelled order must remain available for seven years. Application logic, workflow, policy and governance are still needed.

The point is not that RDF uniquely fails to provide lifecycle management. The point is that RDF’s strengths in representation and interoperability should not be mistaken for a complete operational lifecycle model.

Three separate questions should therefore be kept apart.

First, what happened to the graph? A SPARQL Update operation may remove a triple from a particular graph.

Second, what can now be concluded logically? Under standard RDF and OWL semantics, the absence of a statement is not generally treated as proof of its opposite. Removing a statement that a customer is active does not logically assert that the customer is inactive [11][12].

Third, what does the change mean to the business? The customer may have become inactive, the status may be unknown, the source may have been corrected, or the information may have moved to a different version. That meaning must be modelled and governed explicitly.

RDF is particularly strong when meaning must travel independently of one application. It is less obviously necessary when the main problem is controlling changing state inside one operational boundary.

4. Eight signals that RDF may be unnecessary

The following situations are not automatic rejection rules. One regulatory or interoperability requirement may justify RDF even when several other conditions point towards a simpler model.

They are signals that RDF should carry a higher burden of proof.

4.1. The problem is contained within one application

One application owns the data, workflow, schema and definitions. Its product team controls releases and most consumers use the same operational model.

A relational schema, domain model or governed API may already express the required meaning. Adding RDF could create a second representation without creating an independent consumer.

4.2. The schema is controlled and changes predictably

RDF is valuable when data sources evolve independently and no single team controls the complete model.

Where one organisation owns the schema and manages planned changes, explicit constraints and versioned contracts may be enough. Semantic flexibility is not automatically an advantage when the domain is intentionally controlled.

4.3. The main workload is transactional

Operational systems often prioritise validation, concurrency, predictable writes, recovery and controlled state transitions.

RDF may be useful for publishing or integrating the resulting information, but that does not make it the best foundation for creating orders, settling payments or managing workflow state.

The decision should follow the workload rather than the presence of relationships.

4.4. Relationships are local and predictable

Almost all enterprise data contains relationships. Customers place orders, employees belong to teams and contracts refer to parties.

A small set of known joins does not automatically justify RDF or any graph database.

An LPG may become attractive when repeated multi-hop traversal, paths, topology or graph algorithms create value. RDF may become attractive when relationships need shared meaning across independent systems. A few predictable joins may need neither.

4.5. Formal entailment does not affect an outcome

A derived conclusion matters when it changes an approval, classification, obligation, control or permitted action.

It matters less when application code calculates the same result, when every conclusion needs manual confirmation, or when the result appears only in a demonstration.

Rules, SQL, materialised relationships, graph algorithms and machine learning may also derive or predict information. These mechanisms are not equivalent to OWL entailment, but one of them may fit the decision more naturally.

4.6. External vocabularies are not genuinely reused

RDF becomes compelling when regulators, partners, research communities or industry bodies already recognise the same vocabulary.

An external ontology that no real consumer uses may add mapping work without reducing integration work. In a purely internal domain, a shared API schema, data contract or metadata service may be sufficient.

4.7. Only one application will consume the model

A semantic model created for one report, chatbot or retrieval pipeline can still be useful. It is probably an application model rather than enterprise semantic infrastructure.

Future reuse should be concrete. The proposal should name the next consumers, the mappings they will stop maintaining and the teams committed to adoption.

4.8. Nobody owns semantic change

Shared meaning needs funded ownership.

Someone must govern identifiers, vocabulary versions, mappings, deprecations, validation rules and inference behaviour. Without that ownership, a shared model will drift like any other enterprise model, while its failures may affect more consumers.

These conditions do not suggest that the organisation needs no semantics. They suggest that the semantics may be implemented more simply through the operational model, contracts, policies and governance the organisation already uses.

5. The ontology tax is not one cost

I use ontology tax as a working label, not as an established industry metric.

The phrase is useful because it draws attention to costs that are often missing from semantic demonstrations. However, those costs should not all be attributed to ontology.

They fall into at least three groups.

Ontology design cost

This includes defining concepts, properties, axioms, classifications and vocabulary versions. It also includes resolving conflicting interpretations and reviewing the consequences of a semantic change.

These are genuine ontology costs.

RDF integration and platform cost

This includes mapping source systems, generating and synchronising RDF data, managing identifiers, operating a triplestore, building queries and integrating the graph with applications.

Some of these costs would exist in any integration architecture. The important point is to identify them rather than hide them inside a broad claim about semantic maturity.

Shared semantic governance and adoption cost

This includes ownership, approval processes, consumer support, version communication, lifecycle management, testing and the effort required to persuade teams to reuse the shared model.

The cost often grows with the ambition of the programme. A model used by ten systems can create more value than a model used by one, but it also requires stronger change management.

Other architectures pay similar costs. Relational systems require modelling and migration. LPGs require identity rules and graph governance. APIs require contracts, versioning and support.

The question is not whether RDF has costs that other models avoid entirely. It is whether RDF creates enough additional value to justify the specific combination of modelling, integration and governance work.

Consider two examples.

In the first, eight systems and several external partners maintain separate mappings for the same products, legal entities and regulatory classifications. A shared RDF representation may reduce duplicated mapping, preserve common identifiers and make partner integration easier. Several consumers share the cost.

In the second, one internal chatbot answers questions from two governed tables. Mapping those tables into RDF may improve the conceptual design, but it may not improve the answers enough to justify a second query stack, synchronisation process and governance model.

The same issue appears in CRUD-heavy environments. When the operational application remains the only trusted place where records can be created, corrected and deleted, an RDF layer may become a semantic copy of operational state. That copy still needs synchronisation, reconciliation, version management and reprocessing.

The ontology tax is reasonable when several systems reuse the meaning. It is difficult to justify when one application merely needs a better query.

6. When RDF earns the investment

RDF earns its place when it creates a capability that simpler local models cannot provide as effectively over the expected life of the solution.

One strong case is exchange between independent organisations. Shared identifiers and vocabularies can provide an agreement that exists outside any single application, database or vendor.

Another is the reuse of established standards. A vocabulary already recognised by regulators, research communities or industry partners may reduce repeated negotiation and custom mapping.

RDF can also help when datasets evolve independently. It does not remove the need to understand and map each source. Its value comes from allowing several sources and consumers to align through a common representation rather than maintaining a separate mapping for every pair.

Formal entailment may justify the investment when a logically derived conclusion changes a real outcome. For example, a product classification derived from asserted properties and an ontology may trigger an additional compliance check or alter an approval route.

Longevity provides another reason. Applications are replaced, databases are migrated and vendors change. A standards-based representation can help preserve identities, classifications, relationships and provenance beyond the life of the systems that originally created them.

Linked data publication or consumption may itself be a requirement. In that situation, RDF is not one optional implementation among many. It is part of the requested capability.

Consider a hypothetical product compliance network involving manufacturers, distributors and regulators. Each participant owns different systems and release cycles. They need to exchange product identities, classifications, evidence and regulatory status.

A shared RDF vocabulary may allow all parties to use the same identifiers and classification terms without adopting the same application. Formal rules may derive which compliance regime applies, while provenance records show where the supporting information came from.

The value would not be the number of triples produced. It would be fewer custom mappings, faster onboarding of new participants, less ambiguity in product identity and more consistent compliance decisions.

Even then, RDF does not need to perform every architectural role.

The manufacturer may keep product transactions in a relational system. An LPG may support supply-chain paths and risk analysis. Event streams may carry lifecycle changes. Policy services may enforce permissions and obligations. RDF may provide the durable semantic and exchange layer connecting them.

RDF earning a place does not mean RDF must become the whole architecture.

7. The RDF Break-Even Test

The RDF Break-Even Test is a working term for a qualitative architectural assessment. It is not a mathematical formula, a universal score or a claim that every question has equal weight.

A legal or contractual requirement to use a standard may be decisive even when several other answers are no. Conversely, a long list of speculative benefits should not justify an enterprise platform.

Each positive answer should be supported by evidence.

Required capability and obligation

1. Is an RDF-based standard required by a regulator, partner or established ecosystem?

Name the standard, the external parties and the exchange process.

A concrete obligation is stronger than a general preference for semantic interoperability.

2. Which business capability becomes possible because RDF is used?

“Better semantics” is not a business capability.

A useful answer describes what the organisation will be able to exchange, reuse, derive or preserve that it cannot achieve economically today.

3. Does formal entailment change a decision, action or control?

The proposal should identify the asserted information, the conclusion that is logically derived and the workflow that changes as a result.

It should also explain how ontology changes will be tested. Making implicit knowledge explicit is valuable only when someone or something uses the conclusion.

Reuse, identity and longevity

4. Which independent consumers will reuse the model?

Name the applications, teams, partners and workflows.

Expected reuse should be based on committed consumers rather than the possibility that somebody may adopt the model later.

5. Are shared identifiers materially important?

Describe the current identity problem. It may involve duplicate entities, failed joins, incompatible partner identifiers or repeated reconciliation.

Using IRIs can provide a common naming mechanism. Stable identity still requires ownership, persistence rules and entity resolution.

6. Will established external vocabularies replace local negotiation?

Name the vocabularies and the consumers that recognise them.

Adopting a standard that no other participant uses creates another mapping target rather than interoperability.

7. Must the knowledge outlive the systems that produce it?

The case becomes stronger when identities, provenance, classifications and relationships must remain interpretable across several generations of applications.

Temporary application state creates a weaker longevity argument.

Workload and operational fit

8. What workload must the architecture support?

Separate transaction processing, graph traversal, analytics, semantic exchange, document retrieval and formal reasoning.

A graph model should not be chosen merely because the data contains relationships. The workload should explain why RDF, an LPG, SQL, search or a combination is appropriate.

9. What are the expected scale, change rate and performance requirements?

The assessment should include:

• data volume and growth

• ingestion and update frequency

• query shapes

• expected latency

• concurrent users and processes

• reasoning or validation frequency

• reprocessing requirements

These should be tested against realistic data rather than assumed from the data model.

10. Where does operational authority remain?

Identify the system of record and the lifecycle owner.

When RDF is a projection of operational data, explain how creation, correction, deletion, late events and conflicting updates will be synchronised. Maintaining two representations can be reasonable, but its cost must be visible.

Delivery, governance and economics

11. Does the organisation have the required skills and operating model?

The assessment should cover modelling skills, query expertise, platform support, security, monitoring, incident response and consumer support.

It should also identify a funded owner for ontology, mappings, identifiers, validation and semantic change.

12. Does RDF outperform the simplest credible alternative over the expected lifetime?

Compare RDF with SQL, an LPG, APIs, event contracts, search and application logic where relevant.

The comparison should include:

• platform and licensing costs

• implementation and migration

• source mapping

• synchronisation

• specialist skills

• operational support

• governance

• change and reprocessing

• expected years of use

• measurable benefits

Counting triples, ontology classes or vocabulary terms measures implementation size, not value.

Useful business measures may include fewer custom mappings, faster partner onboarding, fewer identity conflicts, lower integration effort, broader reuse of shared definitions and decisions improved through formal entailment.

Interpreting the result

RDF is more likely to be above break-even when a named external or cross-system capability is required, several consumers will reuse the model, identifiers and vocabularies are genuinely shared, formal semantics affect outcomes, and long-term ownership is funded.

The case is unproven when the benefits depend mainly on future reuse, the workload has not been tested, consumers have not committed or the operating model is unclear. A bounded pilot is more appropriate than an enterprise platform.

RDF is probably below break-even when the problem is local, one application consumes the result, the schema is controlled, no external vocabulary is reused, formal entailment changes no decision and a simpler model can deliver the same outcome at lower total cost.

There is no universal number of yes answers. The strength of the evidence matters more than the count.

8. AI needs trustworthy context, not a preferred syntax

Enterprise AI has made the RDF question more urgent because semantics is increasingly presented as the answer to unreliable agents.

The reasoning often follows another automatic chain:

AI needs context. Context needs semantics. Semantics needs an ontology. Therefore, AI needs RDF.

The conclusion still does not follow automatically.

An enterprise agent needs to know which entity is involved, which facts are current, where the evidence came from, what the user is authorised to see, which policy applies and which action is permitted.

It also needs lifecycle context. A customer may have withdrawn consent. An order may have been cancelled. A policy may have expired. An identity relationship may have been corrected.

RDF can represent these facts and events. It does not automatically select the right evidence, resolve conflicting versions, enforce permissions or prevent an unsafe action.

At decision time, an AI agent gains no safety simply because a fact arrived as an RDF triple. What matters is whether the information is current, relevant, authorised, supported and actionable.

Representation still matters to the surrounding architecture. Parsers, query engines and retrieval services need to understand the format. However, syntax alone does not establish whether the information may be trusted for a particular decision.

In From LPG to GraphRAG: The Minimum Semantic Contract, I described the minimum commitments that a GraphRAG runtime should be allowed to trust [7]. The Missing Half of Enterprise Semantics: What the Agent Must Not Do extended that argument to the restrictions that determine whether an interpretation or action is admissible [8]. The Applied Knowledge Graph as the Runtime Layer for Agentic AI connected graph structure with evidence, policy, tools, state and decision trace [9].

These capabilities may be implemented through RDF, an LPG, relational data, APIs, event streams, policy services, metadata platforms and controlled retrieval pipelines.

RDF can provide durable identifiers, vocabularies and provenance across these components. The operational layer must still retrieve the correct version, apply the right policy, check authorisation and record what happened.

AI can also increase the consequences of semantic change. A new class hierarchy may alter retrieval. A changed identity mapping may merge entities that were previously separate. A new inference rule may expand the set of transactions affected by a policy.

As argued in The Ontology Trap: When AI Scales Unvalidated Meaning, machine-generated ontology content should remain a proposal until it has been reviewed, tested and approved [6].

The more authority an agent receives, the less acceptable it becomes to confuse representable meaning with governed and operationally valid meaning.

9. Summary

RDF is a strong standard for representing and exchanging connected information. It can support shared identifiers, external vocabularies, validation, provenance and formal semantics across systems that do not share one implementation.

That does not make it the natural destination of every semantic initiative.

An ontology is useful when people and systems reuse it. An identifier is durable when somebody governs it. A logically derived conclusion creates value when it changes a real decision. A vocabulary is only shared when independent consumers adopt it.

The same practical test applies to enterprise CRUD. RDF, SPARQL and triplestores can query and modify graph data, but technical update operations are not the complete business lifecycle. Approval, cancellation, correction, retention and legal deletion still require policy, workflow and ownership.

This is not a weakness unique to RDF. No data model supplies the full lifecycle by itself. The distinction matters because representation, operational state and business meaning are different architectural responsibilities.

RDF is most convincing when meaning must cross boundaries, remain reusable and survive the applications that first produced it. In those cases, the cost of ontology design, RDF integration and shared governance may create a durable asset.

When the problem is local, the workload is transactional and one application owns the meaning, a relational model, an LPG, an API or application logic may provide the same result more simply.

The break-even test is therefore not a competition between graph communities. It is a comparison between a required business capability and the complete cost of delivering it.

That cost includes workload fit, scale, performance, mappings, synchronisation, skills, governance, migration and years of operation. The value must include named consumers, reduced integration work, better decisions or knowledge that remains reusable over time.

Enterprise AI does not remove this requirement. Agents need trustworthy context, but trustworthy context is not synonymous with RDF. Information must still be current, authorised, supported by evidence and valid for the proposed action.

The practical conclusion is straightforward. RDF should earn its place in the architecture, just like every other component.

Businesses should ask:

Which capability becomes possible because we chose RDF, who will reuse it, and why can we not achieve the same result more simply elsewhere?

When there is a clear, measurable answer, RDF may be the right investment. When there is no answer, the organisation may not be building semantic maturity. It may simply be paying an ontology tax.

10. References

Previous publications

1. RDF Is a Knowledge Representation Model. LPG Is a Decision Infrastructure
https://sergeyvasiliev.substack.com/p/rdf-is-a-knowledge-representation

2. LPG, PG and RDF: Structural Models, Semantics, and Applied Reality
https://sergeyvasiliev.substack.com/p/lpg-pg-and-rdf-structural-models

3. The Pragmatic Semantic Layer Manifesto
https://sergeyvasiliev.substack.com/p/the-pragmatic-semantic-layer-manifesto

4. The Semantic Layer Naming Crisis
https://sergeyvasiliev.substack.com/p/the-semantic-layer-naming-crisis

5. The RDF Assumption That Meaning Lives in Ontology Is Breaking in the LLM Era
https://sergeyvasiliev.substack.com/p/the-rdf-assumption-that-meaning-lives

6. The Ontology Trap: When AI Scales Unvalidated Meaning
https://sergeyvasiliev.substack.com/p/the-ontology-trap-when-ai-scales

7. From LPG to GraphRAG: The Minimum Semantic Contract
https://sergeyvasiliev.substack.com/p/from-lpg-to-graphrag-the-minimum

8. The Missing Half of Enterprise Semantics: What the Agent Must Not Do
https://sergeyvasiliev.substack.com/p/the-missing-half-of-enterprise-semantics

9. The Applied Knowledge Graph as the Runtime Layer for Agentic AI
https://sergeyvasiliev.substack.com/p/the-applied-knowledge-graph-as-the

External references

10. W3C, RDF 1.1 Concepts and Abstract Syntax
https://www.w3.org/TR/rdf11-concepts/

11. W3C, RDF 1.1 Semantics
https://www.w3.org/TR/rdf11-mt/

12. W3C, OWL 2 Web Ontology Language Primer (Second Edition)
https://www.w3.org/TR/owl2-primer/

13. W3C, Shapes Constraint Language (SHACL)
https://www.w3.org/TR/shacl/

14. W3C, PROV-O: The PROV Ontology
https://www.w3.org/TR/prov-o/

15. W3C, SPARQL 1.1 Query Language
https://www.w3.org/TR/sparql11-query/

16. W3C, SPARQL 1.1 Update
https://www.w3.org/TR/sparql11-update/

1. Introduction: a map without warning signs

2. What Anthropic’s analytics files reveal

3. Defining Negative Semantic Knowledge

4. What Negative Semantic Knowledge is not

5. The typed rule families of Negative Semantic Knowledge

6. Does a Negative Knowledge Graph make sense?

7. Representing Negative Semantic Knowledge in a Labelled Property Graph

8. How an agent should use Negative Semantic Knowledge

9. Extending the Minimum Semantic Contract

10. Conclusion

11. References

1. Introduction: a map without warning signs

Most enterprise semantic models resemble maps that show every road but none of the warning signs.

They describe what exists, what it means and how it is connected. This table represents customers. This field contains a customer identifier. This relationship connects orders to products. This metric calculates active users. This tool performs experiment analysis.

All of that is useful. It is also incomplete.

A real map tells us more than how to reach a destination. It warns us that a bridge cannot carry heavy vehicles, a road is closed after a certain date, or a route crosses a restricted area. The road still exists. It is simply not suitable for every journey.

Enterprise data has the same problem.

Two datasets may contain technically compatible keys, but joining them may produce the wrong level of detail. A metric may be correctly defined for operational monitoring but not approved for financial reporting. A relationship in a graph may be useful for investigation but insufficient as evidence for a compliance decision. A missing record may mean that something did not happen, or simply that the relevant system did not capture it.

Human experts usually know these distinctions.

An experienced analyst knows not to use product telemetry as a source of legal customer identities. A finance specialist knows which revenue table has been approved for external reporting. A compliance specialist knows that a shared address may indicate a connection but does not prove ownership or control.

Much of this knowledge is never represented formally. It remains in people’s heads, review conversations, old tickets, code comments and warnings such as:

We normally do not use that table for this.

That was already a governance problem. Agents make it a production problem.

An agent is not merely reading definitions. It selects sources, resolves identities, joins datasets, follows graph paths, compares metrics and turns evidence into conclusions. In GraphRAG, where graph structure is used to retrieve and assemble context for a language model, these choices determine what the model is allowed to see. In Text2Query, where a natural-language question is converted into SQL, Cypher or another query language, they determine what the system executes.

A query can therefore be syntactically correct and still express the wrong business meaning.

A route can exist without being suitable. A source can be available without being approved. Two metrics can look similar without being validly comparable. Missing evidence can remain unknown rather than becoming a negative conclusion.

Production agents need explicit knowledge of these limits. I call this Negative Semantic Knowledge, or NSK.

This concept continues the argument developed in three of my earlier publications. The Ontology Trap examined the danger of allowing plausible but unvalidated meaning to enter operational systems [9]. Labelled Property Graphs, GraphRAG and Text2Query separated query planning from query generation [10]. From LPG to GraphRAG: The Minimum Semantic Contract defined the smallest set of semantic commitments that a production GraphRAG environment may trust [11].

NSK focuses on the restrictions, qualifications and required conditions within those commitments.

2. What Anthropic’s analytics files reveal

Anthropic’s account of its internal analytics environment provides a useful practical example.

Its reference files do more than describe available tables and columns. They record a table’s grain, scope, exclusions, appropriate uses, inappropriate uses, join keys, required filters and known wrong-answer modes.

Here, grain means what one row represents. One table may contain one row per customer, another one row per order and another one row per product event. A join can be technically possible while still being invalid because those grains have not been reconciled correctly.

Anthropic’s reference-file template explicitly asks authors to record what one row represents, when a table should and should not be used, which joins are available, which filters are required and which mistakes a senior analyst would recognise. That information sits alongside business definitions rather than being treated as unrelated documentation [1].

A simplified example might read as follows:

This table contains product events at event grain. Do not use it to count legal customers. Exclude internal accounts. Do not join it directly to invoices through a device identifier. Use the approved account mapping instead.

This is my illustrative example, not a quotation from Anthropic. It shows the difference between a description and an operational semantic contract.

A conventional catalogue entry might state that a table contains product activity. That makes the table discoverable. It does not tell an agent whether the table is suitable for financial reporting, whether its identifier represents a device or a customer, or whether a particular join will duplicate revenue.

Anthropic reports that, without its analytics skills, Claude’s accuracy on the organisation’s evaluations did not exceed 21 per cent. Adding the skills raised aggregate performance consistently above 95 per cent and regularly to around 99 per cent in some domains [1].

That result should be attributed to the skills as a whole. The skills include structured reference material, routing, analytical procedures and review steps. The published result does not isolate the effect of reference files from the rest of the system. What the example does show is that schemas and raw access were not enough. The agent needed curated business context and procedures for using it.

The same source also describes a maintenance problem. Anthropic observed its offline accuracy falling from about 95 per cent at launch to about 65 per cent over one month as the data environment changed. It responded by keeping skill files with the transformation models and checking whether data-model changes were accompanied by corresponding skill changes. Anthropic reports that roughly 90 per cent of relevant data-model pull requests now include a skill change in the same update [1].

This matters because exclusions and restrictions are not permanent annotations. They change when schemas, metrics, business processes and reporting policies change.

A filter may become compulsory. A source may lose its approved status. An identifier may be replaced. A previously invalid join may become valid after a governed mapping is introduced.

Knowledge about what an agent must not do therefore needs ownership, versioning and maintenance. It cannot safely remain as an old comment copied into a prompt.

3. Defining Negative Semantic Knowledge

Negative Semantic Knowledge is a working term used in this article. I am not presenting it as an established standard, a new logic or a replacement for existing policy and validation languages.

The idea has an important precedent in research on professional expertise.

Researchers use the term negative knowledge to describe knowledge about what is wrong, what should be avoided and which approaches lead to failure in a particular work situation. An experienced professional becomes effective not only by learning more correct actions, but also by recognising plausible wrong turns before taking them [2].

That is close to what experienced data professionals do every day.

A senior analyst knows which table to use. They also know which apparently reasonable alternative will produce a misleading result. They know which join multiplies monetary values, which field only looks like a customer identifier and which operational metric must not appear in a regulatory report.

NSK brings this knowledge into the governed semantic environment.

Negative Semantic Knowledge is explicit, governed and machine-retrievable knowledge that states when an interpretation, data combination, inference or action is prohibited, unsupported or conditional within a defined context.

This is an umbrella concept. It does not turn every restriction into the same kind of semantic rule. Instead, it groups several related rule families while preserving the difference between them.

A rule about the meaning of an identifier is not the same as a rule about access permission. A rule about an invalid join is not the same as a rule requiring human approval. A rule about missing evidence is not the same as a temporal deprecation rule.

They belong to one NSK model because they can all change whether an agent’s proposed plan is acceptable. Their types must remain explicit because different rules have different owners, evaluation methods and enforcement mechanisms.

3.1 Explicit

NSK cannot depend on somebody remembering that a source is “usually wrong for this”.

The restriction must be stated clearly enough for a person or system to evaluate it. It should identify what is restricted, under which conditions, for which purpose and with what expected result.

Compare these two statements:

Be careful with the old customer table.

And:

The legacy customer table is not approved for current regulatory reporting. It remains suitable for reproducing reports issued before 1 January 2025. Current reporting must use the governed legal-customer model.

The first is informal advice. The second can be evaluated.

3.2 Governed

A serious restriction needs an owner and a lifecycle.

The system should know who approved it, when it became active, what evidence supports it, whether an exception exists and which newer rule replaces it.

Governance also applies to changes. An agent may propose a new restriction after detecting a failure pattern, but a generated rule should not become authoritative simply because it sounds sensible. Like any other semantic change, it must be reviewed and approved.

3.3 Machine-retrievable

A rule can be perfectly written and still be operationally useless if the agent cannot find it before acting.

NSK must be connected to the datasets, metrics, identifiers, relationships, question types and decisions that it controls. When a candidate plan selects an asset or path, the relevant restrictions should be retrievable with it.

This does not mean that every rule must be stored in one database. It means the production environment needs a reliable way to locate and evaluate applicable rules before execution.

In this article, runtime means that wider production execution environment. It includes the agent, retrieval services, rule evaluation, query validation, permissions, tools and audit records. It does not mean the language model alone.

3.4 Prohibited, unsupported or conditional

Not every NSK rule says “never”.

Some actions are prohibited:

Do not use product telemetry for audited revenue reporting.

Some conclusions are unsupported:

A shared address is insufficient evidence of company ownership.

Other actions are valid only under stated conditions:

This comparison is allowed only after both metrics are aligned to the same population and time window.

NSK therefore includes direct prohibitions, evidential limits and compulsory preconditions.

A rule written as “always apply this filter” belongs here because it defines every query without that filter as inadmissible.

3.5 Context matters

A rule rarely applies everywhere.

A source may be suitable for exploratory analysis but not approved for a board report. A relationship may be useful for search but insufficient for a customer decision. A legacy metric may be valid for reproducing a historical report but unsuitable for current performance management.

Relevant context can include the question type, intended use, reporting audience, jurisdiction, time period, decision type, user role and required assurance level.

The restriction should be as narrow as the underlying reason allows. A vague global prohibition can block valid work just as easily as a missing rule can allow invalid work.

3.6 A consistent vocabulary

Several terms in this area are often used as if they mean the same thing. In this article, they have distinct meanings.

Valid describes semantic or structural correctness. A join is valid when it preserves the intended grain, cardinality and meaning.

Suitable describes fitness for a particular purpose. A source may be valid within its own domain but unsuitable for a financial report.

Approved describes a governance decision. An approved source or metric has passed the organisation’s defined review process for a stated use.

Authorised describes access permission. An agent may be authorised to read a source without that source being suitable or approved for the current purpose.

Trusted describes what the production environment is allowed to rely on when producing an answer or taking an action.

Admissible describes the result of evaluating a complete candidate plan in context. A plan is admissible only when its interpretations and combinations are valid, its sources are suitable, its governed elements are approved, the user or agent is authorised, and the evidence is trusted for the intended use.

These distinctions prevent technical access, semantic correctness and governance approval from being collapsed into one vague idea of “allowed”.

4. What Negative Semantic Knowledge is not

The boundaries of NSK matter because several neighbouring concepts also use the language of negation, constraints and prohibition.

4.1 NSK is not simply a negative fact

A negative fact describes something that does not hold in the domain:

Company A does not own Company B.

Product X does not contain Ingredient Y.

Customer C did not place an order in June.

An NSK rule describes the permitted use of information:

Do not infer ownership from a shared registered address.

Do not treat missing ingredient information as proof that a product is allergen-free.

Do not infer customer inactivity from the absence of an order in one source system.

The negative fact makes a claim about the world. The NSK rule controls an interpretation, inference or action.

Both can appear in the same knowledge graph. They should not be represented as if they were the same type of statement.

4.2 NSK is not missing information

Knowledge graphs commonly operate under an open-world assumption. Under this assumption, a statement that is not present may simply be unknown. Its absence does not make the statement false.

The OWL 2 Primer contrasts this with the closed-world behaviour commonly associated with databases. In OWL, a missing fact may still be true but unrecorded. OWL also supports explicit negative property assertions, which allow a system to state that a particular relationship is known not to hold [4]. Research on expressive negative statements in open-world knowledge graphs makes the same distinction between absent information and supported negative information [3].

Four states should therefore remain separate.

A positive assertion says that a fact holds.

An explicit negative assertion says that a fact does not hold.

An unknown state means the available knowledge supports neither conclusion.

A validation failure means that information required for a particular operation is missing or malformed.

The last state is not the same as false or unknown. It is the result of applying a requirement.

For example, suppose an agent finds no compliance certificate for a supplier. That may mean the supplier has no certificate. It may also mean the certificate has not been loaded, has expired, exists in an inaccessible system or is hidden from the current user.

If the process requires a current certificate, a validation mechanism can report that the requirement is not satisfied. SHACL, for example, can express required properties and generate a validation result when the minimum required number of values is missing [5]. This still does not prove the negative domain statement that the supplier has never been certified.

NSK tells the agent what it may conclude and what it must do in each state. The result might be “unknown”, “incomplete”, “not applicable”, “requires review” or “block the decision”. It should not automatically become “no”.

4.3 NSK is not access control

Access control asks whether a person or agent is authorised to read a source, call a tool or perform an operation.

NSK asks whether the source, interpretation or operation is suitable for the current purpose.

An analyst may be authorised to access product telemetry. That does not make product telemetry an approved source for audited revenue.

The reverse is also possible. A source may be the approved source for the question, while the current user is not authorised to access it.

A production plan must satisfy both conditions. Semantic suitability cannot replace access control, and access permission cannot establish semantic suitability.

4.4 NSK is not reducible to data quality

A source can be accurate, complete and current within its intended scope while still being unsuitable for another use.

Product telemetry may record device activity correctly. It can pass technical quality checks and remain unsuitable for counting legal customers.

At the same time, the boundary between data quality and NSK is not absolute. Data quality is often assessed relative to an intended use. The W3C Data Quality Vocabulary recognises that a dataset may be considered high quality for one use while different characteristics matter for another [12].

NSK therefore overlaps with contextual data quality, but it adds an operational consequence.

A quality annotation may report that identity coverage is incomplete. An NSK rule can state that a plan using the source to count legal customers is not admissible.

NSK does not replace quality measurement. It converts relevant quality, semantic and governance knowledge into an explicit boundary on agent behaviour.

4.5 NSK is not just another prompt instruction

A prompt can explain a rule and help an agent select a better alternative. It cannot guarantee enforcement.

The model may overlook the instruction, misunderstand its scope or generate a query that accidentally violates it. A serious restriction therefore needs a control outside the model’s discretion.

Anthropic’s guidance on Claude Code distinguishes contextual instructions from hooks that can be triggered at defined lifecycle events. Command, HTTP and MCP tool hooks can execute deterministically, and a pre-tool hook can block a command before it runs [8].

The wider principle applies beyond Claude Code.

Prompt instructions are useful for guidance and explanation. Deterministic validation checks whether the generated operation follows the rule. Permissions and tool configuration prevent prohibited actions from being available.

NSK describes the meaning of the boundary. Other controls enforce it.

5. The typed rule families of Negative Semantic Knowledge

NSK should not become one undifferentiated collection of warnings. Each rule needs a type because the type determines what is being controlled, who owns the rule and how it should be enforced.

These families often work together. A single plan may use a semantically incorrect identity, an invalid join and a source that was never approved for the requested report.

Keeping the types separate avoids turning every problem into a vague “semantic issue”. The domain steward may own the identity definition, data engineering may own the join rule, finance may approve the reporting use, and compliance may define the evidence threshold for a decision.

The final admission result can combine all of these rules without erasing their different responsibilities.

6. Does a Negative Knowledge Graph make sense?

The phrase Negative Knowledge Graph sounds like the natural opposite of an ordinary knowledge graph. It can make sense, but only when its meaning is kept narrow.

In knowledge graph research, an explicit negative statement records that a particular fact is known not to hold. A graph may state that a person did not receive an award, a company does not own another company, or one biological entity does not interact with another [3]. Some recent research has used a separate negative graph to store and learn from statements of this kind [7].

That is different from missing information. Under an open-world assumption, an absent relationship is unknown rather than automatically false. A separate negative graph cannot safely be created by copying every missing triple into it.

It is also different from the negative samples used to train knowledge graph embeddings. These samples are often generated by altering positive triples so that a model can learn to distinguish observed facts from less plausible alternatives. They are training examples, not necessarily verified negative facts [6].

NSK is broader than all three.

An NSK rule may state that a source is unsuitable, a join is invalid, a metric comparison requires alignment, or an inferred relationship is insufficient for a decision. It is not necessarily claiming that a domain fact is false.

Consider the difference:

Person P shares an address with Company C.

This is a positive graph fact.

A shared address must not be treated as proof of company control.

This is an NSK rule about interpretation and evidence.

A separate Negative Knowledge Graph can be useful when explicit negative facts are a major subject of the application. It is not the best default architecture for enterprise NSK.

A restriction needs to remain connected to the asset, metric, relationship, use case, time period and decision it governs. Separating positive meaning and its usage boundaries creates another synchronisation problem.

For enterprise agent systems, the clearer approach is an NSK subgraph within the same semantic environment. The phrase semantic admissibility can then describe the process that evaluates a candidate plan against that subgraph.

7. Representing Negative Semantic Knowledge in a Labelled Property Graph

A Labelled Property Graph (LPG) represents information as nodes, typed relationships, labels and properties. It provides a practical way to keep NSK rules close to the assets and concepts they govern.

The following patterns are conceptual and are not complete executable Cypher statements:

(:Dataset)-[:MUST_NOT_BE_USED_FOR]->(:UseCase)
(:Identifier)-[:MUST_NOT_BE_INTERPRETED_AS]->(:IdentityConcept)
(:QueryPattern)-[:REQUIRES_FILTER]->(:FilterRule)
(:EvidenceType)-[:INSUFFICIENT_FOR]->(:DecisionType)
(:Source)-[:DEPRECATED_FOR]->(:UseCase)

These direct relationships are suitable for simple rules with limited context.

More complex restrictions should become first-class rule nodes. This allows the graph to record the rule type, effect, owner, approval status, validity period, evidence, enforcement mode and exceptions.

(rule:SemanticRule {
    ruleId: "NSK-204",
    ruleType: "STRUCTURAL",
    effect: "REQUIRE",
    enforcementMode: "MANDATORY",
    impact: "HIGH",
    approvalStatus: "APPROVED",
    lifecycleStatus: "ACTIVE"
})

(rule)-[:LEFT_SOURCE]->
    (:Dataset {name: "order_lines"})

(rule)-[:RIGHT_SOURCE]->
    (:Dataset {name: "payment_events"})

(rule)-[:REQUIRES_STEP]->
    (:Transformation {
        name: "aggregate payments to one row per order"
    })

(rule)-[:FOR_USE_CASE]->
    (:UseCase {name: "revenue reporting"})

This model does not say that either source is universally invalid. It states what must happen before their combination becomes valid for a particular use.

Rule nodes are also preferable for symmetric restrictions. If two metrics are not directly comparable, placing the rule on a separate node avoids relying on the direction of one LPG relationship.

Not every warning needs to become a graph object. A practical test is whether the statement could change the selected source, interpretation, join, graph path, filter, tool, answer or action. When it can, it is a reasonable candidate for first-class NSK representation.

8. How an agent should use Negative Semantic Knowledge

NSK must be evaluated before the agent executes a query or calls a tool.

A practical production flow is:

The candidate semantic plan describes how the question could be answered. It identifies the proposed sources, identities, metrics, joins, graph traversals, filters, aggregations and tools. At this stage, the plan is plausible but not yet admissible.

The production environment then retrieves the NSK rules connected to every material part of the plan. It must check combinations as well as individual assets. Two suitable datasets can still form an invalid join. Two approved metrics can still be non-comparable. A path made from trusted relationships can still be insufficient for the intended decision.

Semantic admissibility evaluation brings these findings together. The result may be ADMIT, ADMIT_WITH_REQUIREMENTS, CLARIFY, REVIEW or BLOCK. These are outcomes for the complete plan, not permanent properties of a source.

Only an admitted plan should be converted into SQL, Cypher or a tool call. The generator receives the selected sources together with required filters, permitted joins, metric versions and traversal limits.

The generated operation should then be checked deterministically. Here, deterministic validation means that the same operation and the same rules produce the same result without depending on the language model’s judgement.

For the most serious restrictions, the prohibited source or tool should not be available in that context at all. The production environment should also preserve the decision trace, including the selected plan, matched NSK rules, required changes, rule versions and any approved exception.

This extends the planning model from Labelled Property Graphs, GraphRAG and Text2Query [10]. Query planning identifies a possible route. Semantic admissibility evaluation determines whether that route is acceptable in the current context. Query generation expresses the admitted route in executable form.

9. Extending the Minimum Semantic Contract

NSK is not a replacement for the ideas in my earlier publications. It gives the negative side of those ideas a clearer structure.

9.1 The Ontology Trap

The Ontology Trap: When AI Scales Unvalidated Meaning argued that AI-generated concepts, relationships and definitions should be treated as proposals until they have been validated [9].

The same rule applies to negative knowledge.

An agent can propose that a join is unsafe, a source should be prohibited or a comparison should require additional conditions. Those proposals may be useful. They should not become authoritative restrictions without evidence, ownership and approval.

An incorrect positive relationship can allow a bad plan. An incorrect prohibition can block a valid one.

Both are changes to operational meaning, so both require governance.

9.2 Labelled Property Graphs, GraphRAG and Text2Query

Labelled Property Graphs, GraphRAG and Text2Query separated query planning from query generation [10].

The difficult part is not merely writing valid syntax. The system must choose the correct starting entities, relationship paths, traversal depth, aggregations and temporal filters.

NSK adds semantic admissibility evaluation between planning and generation.

A candidate plan can be coherent while remaining unacceptable. It may use a source that is not approved for the audience, compare incompatible metrics or rely on evidence that is insufficient for the decision.

Planning identifies a possible route. NSK determines whether the complete route is admissible.

9.3 From LPG to GraphRAG: The Minimum Semantic Contract

From LPG to GraphRAG: The Minimum Semantic Contract defined the Minimum Semantic Contract as the smallest validated set of semantic, structural, evidential, temporal, governance and retrieval commitments that an LPG-backed GraphRAG environment may rely on [11].

It already established that not every graph fact, relationship or retrieval path should be trusted equally. It also introduced the need to exclude, qualify, escalate or block unsuitable information.

NSK makes these negative commitments explicit and typed.

A mature Minimum Semantic Contract should define what concepts mean, but also which interpretations are invalid. It should identify approved retrieval paths, but also which paths must not support a particular decision. It should define metrics, but also the conditions under which they are not comparable. It should identify trusted evidence, but also state when absence must remain unknown.

NSK should therefore be understood as part of the Minimum Semantic Contract, not as another architectural layer placed beside it.

10. Conclusion

Enterprise semantics has traditionally concentrated on positive knowledge.

It describes the available datasets, concepts, metrics, relationships and tools. That helps an agent find a possible route to an answer.

Production agents also need governed knowledge of the routes they must not take.

Negative Semantic Knowledge provides a name for that missing body of knowledge. It covers prohibited interpretations, invalid combinations, evidential limits, governance restrictions, procedural preconditions, temporal boundaries and decision-use controls.

NSK is not one new rule language. It is an umbrella for typed restrictions that remain connected to their proper owners and enforcement mechanisms.

It is also not simply a graph of negative facts.

A Negative Knowledge Graph makes sense when the main purpose is to represent explicit statements known not to hold. Enterprise NSK is broader. It governs how positive facts, negative facts, missing information and available tools may be used.

The better architecture is usually an NSK subgraph connected to the same semantic environment as the assets and concepts it controls.

The agent can then propose a plan. The production environment can retrieve the relevant NSK, evaluate semantic admissibility, validate the generated operation and preserve the decision trace.

This does not create an agent that refuses every difficult question.

It creates an agent that can distinguish between an answer that is merely possible and one that is justified for the stated purpose.

Positive semantics explains what the enterprise knows.

Negative Semantic Knowledge defines where the legitimate use of that knowledge ends.

11. References

1. Anthropic, How Anthropic enables self-service data analytics with Claude
   https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

2. Martin Gartmeier, Johannes Bauer, Hans Gruber and Helmut Heid, Negative Knowledge: Understanding Professional Learning and Expertise
   https://link.springer.com/article/10.1007/s12186-008-9006-1

3. Hiba Arnaout, Enriching Open-world Knowledge Graphs with Expressive Negative Statements
   https://publikationen.sulb.uni-saarland.de/handle/20.500.11880/36992

4. W3C, OWL 2 Web Ontology Language Primer, Second Edition
   https://www.w3.org/TR/owl2-primer/

5. W3C, Shapes Constraint Language, SHACL
   https://www.w3.org/TR/shacl/

6. Kian Ahrabian, Aarash Feizi, Yasmin Salehi, William L. Hamilton and Avishek Joey Bose, Structure Aware Negative Sampling in Knowledge Graphs
   https://aclanthology.org/2020.emnlp-main.492/

7. Rita T. Sousa and Heiko Paulheim, Improving Knowledge Graph Embeddings through Contrastive Learning with Negative Statements
   https://arxiv.org/abs/2510.11868

8. Anthropic, Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents
   https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more

9. Sergey Vasiliev, The Ontology Trap: When AI Scales Unvalidated Meaning
   https://sergeyvasiliev.substack.com/p/the-ontology-trap-when-ai-scales

10. Sergey Vasiliev, Labelled Property Graphs, GraphRAG and Text2Query
    https://sergeyvasiliev.substack.com/p/labelled-property-graphs-graphrag

11. Sergey Vasiliev, From LPG to GraphRAG: The Minimum Semantic Contract
    https://sergeyvasiliev.substack.com/p/from-lpg-to-graphrag-the-minimum

12. W3C, Data on the Web Best Practices: Data Quality Vocabulary
    https://www.w3.org/TR/vocab-dqv/

1. From ambiguity to naming crisis

2. Who is it for, what does it sit over, and where is it applied?

3. RDF 1.2 is useful, but it does not own the semantic layer

4. Representation is only part of the job

5. Name the function, not the ambition

6. A practical test for products and designs

7. Summary

1. From ambiguity to naming crisis

In The Pragmatic Semantic Layer Manifesto, I argued that the semantic layer is not one clearly defined piece of technology. Depending on the speaker, it may refer to a governed metrics model, an ontology, a catalogue, a knowledge graph, a query abstraction, a data product contract or a service that supplies context to an AI agent.

All of these deal with shared definitions or context, but they do not perform the same job. They serve different users, sit in different parts of a system and require different forms of ownership and support.

Since then, the problem has moved beyond ordinary ambiguity. The term is now applied so widely that it often reveals almost nothing about the product or component carrying it.

The semantic layer appears to have stopped being an architecture term and become a universal vendor spell. Once those two words appear in a product announcement, metrics become consistent, data becomes trustworthy, governance starts enforcing itself, lineage appears and AI agents finally stop making things up. Apparently, most enterprise problems were waiting for the correct capitalisation.

The joke works because the inflation of the term has practical consequences. A vendor claiming to provide a semantic layer may be offering governed metrics and SQL or SPARQL generation, an ontology management tool, entity matching across systems, a metadata catalogue, a graph platform or a service that supplies evidence and policy context to an AI agent.

Several of those functions may exist in the same platform, and each can be useful. Yet the label alone no longer tells us what has been implemented, which decisions the product makes or how it affects real work.

Useful architecture terms normally create expectations. They help us understand what a component owns, where its boundaries lie, how other systems use it and what happens when it fails. Once one name can cover almost any product concerned with data, context or business language, it no longer provides that clarity.

This is the naming crisis considered here. The problem is not simply that people disagree about one precise definition, but that the term can now survive almost any definition at all.

2. Who is it for, what does it sit over, and where is it applied?

Before discussing products or standards, three questions help reveal what a proposed semantic layer is actually expected to do: who uses the shared definitions, what does the service sit over, and where are those definitions applied?

For a business analyst, the main goal may be consistent reporting. Terms such as “net revenue”, “active customer” or “renewal rate” need to resolve to approved calculations, dimensions and joins whenever a report or query is produced.

An integration team may face a different problem. Its work could involve mapping the same customer, product or contract across applications, aligning vocabulary between systems and managing the effects of changing source structures. Here the focus is identity, mapping and controlled change rather than analytical calculation.

Inside an AI agent’s operating environment, shared definitions may need to influence decisions directly. The agent may have to identify the authoritative source for a task, check whether information is current, respect the user’s permissions and determine whether a proposed action requires approval.

Although all three cases involve semantics, they call for different designs, interfaces and operating practices. A model used to generate SQL is not maintained in the same way as an identity service, while a catalogue used for discovery has a different role from a policy check placed inside an application’s execution path.

What the service sits over also changes the task. Above a data warehouse, it may hide joins and expose approved measures. Across data products, it may align identities and contracts. Over a knowledge graph, it may provide connected facts and paths that several applications can reuse.

The third question, where the definitions are applied, separates documentation from control. A catalogue may explain how a metric should be calculated without ensuring that a dashboard uses that calculation. Similarly, a graph may record which policy applies to an action without placing the policy check into the system that carries out the action.

Descriptive tools can still be valuable. Glossaries, catalogues and conceptual models may improve discovery, ownership and communication even when they do not control application behaviour. Problems begin when a descriptive product is presented as if it governs every query, decision and action in the organisation.

From a practitioner’s point of view, the important distinction is therefore not whether a vendor uses the phrase “semantic layer”. It is whether the product supplies definitions, applies them during query or application execution, or does both.

3. RDF 1.2 is useful, but it does not own the semantic layer

Renewed interest in semantic layers may look like a late victory for RDF and the Semantic Web. The market is again discussing shared concepts, machine-readable relationships, connected context and reusable models, all of which sound familiar to people who have worked with RDF for many years.

The language is familiar, but that does not mean the underlying systems have converged on RDF.

RDF 1.2 contains worthwhile improvements. In particular, its support for triple terms and updated reification makes it easier to describe statements themselves, including who made a claim, where it came from and what other information is attached to it. A graph can record that a person or system made a claim without automatically treating the claim as true, which is useful when sources disagree or when information needs to be traced back to its origin. (W3C RDF 1.2 Concepts and Abstract Syntax)

These changes can improve provenance, exchange and statement-level context. They deserve to be assessed on those terms.

They do not provide a complete enterprise operating model, nor do the RDF specifications claim that they do. RDF 1.2 defines a standard way to represent and interpret information, while concerns such as metric ownership, source mappings, approval processes, policy enforcement and application integration remain matters for the organisations and systems using it.

Confusing those two levels creates the problem. A standard can make claims and annotations easier to exchange without deciding which department owns a definition, which source should be used in a particular process or whether an AI agent may carry out a proposed action.

At the time of writing, the core RDF 1.2 documents are still at the W3C Candidate Recommendation stage rather than being final Recommendations. That is a normal part of standards development, but it also makes any declaration of a completed market victory premature.

More importantly, the growing use of the phrase “semantic layer” tells us very little about RDF adoption. Analytics products already use the label for governed metric definitions, automated joins and SQL generation. The dbt Semantic Layer, for example, is publicly described through MetricFlow, centralised metrics and query generation rather than through RDF.

A product can therefore adopt the name without adopting RDF, just as an organisation can use RDF without calling the result a semantic layer. Counting appearances of the word “semantic” in product marketing is not a useful measure of standards success.

Nor does this need to become another contest between RDF and Labelled Property Graphs, LPG. LPG may be practical when an application relies heavily on relationship properties, graph traversal and changing operational state. RDF may be the stronger fit where standardised exchange, global identifiers and formal interpretation are more important.

Relational models remain effective for metrics and transactions, while documents continue to matter when context depends on clauses, explanations or human language. Serious systems often combine several of these approaches because they are solving several different problems.

RDF 1.2 should be judged through working implementations, interoperability, portability, tooling and successful use in production. A marketing trend may create attention, but it does not prove adoption.

4. Representation is only part of the job

A persistent mistake in semantic projects is to assume that representing a fact is the same as putting that fact to work.

A model can record who owns a metric, which policy applies to an action and which source is considered authoritative. Those records become operationally useful only when reports, applications and AI agents consult them at the appropriate point and respond in a predictable way.

In analytics, an approved revenue definition creates limited value when delivery teams continue to build local calculations in dashboards and spreadsheets. Value appears when query tools reuse the approved logic, changes are distributed in a controlled way and users can see which definition produced a result.

The same principle applies to AI agents. An ontology might define an authoritative source, while a graph connects that source to a customer, policy and decision. Additional application logic is still required to select the right evidence, check permissions, handle exceptions and record what the agent did.

Putting shared definitions into practice therefore requires more than a model. Someone must decide which source or definition takes priority in a given context, and mappings must connect business concepts to tables, APIs, documents and application objects. Version control is also essential because policies, calculations and source structures change over time.

Governance determines who may approve, alter or retire those definitions. Security determines how permissions on conceptual objects relate to permissions on the underlying data. Production support covers deployment, monitoring, testing and recovery, especially when other systems depend on the service during query or application execution.

Change exposes whether these arrangements are real. When a source field is renamed, the organisation needs to know which mappings, reports and applications are affected. When a policy is replaced, teams must understand which processes should use the new version and how past decisions will remain explainable.

Adoption presents another test. A shared service that is harder to use than the underlying data will be bypassed, particularly when teams are under delivery pressure. Good interfaces, documentation, ownership and support matter as much as the elegance of the model.

The practical distinction is between recording agreed definitions and making those definitions influence real queries, decisions and actions. Both can be useful, but they should not be presented as the same achievement.

5. Name the function, not the ambition

Solving the naming crisis does not require a new universal taxonomy. Creating eight more kinds of semantic layer would simply provide future conference speakers with more boxes to rearrange.

A more useful method is to name a component through its domain, its main function and the point at which it is used. The examples below are working descriptions, not proposed standards or established industry categories.

A team governing measures, dimensions, joins and calculation rules might reasonably call its service an analytics metrics layer. That description tells a reader more than the generic phrase because it points to analytical consistency and query generation.

Where the main task is to align concepts, identifiers and schemas across applications, semantic integration service may be a clearer description. Its success would be visible in reduced mapping duplication, more reliable entity matching and better control over source changes.

An Enterprise Knowledge Graph, EKG, can remain an appropriate name when the system connects reusable entities, facts and relationships across domains. The term does not guarantee good governance or successful adoption, but it gives the reader a clearer idea of what is being built.

For an AI agent, a team might use the working description agent context and control service when the component selects evidence, applies permissions, supplies workflow state and restricts available actions. Calling it a service rather than assuming it is always a layer also leaves room for a more honest technical design.

Other products do not need a new label. An ontology can remain an ontology, a metadata catalogue can remain a catalogue and a graph database can remain a graph database. None becomes more useful simply because “semantic” is placed in front of its name.

Clearer descriptions also reduce procurement risk. A buyer seeking consistent metrics should not discover halfway through a programme that the product mainly supports conceptual modelling. A team seeking controls for AI agents should not receive a catalogue, a search interface and a prompt template, while an organisation purchasing a graph platform should not assume that identity, provenance and governance arrive automatically with the database licence.

Platforms may combine several of these functions, and that can be a sensible design. The provider should still explain which parts are included, how they interact and where each boundary lies, rather than leaving the buyer to imagine that one impressive label covers everything.

6. A practical test for products and designs

When a product is described as a semantic layer, the most useful question is not whether it stores definitions, but what happens when those definitions meet disagreement, change and real use.

Begin with a conflict. Give two departments different definitions of the same business term, then ask the provider to show how the system identifies the disagreement and determines which definition applies. A credible demonstration should also reveal whether both versions can remain valid in different contexts, who may approve them and how reports or applications choose between them.

Next, introduce change by modifying a source field, replacing a policy or changing the effective date of a metric. The product should show which mappings, reports, models and processes are affected, rather than providing only a screen where someone can edit the definition.

Finally, follow one result back through the system. It should be possible to identify the definition and version that were used, the evidence that supported the result and the person or team that owned the relevant decision. When the result led to an action, the trace should also show which permissions or policies were checked.

These exercises test authority, change management and explainability. They reveal far more than a feature list because they show whether the product participates in real work or simply presents related metadata.

Two further questions expose the technical boundary. What happens when the service is unavailable, and can the definitions, mappings and policies be exported in a form that remains useful elsewhere? The first question shows whether other systems depend on it during normal operation, while the second reveals how tightly the organisation is tied to one platform.

Internal projects deserve the same scrutiny. Teams should be able to explain who maintains the service, how changes are reviewed, which consumers rely on it and what outcome has improved since it was introduced.

Depending on the purpose, success might mean fewer disputes between reports, faster integration of new sources, more consistent policy checks, safer AI agent actions or clearer explanations of automated decisions. The measure should follow from the job the component is meant to perform.

When the response to these questions returns to a glowing box labelled “Semantic Layer”, the label is still doing more work than the system.

Summary

The phrase “semantic layer” is becoming too broad to function as a useful architecture term. Vendors now use it for metric models, metadata, ontologies, knowledge graphs, integration services, AI context and application controls, even though these products serve different users and influence systems in different ways.

A practical assessment should begin by asking who uses the shared definitions, what the component sits over and where those definitions are applied. The answers show whether the product documents concepts, influences query generation, participates in application execution or combines several of these roles.

RDF 1.2 is valuable standards work, particularly where claims, sources and statement-level context need to be represented and exchanged. However, the wider popularity of semantic layer language does not demonstrate RDF adoption, and a representation standard does not provide ownership, mappings, approval processes or application controls by itself.

Neither RDF nor a Labelled Property Graph automatically creates a complete semantic design. The right choice depends on the problem, the need for interoperability, the systems involved and how the information will be used.

Rather than inventing another universal definition, practitioners should describe each component through its domain, function and point of use. Terms such as analytics metrics layer, semantic integration service or agent context and control service can be useful as working descriptions, provided they are not mistaken for fixed industry categories.

Ultimately, the value of any semantic product lies in what it changes in real work: whether reports agree more often, integration becomes easier, policies are applied consistently and automated decisions can be explained.

1. Introduction

2. Terminology used in this article

3. The flow: LPG → AKG → PSL → MSC

4. Why MVO is the right starting point

5. Why MVO and MVG are not enough for GraphRAG runtime use

6. Defining the Minimum Semantic Contract

7. What the contract must contain

8. Implementing and operating the MSC in an LPG

9. Closing view

10. References

1. Introduction

In previous posts, I described a progression from graph structure to operational semantics, and from operational semantics to semantic control.

The post on when a Labelled Property Graph can legitimately be considered an Applied Knowledge Graph defined the maturity threshold: an LPG becomes an AKG when labels carry domain meaning, relationships encode valid domain interactions, constraints enforce correctness, applications rely on the graph, and system behaviour would degrade if the graph semantics were wrong [1].

The Pragmatic Semantic Layer Manifesto then moved the argument from graph maturity to architectural purpose. It positioned the semantic layer as something broader than metadata or analytics vocabulary. A pragmatic semantic layer must combine meaning, access and control. It must help systems and agents retrieve the right context, follow the right path, apply the right policy and explain what happened afterwards [2].

Other posts filled in adjacent parts of the same argument. GraphRAG was framed as a pipeline, not a single pattern [3]. Token efficiency was positioned as a graph modelling problem, not only a prompt optimisation problem [4]. GraphRAG evaluation was moved beyond answer quality towards retrieval coverage, path faithfulness, provenance completeness, cost, latency and decision usefulness [5]. Ontology work was treated as a source of infrastructure risk when generated structures enter production without validation [6]. Labels, graph summarisation and AKG runtime behaviour were discussed as practical mechanisms for making semantics executable [7], [8], [9].

This post is the next step in that sequence.

The flow is:

LPG → AKG → Pragmatic Semantic Layer → Minimum Semantic Contract for GraphRAG

The new question is not: Can an LPG become an AKG?

That was already addressed.

The new question is: Once an LPG-backed AKG becomes part of a GraphRAG runtime, which semantic commitments is the runtime allowed to trust?

That is the role of the Minimum Semantic Contract.

This argument also connects to external work. The RAG work by Lewis et al. formalised one influential formulation of combining parametric language models with external non-parametric memory for knowledge-intensive language generation [10]. GraphRAG extends retrieval by constructing and using graph structures, communities and summaries for question answering over private corpora [11], [12]. Property graph systems, Neo4j Cypher, openCypher and GQL give the implementation side a stronger standardisation path [14], [15], [16], [17]. W3C standards and publications, including OWL, SHACL, PROV-O, RDF 1.2 and SKOS, give useful reference points for formal meaning, validation, provenance, statement-level metadata and controlled vocabularies [18], [19], [20], [21], [22].

The point of this article is not to replace those traditions.

The point is to define the missing implementation artefact between a Minimum Valuable Ontology and a production GraphRAG capability.

A GraphRAG system should not treat every node, relationship, property, extracted fact, generated summary or inferred link as equally trusted. Professional graph systems contain candidates, drafts, deprecated structures, low-confidence extractions, duplicated entities, old policy versions, disputed evidence and experimental model changes. That is normal.

What is not normal is allowing all of that structure to enter retrieval and generation as if it had the same authority.

The Minimum Semantic Contract defines the smallest explicit set of semantic, structural, evidential, temporal and retrieval commitments that the GraphRAG runtime can rely on.
Small enough to ship.
Explicit enough to test.
Strict enough to trust.
Pragmatic enough to evolve.

2. Terminology used in this article

The following short forms are used consistently throughout the article.

Labelled Property Graph, LPG

A Labelled Property Graph, LPG, is a graph model built from nodes, relationships, labels and properties. Nodes can have one or more labels. Relationships have types. Both nodes and relationships can carry properties.

In this article, LPG refers to the implementation model.

Applied Knowledge Graph, AKG

An Applied Knowledge Graph, AKG, is a knowledge graph used in a real workflow where graph structure, graph semantics, application behaviour and governance are managed together.

In this article, AKG refers to a graph that participates in operational behaviour, not only storage, search or reporting.

Pragmatic Semantic Layer, PSL

A Pragmatic Semantic Layer, PSL, is the combination of meaning, access and control.

It defines the concepts and relationships that matter, makes them usable through queries and retrieval, and governs how they are owned, trusted, versioned, explained and changed.

In this article, PSL refers to the architectural layer that turns semantic structure into operational control.

Minimum Valuable Ontology, MVO

A Minimum Valuable Ontology, MVO, is the smallest set of domain concepts, relationship meanings, constraints and validation expectations that makes a specific workflow meaningfully better.

In this article, MVO means Minimum Valuable Ontology, not Minimum Viable Ontology.

The distinction matters.
Viable means it can exist.
Valuable means it improves work.

The minimum viable ontology and graph pattern is useful as a delivery reference point in enterprise knowledge graph guidance [24]. This article deliberately raises the bar from viable to valuable because GraphRAG runtime trust requires more than the existence of a small ontology slice.

Minimum Valuable Graph, MVG

A Minimum Valuable Graph, MVG, is the smallest connected graph slice, with real instance data and evidence, that proves the value of the MVO in a specific use case.

The MVO defines the minimum useful meaning.
The MVG provides the minimum useful connected evidence.

Retrieval-Augmented Generation, RAG

Retrieval-Augmented Generation, RAG, combines retrieval from external sources with generation by a language model.

In this article, RAG refers to the general retrieval plus generation pattern.

GraphRAG

GraphRAG is graph-based retrieval-augmented generation. It uses graph structure, entities, relationships, paths, communities, summaries, constraints and evidence to improve retrieval and context assembly for generation.

In this article, GraphRAG refers specifically to implementations where graph semantics influence retrieval, context packaging, explanation or answer constraints.

Large Language Model, LLM

A Large Language Model, LLM, is the language model used for interpretation, extraction, summarisation, planning, generation or query construction.

In this article, the LLM is not treated as the source of semantic authority. It is one component in a governed retrieval and generation architecture.

Minimum Semantic Contract, MSC

A Minimum Semantic Contract, MSC, is the smallest validated set of semantic, structural, evidential, temporal, governance and retrieval commitments that an LPG-backed GraphRAG runtime is allowed to rely on.

In this article, MSC is the proposed next implementation artefact after MVO and MVG.

3. The flow: LPG → AKG → PSL → MSC

The sequence matters because each step answers a different question.

LPG answers the representation question

How do we represent entities, relationships, properties and paths in a way that engineers can build, query and evolve?

The LPG gives us labelled nodes, typed relationships, properties and traversals. It is a strong implementation model for domains where relationships matter and where relationship properties such as source, confidence, validity, timestamp, owner, status or weight need to be represented directly.

This is why the LPG model is practical for GraphRAG. It allows domain-specific relationship types and properties to sit close to the retrieval path. The graph does not only store connected entities. It can store why they are connected, when the connection applies, who approved it, which evidence supports it and whether the connection is trusted for runtime use.

However, an LPG is not automatically a knowledge graph. It may be a graph-shaped data store. It may support analytics, navigation or application queries. That alone does not make it semantic infrastructure.

AKG answers the operational question

When does the graph become part of the system’s behaviour?

An LPG becomes an AKG when graph semantics enter the control path. This happens when labels act as domain types, relationship types define valid interactions, constraints enforce correctness, workflows depend on graph patterns and AI systems are grounded or constrained by the graph [1].

In GraphRAG, this point is especially important. If the graph only stores chunks and embeddings, it is infrastructure. If the graph constrains what the LLM may retrieve, cite, infer or say, it becomes part of runtime behaviour.

That shift creates responsibility.

Once the graph influences generated answers, its semantics are no longer optional documentation. They become operational commitments.

PSL answers the architecture question

How do we make agreed meaning usable through access and control?

The Pragmatic Semantic Layer extends the AKG idea into an architectural pattern. Meaning is not enough. A useful semantic layer must also provide access and control [2].

Access means the semantic structure is queryable, traversable, retrievable and usable by applications and agents.

Control means the semantic structure is governed through ownership, policies, evidence, lineage, quality rules, versioning, permissions, change control and audit.

This turns semantics from documentation into infrastructure.

For GraphRAG, this is critical. A semantic layer that cannot guide retrieval is too passive. A semantic layer that cannot preserve evidence is too weak. A semantic layer that cannot express refusal, qualification or escalation is too unsafe for production AI.

MSC answers the runtime trust question

Which semantic commitments can GraphRAG rely on when retrieving, assembling context, generating answers, explaining evidence or blocking unsafe outputs?

This is the next logical step.

An MVO can define the useful concepts and relationship meanings. An MVG can provide the useful connected data. But the GraphRAG runtime still needs to know which parts are trusted enough to influence generation.

The MSC is that boundary.

It says:

• These labels are trusted.

• These relationship types have approved meaning.

• These source-target patterns are valid.

• These properties are mandatory.

• These evidence rules must hold.

• These temporal filters must be applied.

• These retrieval paths are approved.

• These graph facts may enter runtime context.

• These graph facts must remain in review, staging or exclusion.

• The MSC is therefore not a larger ontology.

It is a runtime contract over the part of the semantic layer that GraphRAG is allowed to use.

4. Why MVO is the right starting point

GraphRAG does not usually need a complete enterprise ontology before it delivers value.

It needs a focused semantic slice that is relevant to a real capability.

Examples:

• Which obligations apply to this business process in this jurisdiction?

• Which suppliers create exposure for this active contract?

• Which contractual clauses conflict with the current negotiation playbook?

• Which system dependencies increase the risk of an unresolved vulnerability?

• Which customer commitments are affected by a changed regulatory rule?

These are not abstract questions. They are operational questions.

They do not require every enterprise concept to be fully modelled. They require the concepts and relationships that make the answer reliable.

That is why Minimum Valuable Ontology is the right starting point.

• An MVO should define:

• the domain concepts that matter for the capability

• the relationship meanings that support the workflow

• the constraints that prevent invalid interpretation

• the evidence expectations that make claims traceable

• the temporal and version rules that keep answers current

• the ownership and review rules that make changes governable

The associated MVG should then provide enough connected instance data to test whether the MVO is useful in practice.

For an LPG practitioner, this is a natural delivery pattern.

• Start with a workflow.

• Identify the concepts and relationships that matter.

• Build the graph slice.

• Test it against real questions.

• Expand only where ambiguity, risk or user value justifies expansion.

• The point is not to model less for the sake of speed.

• The point is to model the smallest semantic structure that is valuable enough to use and strict enough to trust.

This is also where ontology engineering practice remains relevant. Classic ontology guidance emphasises scope, intended use, users, maintainers and the questions the ontology should answer [23]. In a GraphRAG setting, those questions become more operational. They are not only competency questions for ontology design. They become release questions for retrieval and generation.

The MVO should therefore be shaped by the real GraphRAG capability, not by an abstract desire for semantic completeness.

5. Why MVO and MVG are not enough for GraphRAG runtime use

MVO and MVG are necessary, but they are not sufficient for production GraphRAG.

The MVO may include meanings that are still being refined.

The MVG may include instance data at different levels of trust.

The graph may contain:

• candidate labels

• unreviewed relationships

• generated mappings

• low-confidence extractions

• duplicate entities

• stale policy versions

• deprecated relationship types

• draft summaries

• conflicting evidence

• experimental retrieval paths

This is not a failure. It is what living graph systems look like.

The problem starts when the GraphRAG runtime treats all of these structures as equally authoritative.

A graph can be useful for exploration while still being unsafe for generation.

A relationship can be interesting during discovery while still being unapproved for runtime retrieval.

A generated summary can be helpful during review while still being too weak to enter a final answer.

A label can exist in the graph while still being excluded from trusted context.

That distinction is essential.

GraphRAG is not only about finding related content. In an LPG-backed implementation, retrieval may return entities, relationship paths, source evidence, graph facts, community summaries, context cards, temporal states and policy constraints. The LLM may then use those elements to produce an answer.

If the retrieved structure is semantically weak, the generated answer can be fluent and still wrong.

For example:

(:Document)-[:MENTIONS]->(:Requirement)

may be enough for search.

It is not enough to answer: Which approved obligation applies to this process as of today?

For that, the runtime needs something closer to:

(:PolicyVersion)-[:CONTAINS]->(:Clause)
(:Clause)-[:CREATES]->(:Obligation)
(:Obligation)-[:APPLIES_TO]->(:BusinessProcess)
(:Obligation)-[:SUPPORTED_BY]->(:Evidence)
(:PolicyVersion)-[:VALID_IN]->(:Jurisdiction)

Even that structure is not enough unless the runtime knows which statuses, evidence rules, dates and relationship properties must be checked.

This is the gap the MSC fills.
The MVO defines the valuable meaning.
The MVG proves the valuable graph slice.
The MSC decides which part of both is trusted enough for GraphRAG runtime use.

6. Defining the Minimum Semantic Contract

A Minimum Semantic Contract is: The smallest validated set of semantic, structural, evidential, temporal, governance and retrieval commitments that an LPG-backed

• GraphRAG runtime is allowed to rely on.

• The MSC is not the entire ontology.

• It is not the entire graph schema.

• It is not all available graph data.

• It is not a prompt instruction.

• It is not a diagram.

• It is the approved runtime subset of the semantic layer.

• A useful distinction is:

MVO: What meanings are valuable for this capability?
MVG: What connected instance data and evidence make those meanings usable?
MSC: Which meanings, structures, facts, paths and evidence rules may GraphRAG trust at runtime?

This changes the design conversation.

Instead of asking only: What should we model?

we also ask: What is the GraphRAG runtime allowed to trust?

Instead of asking only: What can we retrieve?

we also ask: What should be excluded, qualified, escalated or blocked?

Instead of asking only: Did the LLM produce a good answer?

we also ask: Did the answer come from an approved semantic path with sufficient evidence?

This is where semantic modelling becomes runtime engineering.

This distinction is important because RAG evaluation frameworks usually focus on retrieval relevance, faithfulness, answer relevance or context quality [25], [26]. These are useful dimensions, but they do not fully answer the pre-runtime semantic question:

Was the retrieved graph structure trusted enough to be used in the first place?

The MSC sits before the answer.

It defines the semantic boundary that retrieval, generation and evaluation must respect.

7. What the contract must contain

The MSC should be small, but it must not be vague.

A practical way to think about it is as five connected layers.

+----------------------------------------------------------------------+
|                    Minimum Semantic Contract                         |
+----------------------------------------------------------------------+
| 1. Scope layer        What capability is this contract for?          |
| 2. Semantic layer     Which labels and relationships mean enough?    |
| 3. Evidence layer     Which facts are traceable and valid?           |
| 4. Retrieval layer    Which paths and filters may be used?           |
| 5. Runtime layer      What may be answered, qualified or blocked?    |
+----------------------------------------------------------------------+

The contract is not a larger ontology. It is the approved runtime subset of MVO and MVG.

MVO              MVG                  MSC
meaning          connected data       trusted runtime commitments
concepts         instances            approved labels
relations        evidence             approved relationships
constraints      graph facts          approved paths
definitions      source links         approved evidence rules

7.1 Contract content map

The following table shows the main content of the MSC.

+----------------------------+------------------------------------------+
| MSC component              | Runtime question it answers              |
+----------------------------+------------------------------------------+
| Semantic scope             | What can this capability answer?         |
| Trusted labels             | Which node types may retrieval trust?    |
| Relationship semantics     | Which edge types have approved meaning?  |
| Source-target rules        | Which graph patterns are valid?          |
| Identity rules             | Which nodes represent the same thing?    |
| Evidence and provenance    | Where did this fact come from?           |
| Statement metadata         | What is known about this relationship?   |
| Temporal and version rules | When is this fact valid?                 |
| Confidence and review      | Is this fact approved, candidate or old? |
| Retrieval patterns         | Which paths may GraphRAG follow?         |
| Context packaging          | What enters the LLM context?             |
| Refusal and escalation     | When must the system not answer?         |
+----------------------------+------------------------------------------+

This inventory is deliberately implementation-oriented. It does not ask whether the ontology is elegant. It asks whether the runtime can safely depend on the graph.

7.2 Semantic scope and trusted labels

Every MSC starts with a capability boundary.

Trusted labels are then defined inside that boundary.

Capability: Retrieve current policy obligations for business processes.

In scope:

• Policy

• PolicyVersion

• Clause

• Obligation

• BusinessProcess

• Jurisdiction

• Evidence

• SourceDocument

Out of scope:

• Draft policies

• Historical policy analysis before the approved start date

• Unreviewed extracted obligations

• Obligations without source evidence

Jurisdictions not mapped to the controlled jurisdiction catalogue

+--------------------+-------------------+--------------------------------+
| Label group        | Examples          | Runtime treatment              |
+--------------------+-------------------+--------------------------------+
| Trusted            | Policy, Clause,   | May guide retrieval, ranking,  |
|                    | Obligation        | validation and packaging       |
| Candidate          | RiskTheme,        | May support review, not final  |
|                    | ControlGap        | answer generation              |
| Deprecated         | Requirement,      | Excluded from production paths |
|                    | RuleFragment      | unless explicitly mapped       |
+--------------------+-------------------+--------------------------------+

Labels are not only grouping mechanisms in disciplined LPG systems. They are operational type commitments. A trusted label should have a definition, owner, identity rule, required properties and expected runtime behaviour.

Controlled vocabulary practice is useful here. SKOS is a useful reference because it shows how controlled vocabularies, taxonomies and classification schemes can be represented and linked as machine-readable knowledge organisation systems [22]. An LPG implementation does not need to become an RDF SKOS implementation to learn from the principle.

• Terms need identifiers.

• Terms need definitions.

• Terms need ownership.

• Terms need lifecycle status.

• Terms need mappings and aliases.

• Terms need deprecation rules.

Without this discipline, GraphRAG may retrieve over terms that look similar to humans but behave differently in the graph.

7.3 Relationship semantics and source-target rules

Relationship types are one of the strongest semantic instruments in an LPG.

They are also one of the easiest places to create semantic debt.

Weak runtime graph:

(:Document)-[:MENTIONS]->(:Thing)
(:Thing)-[:RELATED_TO]->(:Thing)

Contract-ready graph:

(:PolicyVersion)-[:CONTAINS]->(:Clause)
(:Clause)-[:CREATES]->(:Obligation)
(:Obligation)-[:APPLIES_TO]->(:BusinessProcess)
(:Obligation)-[:SUPPORTED_BY]->(:Evidence)
(:PolicyVersion)-[:VALID_IN]->(:Jurisdiction)

The MSC should define relationship types with operational meaning.

+---------------------+-----------------------+------------------------------+
| Relationship type   | Valid pattern         | Runtime rule                 |
+---------------------+-----------------------+------------------------------+
| IMPOSES_OBLIGATION  | PolicyVersion →       | Allowed only when reviewed   |
|                     | Obligation            | and evidence-backed          |
| APPLIES_TO          | Obligation →          | Allowed only above confidence|
|                     | BusinessProcess       | threshold                    |
| SUPPORTED_BY        | Obligation → Evidence | Required for material claims |
| SUPERSEDES          | Version → Version     | Required for version logic   |
| VALID_IN            | PolicyVersion →       | Required for jurisdictional  |
|                     | Jurisdiction          | filtering                    |
+---------------------+-----------------------+------------------------------+

A relationship type should not be valid between arbitrary node labels.

Valid:

  (:PolicyVersion)-[:IMPOSES_OBLIGATION]->(:Obligation)

Invalid for this capability:

  (:Person)-[:IMPOSES_OBLIGATION]->(:Document)

Source-target rules are particularly important when LLMs or extraction pipelines propose graph structures. Generated graph content often looks plausible because the language is plausible. The MSC must prevent plausible structure from becoming trusted structure without validation.

SHACL is relevant as an external reference because it formalises the idea of validating graph data against shape constraints [19]. An LPG implementation may use different constraint mechanisms, but the principle remains the same.

Trusted graph structure should be validated before runtime use.

7.4 Identity, evidence, provenance and statement metadata

GraphRAG quality depends heavily on entity resolution. If the same policy, product, process, supplier or system appears under several nodes, retrieval becomes fragmented.

+-------------------+-----------------------+------------------------------+
| Entity type       | Identity rule         | Runtime implication          |
+-------------------+-----------------------+------------------------------+
| Policy            | policyId + version    | Prevents version confusion   |
| BusinessProcess   | canonical processId   | Prevents duplicate paths     |
| Jurisdiction      | controlled code       | Prevents free-text filtering |
| Supplier          | supplierId + aliases  | Prevents exposure gaps       |
+-------------------+-----------------------+------------------------------+

Evidence and provenance define why a fact can be trusted.

Direct relationship metadata:

(:PolicyVersion)-[:IMPOSES_OBLIGATION {
  sourceId: "doc-421",
  sourceSpan: "section 4.2",
  confidence: 0.92,
  extractionMethod: "human_reviewed_extraction",
  reviewStatus: "approved"
}]->(:Obligation)

For more complex claims, a reified assertion pattern may be safer.

(:PolicyVersion)-[:CONTAINS_ASSERTION]->(:ObligationAssertion)
(:ObligationAssertion)-[:ASSERTS_OBLIGATION]->(:Obligation)
(:ObligationAssertion)-[:SUPPORTED_BY]->(:Evidence)
(:ObligationAssertion)-[:APPLIES_IN]->(:Jurisdiction)
(:ObligationAssertion)-[:VALID_DURING]->(:ValidityPeriod)

W3C PROV-O is a useful external reference for provenance because it provides a model for representing entities, activities and agents involved in producing information [20]. OpenLineage is also relevant from the data engineering side because it defines a standard approach for collecting lineage events about jobs, runs and datasets [30].

An LPG-based MSC can take the same principle into GraphRAG.

Every material graph fact used in generation should know:

• where it came from

• how it was produced

• when it was observed or extracted

• who or what approved it

• whether it is trusted for runtime use

LPGs are naturally strong at attaching properties to relationships. RDF 1.2 and RDF-star are also relevant reference points because they address statements about statements through quoted triples [21]. The practical lesson is not that GraphRAG must choose RDF or LPG. The lesson is that modern knowledge systems need first-class ways to attach metadata, evidence and lifecycle state to claims.

7.5 Temporal, confidence and review rules

Many GraphRAG failures are temporal failures.

Wrong retrieval: current policy + superseded policy + draft update + old interpretation

Safer retrieval:

• active policy version

• approved obligation

• valid jurisdiction

• correct as-of date

• evidence-backed relationship

The MSC should define temporal semantics explicitly. It should distinguish when a fact becomes applicable, when it stops being applicable, when it was observed, when it was extracted, when it was approved and which version or fact superseded it.

It should also distinguish statuses such as at Figure 7.5

The runtime should know whether a fact can be used directly, used only as background context, shown with a warning, sent for human review or excluded from retrieval.

This is where the practical operating model from earlier ontology validation work becomes important: AI can propose, systems can validate, humans can decide, and the graph should record the decision [6].

Figure 7.5: Temporal, confidence and review rules turn graph facts into authorised, qualified, review-only or excluded GraphRAG context.

7.6 Retrieval, packaging and escalation rules

GraphRAG should not be allowed to traverse everything that is technically reachable.

For an obligation question, the MSC may approve a path like this.

Question type: Which obligations apply to this business process?

Approved retrieval path see at Figure 7.6

Required filters may include:

obligation.reviewStatus = approved
policyVersion.status = active
applies.confidence >= 0.8
jurisdiction = requestedJurisdiction
validFrom <= asOfDate
validTo is null or validTo >= asOfDate

Context packaging should preserve semantic metadata. A prompt-only rule is not enough. Telling the LLM to “use only approved evidence” is useful, but weak if retrieval has already supplied unapproved, obsolete or unsupported facts.

The MSC should also define refusal, qualification and escalation behaviour.

+------------------------------+----------------------------------------+
| Runtime condition            | Behaviour                              |
+------------------------------+----------------------------------------+
| No approved evidence         | Refuse material claim                  |
| Low confidence               | Qualify answer                         |
| Conflicting approved sources | Escalate or present conflict           |
| Missing jurisdiction         | Ask for clarification                  |
| Missing as-of date           | Ask or use declared default            |
| Candidate facts only         | State that no approved knowledge exists|
+------------------------------+----------------------------------------+

The graph should not only help the LLM say more. It should help the system know when not to say too much.

Figure 7.6: Retrieval, packaging and escalation rules restrict GraphRAG to approved paths, authorised context and explicit answer behaviour.

8. Implementing and operating the MSC in an LPG

The MSC should not live only in a document.

It should be represented in a form that systems can query, test and monitor. Depending on the architecture, it may live in a schema registry, graph catalogue, configuration repository, CI test suite, retrieval gateway, application code or the graph itself.

The implementation detail is less important than the principle.

A contract that cannot be checked is only guidance.

8.1 MSC as an executable control plane

The MSC is the control plane between MVO, MVG and the GraphRAG runtime.

It takes the valuable meaning from the MVO, the connected evidence from the MVG, and turns the trusted subset into runtime commitments. Those commitments then drive ingestion validation, retrieval control, query guards, context packaging, generation constraints, monitoring and governed evolution.

Figure 8.1: The Minimum Semantic Contract as the executable control plane between MVO, MVG and GraphRAG runtime behaviour.

8.2 Trust zones in the graph environment

A practical graph programme should not force all graph content into one trust level.

The same graph environment may contain:

• exploration graph: broad extraction, weak structure, discovery relationships

• staging graph: candidate labels, candidate mappings, generated facts

• review graph: structures awaiting human or automated validation

• trusted runtime graph: approved labels, approved relationships, evidence-backed facts

• audit graph: changes, decisions, rejected proposals, lineage, review outcomes

This separation can be physical, logical or property-based.

For example, a relationship may carry:

status: "candidate"
runtimeTrusted: false

and later become:

status: "approved"
runtimeTrusted: true
approvedAt: "2026-07-09"
approvedBy: "policy-governance-team"

This prevents a common GraphRAG failure: The exploration graph becomes the production retrieval graph by accident.

Generated labels, generated relationships, generated summaries and generated mappings should enter the trusted runtime graph only when they pass MSC validation and review rules.

Figure 8.2: Trust zones prevent exploratory or candidate graph content from entering GraphRAG runtime context without MSC validation and review.

8.3 Executable metadata pattern

Part of the MSC can be modelled in the graph itself.

(:SemanticContract {
  contractId: "policy-obligation-graphrag-v1",
  version: "1.0.0",
  status: "active",
  capability: "policy_obligation_retrieval"
})

The contract can then point to specifications.

(:SemanticContract)-[:ALLOWS_LABEL]->(:LabelSpec)
(:SemanticContract)-[:ALLOWS_RELATIONSHIP]->(:RelationshipSpec)
(:SemanticContract)-[:REQUIRES_PROPERTY]->(:PropertySpec)
(:SemanticContract)-[:REQUIRES_EVIDENCE_RULE]->(:EvidenceRule)
(:SemanticContract)-[:REQUIRES_TEMPORAL_RULE]->(:TemporalRule)
(:SemanticContract)-[:APPROVES_RETRIEVAL_TEMPLATE]->(:RetrievalTemplate)
(:SemanticContract)-[:REQUIRES_TEST]->(:ContractTest)

Example label specification:

(:SemanticContract)-[:ALLOWS_LABEL]->(:LabelSpec {
  name: "Obligation",
  owner: "Policy Governance",
  runtimeTrusted: true,
  requiredProperties: ["obligationId", "status", "reviewStatus"]
})

Example relationship specification:

(:SemanticContract)-[:ALLOWS_RELATIONSHIP]->(:RelationshipSpec {
  type: "APPLIES_TO",
  sourceLabel: "Obligation",
  targetLabel: "BusinessProcess",
  requiredProperties: ["confidence", "sourceId", "reviewStatus"],
  runtimeTrustedWhen: "reviewStatus = 'approved' AND confidence >= 0.8"
})

Example retrieval template:

(:SemanticContract)-[:APPROVES_RETRIEVAL_TEMPLATE]->(:RetrievalTemplate {
  name: "active_obligations_for_process",
  questionType: "obligation_lookup",
  version: "1.0.0",
  requiresEvidence: true,
  requiresTemporalFilter: true
})

Some teams will implement this through schema constraints, query templates and validation tests. Others will use graph metadata nodes. Others will combine both. The key requirement is that the MSC is inspectable and enforceable.

Domain owner  → understands the contract
Engineer      → enforces the contract
Retriever     → applies the contract
Auditor       → checks the contract

8.4 Implementation flow from ingestion to answer

The MSC should influence the whole path from source ingestion to answer generation.

A typical flow is presented at Figure 8.5

Typical validation rules include:

• Reject relationship if source-target pattern is invalid.

• Send relationship to staging if confidence is below threshold.

• Require sourceSpan for every extracted obligation.

• Require canonical processId before APPLIES_TO is trusted.

• Reject free-text jurisdiction unless mapped to a controlled node.

• Mark summaries as generated unless reviewed.

This is where SHACL-style thinking is useful even in LPG systems [19]. The implementation may not use SHACL directly, but it should use shape-like validation logic.

Example obligation rule:

Every runtime-trusted Obligation must have:

obligationId
reviewStatus = approved
at least one SUPPORTED_BY relationship
at least one source reference
temporal validity where applicable

Validation failures should be visible as graph quality issues, not hidden inside logs.

Figure 8.4: Implementation flow from ingestion to answer, with MSC validation controlling graph writes, retrieval templates and answer context.

8.5 Retrieval and query control

GraphRAG retrieval should not be an unconstrained graph walk.

A safe implementation pattern is presented at Figure 8.6

For generated Cypher, GQL or other graph queries, the MSC should define:

• which labels can be queried

• which relationship types can be traversed

• which properties can be returned

• which filters are mandatory

• which paths are forbidden

• which result limits apply

• which query shapes require review

• which query shapes must be rejected

A generated query should be treated as a proposal until validated against the contract.

Modern graph query languages and tools make this increasingly practical. Cypher / openCypher / GQL-style query patterns remain familiar to many graph engineers, while ISO GQL provides the standardised property graph query language reference point [15], [16], [17]. GraphRAG libraries can combine vector search with graph traversal, but graph traversal still needs approved semantic boundaries [13].

Figure 8.5: Retrieval and query control validates generated graph queries against MSC-approved labels, paths, filters, limits and trust rules before execution.

8.6 Context packaging and semantic acceptance tests

Retrieval does not finish when the graph query returns rows.

If packaging strips away review status, confidence, validity, source span or path structure, the LLM receives context without the metadata needed to interpret it correctly.

For an obligation answer, the package should include:

• obligation text

• policy version

• clause identifier

• jurisdiction

• validFrom and validTo

• reviewStatus

• confidence

• evidence reference

• source span

• retrieval path

For high-risk answers, the package should include source snippets, unresolved conflicts, missing evidence warnings, temporal limitations and reviewer status.

For low-risk exploratory answers, broader summaries may be allowed, but lower-confidence candidates must be explicitly qualified. Candidate facts must not be stated as approved facts.

Semantic acceptance tests should run before answer evaluation.

Examples:

• Superseded policy found: exclude from current answer context.

• Obligation has no evidence: exclude or report limitation.

• Confidence below threshold: qualify answer.

• Two approved sources differ: escalate or show conflict.

• Generated query violates template: reject or rewrite query.

• Jurisdiction missing: ask for clarification.

RAG evaluation frameworks such as RAGAS and ARES are useful after this point because they assess retrieval and answer quality dimensions such as context relevance, faithfulness and answer relevance [25], [26]. The MSC adds a prior control.

Only semantically authorised context should reach the answer generation stage.

Figure 8.6: Context packaging preserves semantic metadata, while acceptance tests check that graph context is trusted before generation.

8.7 Governance, lineage, monitoring and versioning

The MSC needs owners.

Without ownership, the contract will drift.

Ownership should be assigned for:

• labels

• relationship types

• identity rules

• evidence rules

• retrieval templates

• context packaging rules

• confidence thresholds

• review workflows

• semantic tests

• contract releases

Lineage should be captured for:

• source document

• source version

• extraction run

• model and prompt version

• normalisation rule

• entity resolution decision

• human review decision

• graph write

• summary or embedding generation

• retrieval template version

• answer generation event

This is where data lineage and metadata management patterns become relevant. OpenLineage provides a useful reference for lineage events in data pipelines [30]. DataHub is a useful external example of schema-first metadata modelling and lineage management [31]. Again, the point is not that every GraphRAG system must adopt these tools. The point is that GraphRAG needs equivalent discipline.

After release, monitor semantic drift.

• retrieval failures

• unsupported claims

• deprecated label usage

• duplicate entity growth

• evidence gaps

• relationship type drift

• low-confidence fact usage

• temporal filter failures

• user corrections

• human review overrides

• query rejection rates

• contract test failures

• prompt changes

• model changes

• source schema changes

The MSC should be versioned as a runtime artefact.

policy-obligation-graphrag-v1.0.0
policy-obligation-graphrag-v1.1.0
policy-obligation-graphrag-v2.0.0

An audit should be able to ask:

• Which contract version was active?

• Which retrieval template was used?

• Which labels and relationships were trusted?

• Which evidence rules were required?

• Which temporal filters were applied?

• Which model and prompt produced the answer?

• Which graph snapshot or graph version was queried?

Without versioning, GraphRAG audit becomes guesswork.

With versioning, the MSC becomes part of the answer trace.

Figure 8.7: Governance, lineage, monitoring and versioning keep the Minimum Semantic Contract owned, traceable, auditable and able to evolve.

9. Closing view

The Minimum Semantic Contract is the next logical step after the Pragmatic Semantic Layer.

The progression is:

• LPG: expressive graph structure

• AKG: operationally meaningful graph structure

• PSL: meaning plus access plus control

• MVO: the smallest valuable domain meaning for a capability

• MVG: the smallest valuable connected evidence for that capability

• MSC: the part of that meaning and graph structure that GraphRAG is allowed to trust at runtime

This distinction matters.

A GraphRAG system does not fail only because the LLM hallucinates.

It can fail because the graph contains vague labels, ambiguous relationships, stale facts, weak evidence, unresolved identities, unreviewed extraction, missing temporal validity or traversal paths that were never approved for the question being asked.

The answer may still sound good.

But the structure underneath is not safe.

For technical teams working with LPG, GraphRAG, AI, ontology and semantic layers, the hard question is no longer whether graphs can improve retrieval. They can.

The harder question is: Which graph semantics are trusted enough to enter the runtime?

That is the role of the Minimum Semantic Contract.

A Minimum Valuable Ontology defines the meanings that matter.

A Minimum Valuable Graph proves those meanings against connected data and evidence.

A Minimum Semantic Contract tells GraphRAG which of those meanings, structures, facts, paths and evidence rules it is allowed to rely on.

That is where pragmatic semantics becomes production engineering.

10. References

Previous publications

[1] When a Labelled Property Graph Can Legitimately Be Considered an Applied Knowledge Graph
https://sergeyvasiliev.substack.com/p/when-a-labelled-property-graph-can

[2] The Pragmatic Semantic Layer Manifesto
https://sergeyvasiliev.substack.com/p/the-pragmatic-semantic-layer-manifesto

[3] GraphRAG Is a Pipeline, Not a Pattern
https://sergeyvasiliev.substack.com/p/graphrag-is-a-pipeline-not-a-pattern

[4] Token Efficient GraphRAG with Labelled Property Graphs
https://sergeyvasiliev.substack.com/p/token-efficient-graphrag-with-labelled

[5] Why Most GraphRAG Evaluations Are Wrong
https://sergeyvasiliev.substack.com/p/why-most-graphrag-evaluations-are

[6] The Ontology Trap: When AI Scales Unvalidated Meaning
https://sergeyvasiliev.substack.com/p/the-ontology-trap-when-ai-scales

[7] Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs
https://sergeyvasiliev.substack.com/p/labels-as-the-real-semantic-layer

[8] Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective
https://sergeyvasiliev.substack.com/p/graph-summarisation-is-the-new-retrieval

[9] The Applied Knowledge Graph as the Runtime Layer for Agentic AI
https://sergeyvasiliev.substack.com/p/the-applied-knowledge-graph-as-the

External resources

[10] Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020
https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html

[11] Darren Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization
https://arxiv.org/abs/2404.16130

[12] Microsoft GraphRAG documentation
https://microsoft.github.io/graphrag/

[13] Neo4j GraphRAG documentation
https://neo4j.com/labs/genai-ecosystem/graphrag/

[14] Neo4j Graph Database Concepts: Property Graph Model
https://neo4j.com/docs/getting-started/appendix/graphdb-concepts/

[15] Neo4j Cypher Manual
https://neo4j.com/docs/cypher-manual/current/introduction/

[16] openCypher
https://opencypher.org/

[17] ISO/IEC 39075:2024, Information technology, Database languages, GQL
https://www.iso.org/standard/76120.html

[18] W3C OWL 2 Web Ontology Language Document Overview
https://www.w3.org/TR/owl2-overview/

[19] W3C SHACL, Shapes Constraint Language
https://www.w3.org/TR/shacl/

[20] W3C PROV-O, The PROV Ontology
https://www.w3.org/TR/prov-o/

[21] W3C RDF 1.2 and RDF-star publications
https://www.w3.org/groups/wg/rdf-star/publications/

[22] W3C SKOS, Simple Knowledge Organization System Reference
https://www.w3.org/TR/skos-reference/

[23] Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology
https://protege.stanford.edu/publications/ontology_development/ontology101.pdf

[24] Gartner, How to Build Knowledge Graphs That Enable AI-Driven Enterprise Applications
https://www.gartner.com/en/documents/3985680-how-to-build-knowledge-graphs-that-enable-ai-driven-ente

[25] Shahul Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation
https://arxiv.org/abs/2309.15217

[26] Jon Saad-Falcon et al., ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems
https://aclanthology.org/2024.naacl-long.20/

[27] NIST AI Risk Management Framework 1.0
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[28] NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[29] ISO/IEC 42001:2023, Artificial intelligence management system
https://www.iso.org/standard/42001

[30] OpenLineage
https://openlineage.io/

[31] DataHub Metadata Model
https://docs.datahub.com/docs/metadata-modeling/metadata-model

1. Why this matters now

2. Ontologies were created to make domain meaning explicit

3. The problem: AI can describe meaning without being accountable for it

4. What goes wrong when AI-generated ontology proposals grow without proper human validation

5. Structural hallucination becomes infrastructure risk

6. The hidden cost of AI ontology work

7. Open world and closed world assumptions must be explicit

8. A safer operating model for Applied Knowledge Graphs

9. Conclusion: do not turn plausible structure into infrastructure

1. Why this matters now

Ontologies are moving from the background into the operating layer of AI systems. They are no longer just reference models for search, data integration or semantic publishing. In the agentic web, ontologies can shape how AI agents retrieve information, recognise entities, remember context, select tools, validate outputs and decide what actions are allowed.

The WordLift article on ontologies for the agentic web makes this shift clear: ontologies are becoming runtime structures for agents, not only formal artefacts for interoperability.

That is powerful. It is also risky.

The main risk is not that AI is being used in ontology work. AI can be useful. It can extract terms, suggest relationships, draft definitions, propose mappings and generate examples. In this article, AI mainly refers to LLM-based generation used to propose ontology elements, graph structures or extracted relationships.

The real risk is that AI can generate structure faster than organisations can validate meaning. When that happens, we do not get intelligence at scale. We get confusion at scale.

In this article, an ontology means the conceptual layer: concepts, relationship types, definitions, rules and validation expectations, once approved for use. A Knowledge Graph is the operational layer where entities, facts and relationships are stored, connected and queried. In a property graph implementation, part of the ontology may appear as labels, relationship types, properties, constraints and modelling rules. The Labelled Property Graph (LPG) model is based on nodes, relationships, labels, relationship types, and properties, so these modelling choices directly shape how the graph behaves. See Neo4j’s overview of graph database concepts.

By Applied Knowledge Graph, I mean a knowledge graph built for a real workflow, where the model, data, retrieval logic, application behaviour and governance are managed together. That distinction matters because a conceptual error in the ontology can become a structural error in the graph. A structural error in the graph can become a behavioural error in the application or agent.

2. Ontologies were created to make domain meaning explicit

Ontologies were created to make a shared understanding of a domain explicit and machine-readable. That domain might be products, customers, suppliers, medical concepts, legal obligations, research topics, public services or financial instruments. The ontology defines the things that matter, how they relate, which distinctions are important and which assumptions the system is allowed to make.

This is close to the classic knowledge engineering definition of an ontology as an explicit specification of a conceptualisation, described by Thomas Gruber in A Translation Approach to Portable Ontology Specifications.

In an Applied Knowledge Graph, this is not abstract. The ontology shapes the graph. The graph then shapes search, analytics, recommendations, retrieval, explanations and AI behaviour.

A simple graph pattern can carry serious meaning:

(:Product)-[:HAS_INGREDIENT]->(:Ingredient)
(:Product)-[:BELONGS_TO_CATEGORY]->(:Category)
(:Supplier)-[:HOLDS_CERTIFICATE]->(:Certificate)
(:Customer)-[:GAVE_CONSENT_FOR]->(:Purpose)

These are not just links. They are commitments about the domain. If the structure is wrong, the system’s behaviour will be wrong too.

These examples are deliberately simplified. In real systems, relationships such as consent, certification or compliance often need source, timestamp, status, expiry and evidence.

This becomes even more important in GraphRAG, where extracted entities and relationships can shape what context the model receives and therefore what answer or action follows. Neo4j describes GraphRAG as combining entity and relationship extraction from unstructured text with graph and vector retrieval. Microsoft’s GraphRAG documentation describes GraphRAG as a structured approach to retrieval augmented generation using an LLM-generated knowledge graph.

3. The problem: AI can describe meaning without being accountable for it

Current AI models are very good at language. They can produce fluent definitions, convincing categories and plausible relationships. But producing language about a domain is not the same as providing grounded, accountable domain understanding.

An ontology is meant to reduce ambiguity. An LLM often works by producing a likely answer under ambiguity. An ontology is meant to define meaning. An LLM can imitate the language of meaning. An ontology is meant to support reliable validation and action. An LLM can sound confident even when the structure is wrong.

That gap matters.

AI may suggest that two concepts are the same because their names look similar. It may create a relationship because it sounds natural. It may build a hierarchy because the words imply one. It may generate a category that makes sense linguistically but not operationally.

This is why AI-generated ontology content should be treated as a proposal, not as authority.

4. What goes wrong when AI-generated ontology proposals grow without proper human validation

Unvalidated ontology growth usually does not fail loudly. It degrades the system slowly.

The first problem is duplication. AI may create Customer, Client, Buyer, Purchaser and Account Holder as separate concepts when the organisation needs one concept with aliases. Queries become fragmented. Facts are spread across competing structures.

• The second problem is false precision. AI may create many detailed categories that look useful but serve no real use case. The ontology becomes larger, not better.

• The third problem is false equivalence. AI may merge concepts that sound similar but have different business meaning. A supplier is not always a manufacturer. A product category is not always a compliance category. A substitute product is not always a safe alternative.

• The fourth problem is vague relationships. In a graph, relationship types matter. RELATED_TO may feel flexible, but it often becomes a dumping ground. If CAUSES, DEPENDS_ON, REPLACES, CONTAINS, REQUIRES and IS_SIMILAR_TO are blurred together, the graph loses its explanatory power.

• The fifth problem is missing provenance. If nobody knows where a generated class, relationship, mapping or definition came from, nobody can safely trust, maintain or challenge it. Every generated concept, relationship, mapping or definition should record source, model version, prompt or pipeline, timestamp, confidence, reviewer, approval status and change history. W3C PROV describes provenance as information about entities, activities and people involved in producing data or things, which helps assess quality, reliability and trustworthiness. See the W3C PROV overview.

• The sixth problem is semantic drift. The ontology keeps growing until it no longer reflects the organisation, the domain or the use case.

This is how ontology debt is created. The graph still contains nodes and relationships. The agent still gives answers. The dashboards still run. But the meaning underneath has become unstable.

5. Structural hallucination becomes infrastructure risk

LLM hallucination is often discussed as a chatbot problem: the model gives a wrong answer, the user spots it and the answer is corrected. Structural hallucination is more dangerous in ontology work because the hallucination becomes part of the model or graph structure.

OpenAI describes hallucinations as plausible but false statements generated by language models. Its research also argues that common evaluation methods can reward guessing rather than admitting uncertainty. See OpenAI’s article, Why language models hallucinate.

In ontology work, AI may invent:

• a class that sounds valid but has no real business meaning

• a relationship that sounds useful but has no evidence

• a hierarchy that looks clean but does not match reality

• a definition that is fluent but not accepted by domain experts

• a synonym that collapses two different concepts

• a property that belongs at the wrong level of abstraction

Once this enters the knowledge graph, it becomes reusable. It can affect retrieval, recommendations, reasoning, compliance checks and agent actions.

A wrong answer is a content problem. A wrong ontology element becomes an infrastructure problem once other systems depend on it.

This becomes more serious as AI models improve. The safer claim is not that every new model hallucinates more. The better point is that remaining errors can become harder to spot because they are better written, more complete and more persuasive. That makes validation more important, not less.

6. The hidden cost of AI ontology work

AI changes the economics of ontology creation. It lowers the cost of generating candidates, which can speed up discovery, extraction and documentation. But it does not remove the cost of trust. In many cases, it moves the cost downstream.

The visible cost is easy to see:

• model calls

• prompts

• extraction pipelines

• storage

• initial graph loading

The hidden cost is larger:

• reviewing generated concepts

• resolving duplicates

• checking definitions with domain experts

• testing relationship semantics

• adding provenance

• writing validation rules

• versioning ontology changes

• deprecating old labels and relationships

• migrating old graph structures

• refactoring queries

• managing review backlogs

• resolving ownership disputes

• fixing broken dashboards

• correcting poor retrieval

• running agent regression tests

• explaining wrong agent behaviour

• maintaining a larger and messier model

Cheap ontology creation can become expensive ontology maintenance.

The useful question is not: how many ontology elements did AI generate?

The better question is: how many validated, governed and reusable modelling decisions did we add?

In Applied Knowledge Graph work, speed only matters when the structure can be trusted.

7. Open world and closed world assumptions must be explicit

AI-generated ontology proposals also create a serious problem around open world and closed world assumptions.

In an open world assumption, missing information does not mean false. It means unknown. In a closed world assumption, the system treats the available data as complete for a specific purpose. If required information is missing, the record fails validation or the action is blocked.

This distinction is critical.

If a product has no allergen relationship, does that mean it has no allergens, or that the allergen data is missing?

If a supplier has no compliance certificate in the graph, does that mean the supplier is non-compliant, or that the certificate has not been loaded?

If a customer has no consent flag, does that mean consent is denied, unknown or not required?

An AI model should not silently decide whether missing data means unknown, false, invalid or not applicable. For agents, this is an operational issue. The difference between unknown, false, invalid and not allowed can change the action the system takes.

OWL 2 has open-world semantics, where a missing fact may simply be missing rather than false. See the W3C OWL 2 structural specification. SHACL is commonly used to express validation conditions over RDF data graphs. See the W3C SHACL recommendation.

In RDF and OWL environments, these issues are often handled through formal semantics and validation languages such as SHACL. In property graph databases, equivalent controls usually come from constraints, schema registries, test queries, review workflows and application rules. Neo4j, for example, supports constraints such as key constraints to ensure required properties exist and remain unique for nodes or relationships of a specific type. See Neo4j’s documentation on constraints.

Open world assumptions, closed world assumptions and validation policies must be explicit in the ontology, the graph model, the validation rules and the agent policy.

8. A safer operating model for Applied Knowledge Graphs

The solution is not to ban AI from ontology work. The solution is to put AI in the right part of the workflow.

AI should propose. Systems should validate. Humans should decide. The graph should record the decision.

A practical operating model looks like this.

1. Propose

AI suggests candidate concepts, labels, relationships, properties, definitions, aliases and examples. Every proposal should include evidence.

2. Stage

Generated ontology content should first go into a staging area, not into the production graph. This can be a review graph, a versioned branch or a set of pending change nodes.

3. Validate

The proposal should be checked against:

• naming rules

• approved labels and relationship types

• allowed source and target node patterns

• identity rules

• required properties

• provenance requirements

• duplication checks

• competency questions, meaning test questions the graph must be able to answer

• regression queries

• open world and closed world policies

4. Review

Humans must review meaning. Domain experts review the concepts. Graph practitioners review the structure. Governance owners review risk.

5. Merge

Only approved changes enter production. The merge should record who approved the change, when it was approved, what evidence supported it and which tests passed.

It should also record versioning and deprecation decisions. A new label, relationship type or definition may need to replace an old one. That change has to be managed, not left as another layer of graph debt.

6. Monitor

After release, monitor retrieval quality, graph quality, agent behaviour and user feedback. Ontology validation is not a one-time task. It is an operating discipline.

This treats ontology change as production change. That is the right mindset. If an ontology affects retrieval, memory, recommendations, validation or agent action, then changing the ontology changes the system.

9. Conclusion: do not turn plausible structure into infrastructure

AI-generated ontologies are not the enemy. Unvalidated AI-generated ontology proposals are the problem.

Ontologies were created to make domain meaning clear enough that machines could work with it. But current AI models do not provide grounded, accountable domain understanding on their own. They can generate language, structure and relationships that look convincing. That does not make those structures true.

This is especially important for Applied Knowledge Graphs. A graph is not just a storage layer. It shapes how systems retrieve, connect, explain and act. If the ontology is weak, the graph becomes weak. If the graph becomes weak, the agent becomes unreliable.

The practical rule is simple:

• Use AI to propose.

• Use staging to isolate.

• Use validation to test.

• Use humans to decide.

• Use provenance to explain.

• Use governance to control.

• Use monitoring to improve.

The future of AI and knowledge graphs should not be about generating more structure as quickly as possible. It should be about building trusted structure that can be inspected, tested, maintained and safely used.

Growth without validation is not intelligence at scale.

It is confusion at scale, wrapped in confidence.

1. Introduction

2. Why token efficiency starts with graph modelling

3. Why a Labelled Property Graph fits GraphRAG well

4. Alternatives to LPG and when to use them

5. Modelling the graph for compact retrieval

6. How the LPG changes query-time behaviour

7. Implementation architecture

8. Operating a token efficient GraphRAG pipeline

9. Common anti-patterns

10. Practical design rules

1. Introduction

GraphRAG is usually discussed as a way to improve answer quality. The common argument is that graphs help language models reason over entities, relationships, communities, and source evidence better than plain vector search. That is true, but it is only part of the story.

GraphRAG can also be a query-time token efficiency technique. The trade-off is that a GraphRAG pipeline can cost more during indexing, because it may use LLM calls for extraction, entity resolution, relationship generation, summarisation, and community report generation. The savings come when that graph is reused to reduce the amount of raw text sent to the language model at query time.

In a conventional RAG pipeline, the retriever usually sends chunks of text to the language model. Those chunks may be semantically similar to the query, but they are often repetitive, partially relevant, or missing the connecting facts needed to answer the question. The model then has to spend context window space figuring out which pieces matter.

GraphRAG changes the shape of the retrieval problem. Instead of only asking which chunks are similar to the query, the system can ask which entities, relationships, summaries, optional claims, communities, and evidence paths are needed to answer it.

That difference matters because LLM context is expensive. Every irrelevant chunk, duplicated paragraph, obsolete policy, repeated entity description, or vague summary increases cost and can reduce answer quality. A smaller prompt is not automatically better, but a denser prompt usually is.

A well designed graph gives the retrieval system a control layer. It can decide what should enter the prompt, what should remain in storage, and what should only be retrieved if the answer needs source-level evidence.

Figure 1. GraphRAG pipeline overview. The graph narrows context before the LLM sees source evidence, so the prompt can be built from compact facts, relevant summaries, and selected evidence chunks.

The main idea is simple:

Use the graph to increase useful information per token.

This is where graph modelling becomes central. GraphRAG does not save tokens merely because a graph exists. A badly modelled graph can do the opposite. It can create duplicate nodes, generic relationships, noisy communities, oversized summaries, and broad traversals that pull too much context into the prompt.

A token-efficient GraphRAG system depends on careful modelling. The graph must be designed as part of the retrieval architecture, not as a decorative knowledge layer.

2. Why token efficiency starts with graph modelling

A normal vector RAG system usually starts with text chunks. The system embeds chunks, searches for chunks that are close to the query, then sends the top results to the model.

That approach is simple and often effective. It works especially well when the answer is contained in one or two passages. It becomes less efficient when the answer depends on structure.

Examples include:

• Which policy applies to this product in this region?

• What caused this issue and how was it resolved?

• Which risks recur across several business units?

• What has changed between the old and new process?

• Where the domain requires claim modelling, which claims are supported by which documents?

In these cases, the answer is not just a piece of text. It is a relationship between things.

A graph can represent those relationships directly. It can show that a policy applies to a product, that a procedure resolves an issue, that an optional domain-specific claim is supported by a document, or that several incidents share the same root cause.

This reduces query-time token usage because the system can retrieve the relationship itself before retrieving the surrounding prose.

Compare these two retrieval payloads.

Vector-only retrieval might send:

Five chunks, each 500 to 900 tokens, because all mention login timeout,
OAuth refresh, session expiry, customer complaints, and patch notes.

Graph-based retrieval might send:

Issue: Login timeout
Affected version: Mobile App 4.2
Root cause: OAuth token refresh race condition
Resolution: Patch 4.2.1
Evidence: chunk-184-002, chunk-211-009

The second payload is much smaller. It also gives the model a clearer answer structure.

The graph acts as a compression layer, but only if the model is clear. If the graph contains vague links, duplicate entities, or long copied text in properties, it becomes just another source of noise.

A useful rule is:

The graph should do retrieval work before the LLM does language work.

That means filtering, ranking, resolving, grouping, and compressing should happen before the final prompt is built.

3. Why a Labelled Property Graph fits GraphRAG well

GraphRAG does not require a Labelled Property Graph. This article focuses on implementing the GraphRAG knowledge layer as an LPG because it is a practical fit for application-level traversal, ranking, and context assembly.

A Labelled Property Graph, or LPG, represents information as nodes and relationships. Nodes can have labels, relationships can be directed and typed, and both can have properties.

For GraphRAG, this is a practical fit because it maps well to retrieval behaviour.

A node might represent:

Product
Version
Issue
Procedure
Policy
CustomerSegment
Document
Chunk
Claim, optional and domain-specific
Community
ContextCard

A relationship might represent:

AFFECTS
CAUSED_BY
RESOLVED_BY
APPLIES_TO
SUPPORTED_BY
SUPERSEDES
MENTIONED_IN
CONTAINS_ENTITY

Properties hold compact values:

name
summary
confidence
source_count
valid_from
valid_to
authority_score
token_count
embedding_id
text_ref

An LPG is useful because it lets the retriever follow typed paths.

Figure 2. Why a Labelled Property Graph fits GraphRAG well. Labels, typed relationships, and compact properties help the retriever follow meaningful paths before any broad text retrieval is needed.

This graph fragment is more useful than an unstructured list of semantically similar chunks. It tells the system what kind of information each item represents and how the items are connected.

The key difference is:

Vector RAG asks:
Which chunks are similar to the query?

GraphRAG with an LPG asks:
Which facts, entities, paths, summaries, and evidence are needed to answer the query?

That second question is more precise. It allows the retrieval system to send fewer tokens to the model without losing important context.

LPGs are also flexible. They work well when source data is messy, mixed, and evolving. A GraphRAG system often has to combine prose documents, tickets, logs, product metadata, policies, wiki pages, and structured records. The LPG model can represent all of these without forcing every fact into a rigid table or a pure ontology.

Community and community report terms are common in Microsoft-style GraphRAG, where communities are generated artefacts used for broader, corpus-level search. In an LPG implementation, they can be represented as nodes, stored as external records, or indexed as summary documents. They are implementation-specific artefacts, not mandatory parts of every GraphRAG system.

4. Alternatives to LPG and when to use them

A Labelled Property Graph is not the only way to build GraphRAG. It is often a strong choice, but it is worth understanding the alternatives.

RDF-style knowledge graphs

RDF represents information as triples:

subject, predicate, object

RDF is strong when the domain needs formal semantics, standard vocabularies, interoperability, and linked data. RDF itself provides the triple-based graph model. Ontology and constraint reasoning usually comes through related semantic-web tooling such as RDFS, OWL, SHACL, SPARQL entailment, or application-specific rule layers.

RDF-style knowledge graphs are common in regulated, scientific, public-sector, and semantic web environments.

RDF can be a better fit when:

the organisation already has ontologies,
data must follow shared standards,
reasoning over classes and constraints matters,
interoperability is more important than traversal ergonomics.

The trade-off is that RDF can feel heavier for application developers who mainly need fast retrieval paths, flexible properties, and pragmatic graph updates.

Relational databases

Relational databases are strong when data is structured, transactional, and well normalised. Many GraphRAG systems should use relational data directly instead of asking an LLM to rediscover it.

A relational model can be better when:

facts already exist in tables,
joins are predictable,
transactional consistency matters,
the schema is stable,
reporting and governance are mature.

The trade-off is that relationship-heavy retrieval can become awkward when queries need variable-depth traversal, graph neighbourhoods, or community detection.

Vector-only RAG

Vector-only RAG is simpler and cheaper to start with. It is often the right choice for narrow document question answering, especially when answers are usually found in single passages.

Vector-only RAG can be better when:

the corpus is small,
queries are simple,
source text is well written,
cross-document reasoning is not needed,
low indexing cost matters more than retrieval precision.

The trade-off is that vector search does not explicitly model entities, causality, versioning, ownership, evidence, or validity. Those connections must be inferred at prompt time.

Document stores and search indexes

A document store or search index is useful for keyword search, metadata filtering, and hybrid retrieval. It should not be seen as a competitor to GraphRAG. In many implementations, it works alongside the graph.

This can be better when:

exact keyword matching matters,
metadata filters are important,
documents are the main unit of retrieval,
the system needs simple operational behaviour.

The trade-off is that document search still retrieves text first. It does not naturally provide a compact semantic structure above the documents.

Hypergraphs and event-centric models

Some facts involve more than two entities. For example, an acquisition has an acquirer, target, date, amount, regulator, jurisdiction, and status.

A true hypergraph can connect more than two nodes through a single hyperedge. An LPG does not have true hyperedges. In LPG systems, the usual pattern is to model the event or relation as a node, then connect that node to the participating entities and attributes.

Figure 3. Hypergraph-like event modelling inside an LPG. The event node captures an n-ary fact in one place, while staying within the LPG model of nodes and directed relationships.

This gives a hypergraph-like modelling pattern while keeping the LPG model practical and avoiding overloaded relationships.

The practical view

For many GraphRAG implementations, the best architecture is hybrid:

LPG for entity and relationship retrieval
vector index for semantic chunk search
search index for keyword and metadata filtering
relational sources for trusted structured data
object storage for long text and reports

The LPG should not replace every storage system. It should coordinate retrieval.

5. Modelling the graph for compact retrieval

The most important modelling decision is to design the LPG around retrieval behaviour, not abstract completeness.

It is tempting to extract every entity and every relationship from source documents. That usually creates a graph that is expensive to build and difficult to use. A token efficient graph is more selective. It contains the entities and relationships that help the retriever build better prompts.

A practical GraphRAG LPG usually has three layers.

Figure 4. Modelling the graph for compact retrieval. A retrieval-friendly LPG separates domain concepts, compact summaries, and evidence so the context builder can fetch structured facts first and raw text only when needed.

The domain layer contains the concepts users ask about. This might include products, systems, policies, controls, issues, procedures, risks, customers, suppliers, teams, or decisions.

The evidence layer contains documents, sections, chunks, and sometimes sentences. It exists to ground answers and support citation.

The summary layer contains entity summaries, context cards, and community summaries. It exists to provide compact prompt-ready context. Community summaries may be implemented as LPG nodes, indexed summary documents, or stored reports, depending on the GraphRAG design.

This separation matters because each layer has a different job.

The domain graph represents the system's current interpretation of what is true.
The evidence graph explains where it came from.
The summary graph explains what can be said briefly.

A common mistake is to mix these layers into one noisy graph. When that happens, traversal becomes harder to control. A query about a product may drift into chunks, topics, dates, authors, and generic concepts before finding the answer.

A better design keeps long text out of core graph relationships. Relationships should carry meaning and small ranking signals, not copied paragraphs.

For example, this is useful:

Issue RESOLVED_BY Procedure
properties:
confidence = 0.91
source_count = 7
last_seen = 2025-04-14

This is less useful:

Issue RESOLVED_BY Procedure
description = several paragraphs copied from incident reports

Long evidence should live in chunks or external text storage. The graph should point to it.

Entity resolution is also central. If one product appears as “Mobile App”, “mobile client”, “iOS app”, and “customer app”, the system may create four nodes for one concept. That leads to duplicated relationships, repeated summaries, weaker communities, and larger prompt payloads.

A production graph should use canonical identifiers and aliases:

canonical entity:
Product: Mobile App

aliases:
mobile client
iOS app
Android app
customer app

This is not just data hygiene. It is token control.

The same applies to relationships. Vague relationship types such as RELATED_TO give the retriever little guidance. Typed relationships reduce ambiguity and help match retrieval paths to query intent.

For example:

Diagnostic query: prioritise CAUSED_BY and AFFECTS
Fix query: prioritise RESOLVED_BY and REQUIRES
Policy query: prioritise APPLIES_TO, VALID_DURING, and SUPERSEDES
Evidence query: prioritise SUPPORTED_BY and ASSERTED_IN

The more precisely the graph describes meaning, the less the LLM has to infer from raw text.

6. How the LPG changes query-time behaviour

At query time, the LPG should act as a routing and compression layer.

A token efficient GraphRAG system should not immediately dump graph neighbourhoods into the prompt. It should first classify the query.

Figure 5. How the LPG changes query-time behaviour. Query routing chooses between local graph traversal, community summary retrieval, hybrid retrieval, and structured lookup before the prompt is assembled.

A local question asks about a specific thing:

• What caused this issue?

• Which policy applies to this product?

• Who owns this service?

• How do we fix this failure?

For this type of question, the retriever should resolve the key entity, follow a small number of typed relationships, and collect only the most relevant facts and evidence.

A global question asks about the corpus:

• What are the main themes across these reports?

• Which risks recur across business units?

• What patterns appear in customer complaints?

For this type of question, the retriever should use communities and summaries. In Microsoft-style GraphRAG, these may be community reports produced during indexing. Other implementations may store similar summaries in the graph, a vector index, or a document store. The system should not scan every raw chunk unless the answer needs examples or citations.

A hybrid question combines both:
What are the main authentication risks affecting Mobile App customers?

Here, the system needs a broad view of one topic, but still anchored to specific entities. The LPG can begin with the product, move into related issues and communities, then retrieve selected summaries and evidence.

The prompt should usually be assembled in this order:

1. compact graph facts

2. entity or context-card summaries

3. community summaries where useful

4. selected evidence snippets

5. raw chunks only when necessary

This order is important. Raw chunks are valuable for grounding, but they are token heavy. They should be fetched after the graph has narrowed the search space.

The graph also helps with answer reliability. If a fact has confidence, source count, validity dates, and supporting chunks, the system can avoid presenting obsolete or weakly supported information as current truth.

This is especially useful for domains where time matters:

policies
pricing
service ownership
product versions
incident status
regulatory obligations
supplier contracts

Without explicit validity modelling, the retriever may send old and new facts together. The language model then has to resolve the conflict inside the prompt. That wastes tokens and increases the risk of an incorrect answer.

7. Implementation architecture

A token efficient GraphRAG implementation is usually a hybrid system. The LPG is the control plane, but it works with other stores and indexes.

Figure 6. GraphRAG implementation architecture. The LPG coordinates retrieval, while vector, search, object, cache, and structured stores provide specialised capabilities around it.

The architecture can be broken into several stages.

Ingestion

The ingestion stage parses source material and preserves metadata. It should keep document identifiers, section structure, timestamps, authorship, source system details, permissions, and offsets.

Chunking should be stable. If chunk identifiers change every time a file is processed, caching and incremental updates become harder.

A practical chunk identifier might depend on:

• document ID,

• section path,

• start offset,

• end offset,

• content hash.

Normalisation

Many facts should be handled before any LLM call.

Examples include:

• dates,

• product codes,

• version numbers,

• regions,

• customer identifiers,

• policy IDs,

• ticket IDs,

• service names,

• known aliases.

This reduces extraction cost and improves graph quality. The LLM should not be used to rediscover facts that already exist in structured metadata.

Schema-guided extraction

LLM extraction should be constrained by a schema. The prompt should not ask for every entity and every relationship. It should ask for the labels and relationship types that support retrieval.

For example, a support knowledge base might extract:

Product
Version
Issue
RootCause
Procedure
Policy
CustomerSegment

and relationships such as:

AFFECTS
CAUSED_BY
RESOLVED_BY
APPLIES_TO
SUPPORTED_BY
SUPERSEDES

This keeps the graph smaller, cleaner, and easier to query.

Entity resolution

Entity resolution merges equivalent entities and records aliases. It should combine deterministic rules, existing master data, embedding similarity, and LLM adjudication where necessary.

The important point is to resolve early. If duplicates enter summaries and communities, they become more expensive to remove later.

Graph write and enrichment

The graph write stage should upsert nodes and relationships using stable IDs. It should also attach provenance and calculate ranking signals.

Useful relationship properties include:

confidence
source_count
first_seen
last_seen
authority_score
verified
extraction_method

These properties help the retriever rank facts before prompt construction.

Summary generation

The system should generate compact summaries at different levels.

Useful summary types include:

• entity summary,

• context card,

• community summary,

• community report, in Microsoft-style GraphRAG or similar implementations,

• claim summary, where claim modelling is required.

A context card is especially useful for high-traffic entities. It is a short, prompt-ready representation of what the system usually needs to know about that entity.

Query routing and context building

The query router chooses the cheapest useful retrieval path. It should distinguish local, global, hybrid, structured, and evidence-heavy questions.

The context builder then assembles the prompt under a token budget. It should track how many tokens come from graph facts, summaries, and raw chunks.

The final prompt should be compact, structured, and evidence-aware.

8. Operating a token efficient GraphRAG pipeline

GraphRAG usually costs more to index than simple vector RAG. It may use LLM calls for extraction, entity resolution, relationship generation, summaries, and community reports.

That indexing cost is justified when the graph is reused often, when queries need cross-document reasoning, or when the system must provide grounded answers with clear provenance. Query-time token savings must be weighed against the cost of building and maintaining the graph.

The operational aim is to spend tokens once where they can be reused many times.

That means structured data should be mapped directly into the graph. Product catalogues, service ownership tables, policy metadata, ticket fields, incident records, CRM records, and dependency maps do not need to be rediscovered from prose.

A sensible operating model looks like this:

• Use deterministic processing for known structure.

• Use LLM extraction for genuinely unstructured content.

• Use entity resolution before summary generation.

• Use short summaries for routing.

• Use long evidence only when required.

• Use stable IDs and content hashes for incremental updates.

Incremental updates are particularly important. If one document changes, the system should not rebuild the whole graph. It should update the changed chunks, affected entities, dependent relationships, and related summaries.

Token efficiency also needs measurement. The system should track indexing and query-time token usage separately.

Indexing metrics:

• indexing tokens per document

• extraction input tokens

• extraction output tokens

• duplicate entity rate

• entities per 1,000 source tokens

• relationships per entity

• community report token count

• summary token count

Query metrics:

• query type

• retrieval strategy

• graph context tokens

• summary tokens

• raw chunk tokens

• number of chunks retrieved

• number of relationships retrieved

• total query tokens

• citation coverage

• unsupported claim rate

• answer quality per 1,000 tokens

The best metric is not the lowest token count. It is answer quality per token.

A tiny prompt that misses the answer is not efficient. A dense prompt that contains the right facts, summaries, and evidence is.

9. Common anti-patterns

Extracting everything

A common mistake is to treat graph construction as maximum extraction. The pipeline extracts every noun phrase, weak relationship, organisation, date, system, and topic.

This creates a large graph, but not necessarily a useful one. It increases indexing cost and makes retrieval noisier.

A better approach is to extract only what supports known retrieval patterns.

Using generic relationships

A graph full of RELATED_TO edges is not very helpful. It says that two things are connected, but not how or why.

That pushes the hard work back into the prompt. The LLM has to inspect more context to understand whether a relationship means cause, ownership, dependency, evidence, applicability, or sequence.

Typed relationships reduce token usage because they reduce ambiguity.

Letting duplicate entities survive

Duplicate entities create repeated summaries, split evidence, and fragmented graph neighbourhoods.

This weakens retrieval and increases prompt size. Entity resolution is not a clean-up task to run later. It is part of the core indexing pipeline.

Storing long text inside graph properties

Large text properties on nodes and relationships can make the graph look self-contained, but they often harm retrieval. The system starts pulling long descriptions into the prompt when a short fact would have been enough.

Long text should live in chunks, reports, or object storage. The graph should hold compact summaries and references.

Mixing domain and evidence layers

When documents, chunks, entities, topics, and communities are mixed without clear roles, graph traversal becomes unpredictable.

A query about one issue may drift into many chunks, authors, dates, and generic topics. The result is a large and unfocused prompt.

Separate layers make retrieval easier to control.

Overusing global search

Global search is valuable for corpus-level questions, but it is too expensive for simple local questions.

A question such as “How do we fix this issue?” should not require scanning community reports. It should use a local graph traversal and fetch only the evidence needed.

Ignoring time and validity

Many corpora contain old and new facts side by side. Policies change, ownership changes, procedures change, and product versions become obsolete.

If validity is not modelled, the retriever may send contradictory context to the LLM. The answer then depends on the model resolving conflict from prose, which is both costly and risky.

Rebuilding everything

Rebuilding the full graph after each source update wastes tokens and creates operational instability.

Stable IDs, content hashes, and dependency tracking allow the system to update only what changed.

10. Practical design rules

A Labelled Property Graph can make GraphRAG significantly more token efficient, but only when it is designed for retrieval.

The main rule is:

Every graph element should help the system retrieve less text, better text, or more reliable text.

In practice, this means:

• Use a controlled schema.

• Resolve entities early.

• Use typed relationships.

• Keep graph facts compact.

• Keep long text in evidence storage.

• Model time and validity.

• Generate short context cards for common entities.

• Use communities for global questions.

• Route queries before retrieval.

• Fetch raw chunks last.

• Measure answer quality per token.

The LPG should not try to become a perfect copy of the source corpus. That defeats the purpose. The graph should be a structured, compressed, queryable interpretation of the corpus, with links back to the original evidence.

A good test is to inspect real prompt payloads.

If the prompt contains repeated chunks, vague summaries, obsolete facts, or large graph neighbourhoods that the model has to sort through, the graph is not doing enough work.

If the prompt contains a small set of relevant entities, typed relationships, compact summaries, and selected evidence, the graph is behaving as intended.

For technical teams, the important shift is to treat graph modelling as part of retrieval design. Labels, relationship types, properties, aliases, weights, summaries, and provenance links all influence how many tokens the LLM sees.

In a strong GraphRAG implementation, the LPG becomes the control plane for context. It decides what information is worth paying for. The language model then receives a smaller, cleaner, and more meaningful prompt.

That is where the token savings come from.

1. The semantic layer is moving beyond analytics

2. Autonomous agents need semantic control

3. The semantic layer is not one thing

4. Semantic layer, knowledge layer, knowledge graph, ontology and applied knowledge graph

5. Ontology and knowledge graph language is becoming buzzword language

6. The LPG view: meaning lives in topology, not only in triples

7. The practical value of LPG in semantic architecture

8. Gartner’s MVO and MVG: start small, but make it valuable

9. What the market shift reflects

10. Meaning, access and control

11. The semantic layer as a control layer for autonomous agents

12. A pragmatic semantic stack for agentic systems

13. Design principles for the pragmatic semantic layer

14. How to start without creating an enterprise ontology programme

15. Closing manifesto

The semantic layer has become one of those phrases that everyone uses and almost nobody defines in the same way.

For some people, it is a SQL facade. For others, it is a metrics layer, an ontology, a catalogue, a governance wrapper, a data product contract, a knowledge graph, an AI grounding layer, or a polite name for metadata management.

All of those meanings are valid in their own context. None of them is the whole story.

From a Labelled Property Graph (LPG) practitioner’s point of view, the confusion is sharper. We already model meaning in the graph. Labels, relationship types, properties, paths, constraints, identifiers, provenance, time, confidence, lineage and exceptions are not technical decoration. They express how the business sees the domain.

So when someone says “semantic layer”, the first question should be simple:

Layer over what?

Over tables, to hide joins?
Over metrics, to standardise definitions?
Over data products, to support discovery?
Over a graph, to expose a shared domain model?
Over governance, to control usage?
Over autonomous agents, to ground decisions and actions?

The answer matters because the market is now mixing semantic layer, ontology, knowledge graph, context layer, knowledge layer and applied knowledge graph into a new set of fashionable words.

That may help marketing. It does not help architecture.

My thesis is simple:

In the age of autonomous agents, the semantic layer must move from a descriptive layer into a control layer.

It still needs to define meaning. It still needs to support access. It still needs to make data easier to use. But for agentic systems, that is no longer enough. The semantic layer must also help decide what an agent can retrieve, what it can use, what it can infer, what it can do, what it must explain and what it must escalate.

By autonomous agents, I do not mean uncontrolled systems acting without supervision. I mean software agents that can plan, retrieve, call tools and progress work within explicit semantic, policy and human approval boundaries.

By agentic systems, I mean the broader enterprise environment around those agents: orchestration, tools, workflows, memory, policies, evidence, monitoring, review and audit.

A pragmatic semantic layer is not a product category first. It is an organisational agreement made usable through technology.

It is where agreed meaning becomes accessible, governable and actionable.

A useful external reference point for this shift is Gartner’s note: Rethink Semantic Layers to Support the Future of Analytics and AI.

This manifesto argues for a practical position:

Use ontology where formal alignment is needed.
Use RDF where RDF is the right fit.
Use LPG where business context, relationships, state, time, provenance and decision trace need to become operational.
Use applied knowledge graphs where autonomous agents must act, not merely answer.
Do not buy a semantic layer before agreeing what semantics means in your organisation.

1. The semantic layer is moving beyond analytics

The traditional semantic layer was built for a familiar problem.

Business users wanted to ask questions without knowing every table, column, join and filter underneath. They wanted “net revenue”, “active customer”, “renewal rate”, “product margin” and “risk exposure” to mean the same thing across reports.

That problem has not disappeared.

Enterprises still need consistent metrics. They still need business-friendly names. They still need governed definitions. They still need a layer that hides some of the physical complexity of data platforms.

But the role of the semantic layer is changing.

It is no longer only about making analytics easier for people. It is becoming part of the operating environment for agentic systems.

That changes the expectation.

An analyst may ask for a number. An agent may use that number to recommend an action, open a case, escalate a risk, draft a communication, trigger a workflow, or decide which tool to call next.

That means the semantic layer must answer more than:

“What does this metric mean?”

It must also answer:

Is this the right definition for this context?
Which source is authoritative?
Which version is current?
Which policy applies?
Which user is allowed to see this?
Which action is allowed?
Which evidence supports the answer?
Which decision has already been made?
Which human needs to approve the next step?

Those are not dashboard questions.

They are control questions.

This is why the semantic layer is becoming more strategic. It is moving from a reporting convenience to a foundation for trusted, governed and explainable action.

2. Autonomous agents need semantic control

A human analyst can look at a result and ask whether it makes sense. A human can notice that the wrong customer hierarchy was used. A human can remember that the policy changed last quarter. A human can call the data owner and check whether a field is reliable.

An autonomous agent needs much of that context to be available in the system.

It needs to know where to retrieve information from. It needs to know which path through the data is valid. It needs to know which definition is certified, which policy applies and which action is blocked. It needs to know what has already happened in the current workflow.

In other words, an agent does not only need data access. It needs semantic control.

A classic semantic layer can help an agent translate business language into data logic. That is useful, but not enough. The agent also needs operational context.

Context is the scoped, current and governed information with necessary timestamps needed to make a decision, trace previous decisions or take an action.

This definition matters because context is not just “related information”. A pile of related documents is not context. A list of similar records is not context. A catalogue entry is not context on its own.

For autonomous agents, context must be scoped to the task, current enough to be safe, governed enough to be trusted and timestamped enough to support traceability.

The agent needs state.

For example, is the case open, reviewed, blocked, approved or closed?

It needs evidence.

For example, which document, record, calculation, clause or data point supports the recommendation?

It needs policy.

For example, is the proposed action allowed for this customer, in this region, under this contract, for this user?

It needs decision trace.

For example, which information was used, which tools were called, which checks passed, which checks failed, and who approved the final action?

This is the shift.

The semantic layer for autonomous agents is not only a map of data meaning. It becomes the place where meaning, state, policy, evidence and action meet.

3. The semantic layer is not one thing

We often talk about “the semantic layer” as if there is a single agreed architecture behind the term.

There is not.

In practice, the semantic layer can mean several different things.

It can mean a business view over tables. It can mean a governed metrics layer. It can mean a shared model for dashboards. It can mean a catalogue of business terms. It can mean mappings between data products. It can mean an ontology. It can mean a knowledge graph. It can mean a context layer for autonomous agents.

This is why semantic layer conversations often go wrong. People use the same words while discussing different concerns.

One team may be trying to standardise finance metrics. Another team may be trying to expose data products to business users. Another team may be trying to make policies machine-readable. Another team may be trying to build a graph that agents can use for context and control.

All of these are semantic problems, but they are not the same problem.

A pragmatic semantic layer needs to be clear about its boundary.

• If the layer only gives easier access to data, it is a query interface.

• If it only defines terms, it is documentation.

• If it only records ownership and approval, it is governance metadata.

• If it only connects entities, it is a graph.

• If it only defines concepts, it is ontology work.

• If it supports meaning, access and control together, it becomes a practical semantic layer.

This is the anchor sentence:

The semantic layer is where agreed meaning becomes usable.

That word “usable” is important.

Meaning that cannot be queried is weak.
Meaning that cannot be governed is risky.
Meaning that cannot be explained is not trusted.
Meaning that cannot be used by agents is not ready for the next generation of enterprise systems.

4. Semantic layer, knowledge layer, knowledge graph, ontology and applied knowledge graph

The terms need boundaries because the market is starting to blur them.

A semantic layer makes agreed meaning usable. It connects business terms, metrics, definitions, rules and relationships to the data and systems that implement them.

A knowledge layer is broader. It connects meaning to enterprise context. It brings together data, metadata, business entities, policies, lineage, evidence, ownership, usage, conversations and decisions.

A knowledge graph (KG) is not just connected data. It connects entities, relationships, facts and meaning in a way that can be reused for discovery, retrieval, recommendations, decisions and operational understanding.

An ontology provides formal alignment. It helps define concepts, relationships, constraints, hierarchies and shared vocabulary. Ontology can be extremely useful when precision, interoperability or standardisation matters.

An applied knowledge graph (AKG) is a graph that participates in real work. It is not just a representation of a domain. It supports retrieval, policy checks, workflow state, tool use, decision support, recommendations, approvals and audit.

These are related, but they are not the same thing.

A simple test helps:

If the model tells us what concepts mean, it is doing ontology work.
If it connects entities, relationships, facts and meaning, it is doing KG work.
If it maps business language to usable data, it is doing semantic layer work.
If it connects enterprise context for applications and agents, it is doing knowledge layer work.
If it changes how work is executed, governed or audited, it is becoming an AKG.

This distinction matters because many organisations are trying to buy one thing and expecting it to behave like all five.

That is how disappointment begins.

A semantic layer can help people ask better questions.
A knowledge layer can help systems understand the wider business context.
An AKG can help autonomous agents act in a controlled way.

Those are different levels of maturity.

The danger is pretending that a glossary, ontology, catalogue, metrics layer or graph database automatically provides the full stack.

It does not.

5. Ontology and knowledge graph language is becoming buzzword language

There is a new problem in the market: ontology and knowledge graph language is becoming buzzword language.

This is not only annoying. It is dangerous.

When ontology, knowledge graph, semantic layer, context layer and knowledge layer are used interchangeably, teams stop asking the hard architectural questions.

Is this model conceptual or operational?
Is it used by humans, machines or both?
Is it enforced at runtime?
Does it control access?
Does it guide retrieval?
Does it support agent memory?
Does it capture evidence?
Does it record decisions?
Does it evolve with business change?
Can ordinary engineering teams maintain it?

The problem is not ontology.

The problem is ontology used as a substitute for delivery, adoption and operational accountability.

Ontology is valuable. Conceptual discipline is valuable. Semantic precision is valuable. Standards matter. RDF has a place, and in some domains it is the right choice.

But having a place is not the same as owning the market.

Enterprise teams choose technology under delivery pressure. They care about integration friction, hiring reality, maintainability, governance effort, operational fit, supportability and production accountability.

A model that is formally elegant but expensive to maintain, hard to explain, slow to integrate and dependent on scarce expertise will struggle outside specialist environments.

Pragmatism is not anti-intellectual.

Pragmatism is what architecture looks like after it meets budgets, deadlines, legacy systems, support teams and production accountability.

The market is not rejecting ontology because it is too rigorous. It is rejecting approaches that are too detached from how real systems get built, funded, operated and evolved.

The same criticism applies to knowledge graph language.

Calling something a knowledge graph does not make it useful. Calling something a context graph does not make it contextual. Calling something a semantic layer does not mean the organisation has agreed on meaning.

The label is not the architecture.

6. The LPG view: meaning lives in topology, not only in triples

From an LPG practitioner’s point of view, meaning does not only live in formal statements. It also lives in graph structure.

Meaning lives in labels.
Meaning lives in relationship types.
Meaning lives in direction.
Meaning lives in properties.
Meaning lives in paths.
Meaning lives in constraints.
Meaning lives in identifiers.
Meaning lives in provenance.
Meaning lives in time.
Meaning lives in confidence.
Meaning lives in lineage.
Meaning lives in exceptions.

This is where LPG practice differs from many ontology-first conversations.

In an LPG, a relationship is not just a passive link. It can be an event, obligation, approval, dependency, ownership, evidence connection, policy application or operational state transition.

For example:

(:Customer)-[:HAS_CONTRACT {validFrom, validTo, status}]->(:Contract)

(:Decision)-[:SUPPORTED_BY {confidence, sourceVersion, extractedAt}]->(:Evidence)

(:PolicyCheck)-[:BLOCKED {reason, checkedAt}]->(:ProposedAction)

(:AgentRun)-[:USED_TOOL {status, durationMs, result}]->(:Tool)

Those relationship properties are not technical extras. They carry business meaning.

This is the practical value of LPG in semantic architecture. It allows the semantic model to represent working reality, not only conceptual reality.

A business does not only need to know that customers have contracts. It needs to know which contract, in which version, under which conditions, with which evidence, during which period, reviewed by whom and used in which decision.

That is applied semantics.

This is also why the semantic layer discussion should not be reduced to RDF versus LPG.

The better question is:

Where does meaning need to live for this use case to work?

Sometimes meaning needs to live in an ontology. Sometimes it needs to live in a governed metric. Sometimes it needs to live in a catalogue. Sometimes it needs to live in a graph path. Sometimes it needs to live directly on the relationship between two business objects.

A pragmatic semantic layer should be able to combine those forms of meaning without pretending they are all the same thing.

7. The practical value of LPG in semantic architecture

LPG is useful in semantic architecture because it is close to how business people describe work.

People naturally talk in entities and relationships:

• customer owns account

• contract contains clause

• policy applies to product

• metric depends on source

• case requires review

• decision uses evidence

• agent called tool

• action changed status

That language maps cleanly to nodes and relationships.

The value is not only modelling elegance. The value is operational.

LPGs make it practical to represent rich relationships with properties, trace paths across domains, attach evidence to claims, model time and validity, connect structured and unstructured sources, record agent actions, capture workflow state, support explainable recommendations, find indirect dependencies and make governance traversable.

This is why LPGs are strong candidates for the pragmatic semantic layer.

They give us a way to move from static meaning to working context.

A static definition says what a term means.

A graph path shows how the term is connected to data, rules, evidence and decisions.

A relationship property can show when that connection became valid, who certified it and which exception applies.

That is a big difference.

In agentic systems, this difference becomes even more important. An agent cannot rely only on a definition. It needs to know which path to follow, which state to inspect, which rule to apply and which evidence to bring back.

This is where LPG provides practical semantic value.

It does not only describe the domain. It can become the domain control surface.

By domain control surface, I mean the place where the system checks the current state of the domain before acting. It is where the agent can inspect the customer, contract, policy, evidence, workflow state, previous decision and allowed action before it does anything.

That does not mean every semantic layer should be built only as an LPG. It means LPG should be taken seriously as semantic infrastructure, not treated as a mere implementation detail beneath an ontology.

In LPG practice, the graph can itself be the semantic layer, or a major part of it.

The key is discipline.

Labels must mean something. Relationship types must be intentional. Properties must be governed. Naming must be consistent. Constraints must be applied where correctness matters. The model must be explainable to business users and maintainable by engineering teams.

Flexibility without discipline becomes graph spaghetti.

Discipline without delivery becomes ontology theatre.

The pragmatic path sits between them.

8. Gartner’s MVO and MVG: start small, but make it valuable

Gartner uses the terms Minimum Viable Ontology (MVO) and Minimum Viable Graph (MVG).

I use the same acronyms, but I read them through a delivery lens:

Minimum Valuable Ontology and Minimum Valuable Graph.

This is my practitioner interpretation, not a replacement for Gartner’s wording.

The difference is subtle, but important.

Viable means it can exist.
Valuable means it is worth using.

The practical idea is the same: do not begin by defining the whole enterprise. Define only as many concepts, relationships and instances as are needed to deliver a clear business capability.

This is a direct answer to one of the biggest failures in semantic programmes.

Many organisations try to define an enterprise-wide ontology, taxonomy or schema first. They spend months aligning vocabulary, debating abstractions and designing a model that is meant to satisfy everyone. By the time the model is ready, the business use case has moved, the funding has weakened, or stakeholders have lost patience.

The MVO and MVG approach reverses the direction.

Start with a targeted use case. Identify the minimum concepts required. Identify the minimum relationships required. Identify the minimum evidence and data required. Build the graph and ontology slice that delivers the capability. Test it with users. Expand only when value is proven.

For an LPG practitioner, this is natural.

A useful MVG might model customers, contracts, products, policies, evidence, tasks and decisions for one agentic workflow. It does not need every enterprise concept. It needs the concepts and instances that make that workflow reliable.

A useful MVO might define the controlled terms, relationships and constraints needed for that same workflow. It does not need to settle every philosophical question. It needs enough semantic agreement to prevent confusion and support reuse.

The MVO and MVG should not be treated as two separate waterfall phases. They should evolve together.

The MVO gives just enough shared meaning.
The MVG gives just enough connected instance data.
The use case tests whether both are useful.
The next iteration improves both.

This is where Gartner’s idea becomes very practical.

Use existing standards where they help. Reuse industry ontologies where they fit. Do not start from a blank page. Do not wait for the perfect enterprise model. Iterate from capability to capability.

The best first graph is not the biggest graph.

It is the first graph people trust enough to use.

And for autonomous agents, trust is not abstract. It means the graph helps the agent retrieve the right context, follow the right path, apply the right policy and produce an answer or action that can be inspected afterwards.

9. What the market shift reflects

The Gartner Data and Analytics Summit vendor landscape reflects a wider market shift. Different vendor categories are now converging on the same semantic problem.

Analytics platforms talk about trusted metrics and governed business logic.
Data platforms talk about semantic models close to data.
Catalogue and governance platforms talk about context, lineage, ownership and trust.
Graph platforms talk about connected knowledge and explainable paths.
Agentic AI platforms talk about context, action and control.

These are different entry points into the same business pressure.

Organisations want their data and knowledge to be usable by humans, systems and autonomous agents. They want business language to be consistent. They want access to be simpler. They want governance to be visible. They want outputs to be explainable. They want agents to act safely.

That is why so many categories now use semantic language.

But this also increases confusion.

A metrics layer is valuable, but it is not the whole semantic layer.
A catalogue is valuable, but it is not the whole knowledge layer.
A graph is valuable, but it is not automatically an AKG.
An ontology is valuable, but it is not automatically an operational control plane.
A context product is valuable only if it manages real context, not just related metadata.

The buyer’s job is not to ask:

“Which vendor has a semantic layer?”

The better question is:

Which part of the semantic problem are we trying to solve?

• If the problem is inconsistent metrics, the answer may be a governed analytics semantic layer.

• If the problem is poor data discovery, the answer may be metadata and catalogue context.

• If the problem is autonomous agent control, the answer must include state, policy, evidence, decision trace and relationship-native context.

• If the problem is cross-domain reasoning, the answer probably needs a KG or AKG.

• If the problem is formal alignment, the answer may need ontology.

The market signal is clear: semantic architecture is becoming composite.

There will not be one universal semantic layer that magically solves all concerns. Most enterprises will need several semantic assets that work together.

The real architecture question is how to connect them.

10. Meaning, access and control

A useful semantic layer handles three concerns: meaning, access and control.

Meaning is what things are called and how they relate.

This includes business terms, entities, metrics, relationships, definitions, synonyms, hierarchies, rules and assumptions. Without meaning, users and systems cannot agree on what they are talking about.

Access is how people and systems use that meaning without knowing every physical detail.

This includes query interfaces, APIs, data products, graph traversal, dashboards, search, retrieval tools and agent access patterns. Without access, the semantic model remains a nice document.

Control is how meaning and access are governed.

This includes ownership, certification, policy, quality, lineage, versioning, permissions, evidence, audit and change management. Without control, the semantic layer becomes another ungoverned abstraction.

Most failed semantic layer discussions overemphasise one concern and ignore the others.

If the focus is only access, the result is a nicer query layer.

This helps users get to data, but it does not guarantee that the meaning is agreed or that the answers are safe to use.

If the focus is only meaning, the result is documentation.

This may improve alignment, but it does not help if the definitions are not connected to systems, queries, tools and workflows.

If the focus is only control, the result is governance theatre.

This may create approval processes and stewardship records, but it does not help if the governed meaning is not actually used.

A pragmatic semantic layer needs all three.

For LPG teams, this is a major opportunity.

• The graph can represent meaning.

• The graph can support access through paths and patterns.

• The graph can expose control through policy, provenance, ownership, lineage and evidence.

That is why LPG is not just a storage choice. It can be the structural backbone of the semantic layer.

11. The semantic layer as a control layer for autonomous agents

The biggest change in the age of autonomous agents is that the semantic layer must move into the control path.

This is the difference between a semantic layer that describes and a semantic layer that governs action.

A descriptive semantic layer says:

• Here is the definition of customer.

• Here is the approved revenue metric.

• Here is the table behind the report.

• Here is the business owner.

• Here is the lineage.

A control-oriented semantic layer says:

• This is the customer in scope.

• This is the valid contract at this point in time.

• This is the policy that applies.

• This is the certified metric for this decision.

• This evidence is current.

• This evidence is stale.

• This tool is allowed.

• This action is blocked.

• This decision requires review.

• This outcome must be recorded.

• That is a much stronger role.

For autonomous agents, the semantic layer should not sit at the side as a passive reference. It should help decide what the agent can retrieve, what it can use, what it can do, what it must explain and what it must escalate.

This is where AKGs become important.

An AKG is not simply a KG with a nicer name. It is a KG that participates in work.

It connects domain knowledge to operational objects:

• tasks

• cases

• agent runs

• tool calls

• policy checks

• evidence

• exceptions

• human reviews

• approvals

• decisions

• actions

• outcomes

This gives the agent a structured working memory.

It also gives the organisation an inspection layer.

After an agent has acted, the organisation should be able to ask:

• What did the agent know?

• Which evidence did it use?

• Which policy did it apply?

• Which tool did it call?

• Which decision path did it follow?

• Which human approved the step?

• What changed afterwards?

Without that trace, autonomous agents become difficult to trust.

With that trace, the semantic layer becomes a control layer.

12. A pragmatic semantic stack for agentic systems

The pragmatic semantic layer is not a single platform. It is a stack of responsibilities.

Layer 1: semantic agreement

This layer defines the core language of the domain. It includes business terms, core entity types, important relationships, metric definitions and controlled meanings.

Ontology can be valuable here, especially when the organisation needs formal alignment across teams, systems or external standards.

The mistake is trying to define everything before delivering anything.

Layer 2: data mapping

This layer connects meaning to implementation. It maps terms, entities and metrics to tables, columns, files, APIs, documents, events, data products, dashboards and graph nodes.

This is where many traditional semantic layer products are strong.

For autonomous agents, this layer matters because an agent must know where trusted data lives and how business terms resolve to technical assets.

Layer 3: enterprise knowledge graph

This layer connects the durable knowledge of the organisation. It brings together customers, suppliers, products, contracts, policies, assets, systems, people, documents, reports, risks, controls and data assets.

For an LPG practitioner, this is where business topology becomes visible.

The enterprise stops looking like disconnected tables and starts looking like a connected model of how the organisation works.

Layer 4: applied knowledge graph

This layer connects knowledge to work. It models tasks, cases, evidence, agent runs, tool calls, policy checks, approvals, decisions, exceptions, actions and outcomes.

This is the layer that makes the graph operational.

It is also the layer that makes the semantic layer useful for autonomous agents.

Layer 5: agentic context

This layer gives agents usable context. It combines enterprise knowledge, current conversation, workflow state and decision history.

The agent does not need everything. It needs the right subgraph for the current decision, with the right timestamps, permissions, evidence and policy boundaries.

Layer 6: governance and control

This layer makes the semantic system safe. It manages ownership, certification, access, policy, lineage, provenance, quality, review and audit.

In a graph architecture, governance should be represented as relationships that can be traversed and checked.

Layer 7: consumption

This layer exposes the semantic layer to users and systems. It may include BI tools, applications, APIs, search, agents, operational workflows and data products.

The stack should not be built all at once.

Start with an MVO and MVG around a real business problem. Then expand.

The goal is not to build the most complete semantic architecture on paper.

The goal is to build the smallest semantic architecture that changes the quality of work.

13. Design principles for the pragmatic semantic layer

1. Start with organisational meaning, not tooling

Do not start by asking which semantic layer product to buy.

Start by asking which meanings must be shared, which definitions must be governed and which decisions depend on them.

The best semantic layer is not the one with the most impressive architecture slide. It is the one people trust enough to reuse.

2. Be honest about the boundary

The graph, ontology, BI model, metrics store, catalogue and RDF layer are not automatically the semantic layer.

They may contribute to it. They may implement part of it. They may expose it. But the semantic layer is where agreed meaning becomes usable.

3. Treat relationships as semantic assets

In many domains, the relationship is where the business fact lives.

• Who approved what?

• Which policy applies to which action?

• Which evidence supports which decision?

• Which source produced which value?

• Which exception overrode which rule?

An LPG makes these relationships explicit and useful.

4. Make state visible

Autonomous agents need to know where the work stands.

A case may be open, reviewed, blocked, approved, escalated or closed. A contract may be draft, active, expired or superseded. A recommendation may be proposed, accepted, rejected or overridden.

State should not be hidden in logs or prompts. It should be part of the graph.

5. Attach evidence

A semantic layer should not only answer what something means. It should show why the answer can be trusted.

Important claims should connect to evidence, sources, versions, extraction time, confidence and review status.

This matters because autonomous agents will be judged not only by the answers they produce, but by whether those answers can be inspected.

6. Model time properly

Meaning changes.

Policies change. Contracts change. Product hierarchies change. Metric definitions change. Customer status changes. Evidence becomes stale.

A pragmatic semantic layer must distinguish what is true now from what was true then.

For autonomous agents, this is not optional. Acting on outdated context is one of the fastest ways to create risk.

7. Make governance traversable

Governance should not only live in documents and committees.

It should be possible to traverse from data to owner, from metric to certification, from policy to affected data, from decision to evidence, from agent action to approval and from answer to source.

This is one of the strongest practical arguments for LPG.

8. Use ontology where it helps

Ontology is useful when shared conceptual discipline is needed.

Use it to align terms, define types, manage reference models, support interoperability and reduce ambiguity.

Do not use it as a reason to delay delivery for two years.

9. Use LPG where operational context matters

LPG is valuable when the work depends on rich relationships, properties, traversal, state, change and traceability.

That is why LPG is well suited to semantic layers that support applications, agents, investigations, compliance workflows, recommendations and decision intelligence.

10. Measure reuse and trust

The real test is not whether the semantic layer is elegant.

The test is whether people and systems reuse it.

• Do analysts trust the definitions?

• Do engineers build against the model?

• Do agents retrieve the right context?

• Do governance teams rely on the lineage?

• Do business users accept the answers?

• Do decisions improve?

A semantic layer that is not reused is not a layer. It is shelfware.

14. How to start without creating an enterprise ontology programme

The worst way to start is to declare a multi-year enterprise ontology programme before proving practical value.

The better way is to choose a real workflow where semantic confusion is already expensive.

Good starting points are usually places where people waste time reconciling meaning, checking evidence, asking experts, searching across systems, repeating routine analysis, or reviewing actions manually because the system cannot be trusted.

For example:

• A contract process where agents need clauses, obligations, playbooks, risk rules, approvals and evidence.

• A compliance process where agents need controls, policies, systems, owners, evidence and review outcomes.

• A finance process where agents need filings, figures, time periods, calculations, assumptions and decision trace.

• A customer process where agents need products, entitlements, cases, previous interactions, policies and escalation rules.

Start by modelling the work.

• What are the core entities?

• What are the meaningful relationships?

• Which terms need shared definitions?

• Which data sources are trusted?

• Which policies apply?

• Which evidence matters?

• Which actions are allowed?

• Which actions require human approval?

• Which decisions must be recorded?

Then build the MVO and MVG together.

The MVO defines the minimum set of controlled meanings, relationships and constraints needed to make the workflow reliable. The MVG populates enough instance data to prove that the workflow works in practice.

They should evolve iteratively.

The ontology should be tested against the use case and the available graph. The graph should be populated only with the data needed to support the current capability. If the workflow exposes ambiguity, extend the MVO. If the workflow needs more connected evidence, extend the MVG.

Do not model the whole enterprise.

Model the smallest semantic and graph structure that makes the workflow better.

Then connect the graph to the workflow.

This is where many teams stop too early. They build a model, but they do not put it into use. A pragmatic semantic layer has to be used by people and systems. It must become part of how work happens.

After that, expand carefully.

Add more entities when the workflow needs them. Add more relationships when they improve retrieval or control. Add more ontology when ambiguity creates risk. Add more governance when reuse increases.

The goal is not semantic perfection.

The goal is trusted semantic progress.

15. Closing manifesto

We are trying to buy semantic layers before agreeing what semantics means in our organisations.

That is the root problem.

The market is full of useful products, but the buyer must still do the hard work of deciding what meaning, access and control should look like.

The Pragmatic Semantic Layer Manifesto is simple:

• A semantic layer is not an RDF layer.

• A knowledge graph is not automatically an ontology.

• An ontology is not automatically a runtime.

• A catalogue is not automatically a knowledge layer.

• A metrics layer is not automatically enterprise meaning.

• A graph database is not automatically an AKG.

• A context layer is not automatically context.

• A vendor slide is not an operating model.

• Semantics do not only exist in triples.

In LPG practice, meaning can live in labels, relationship types, properties, paths, constraints, identifiers, provenance, time, confidence, lineage and exceptions.

Ontology is valuable, but ontology is not the whole architecture.

RDF has a place, but it is not the default answer to every enterprise semantic problem.

LPG has practical value because it turns meaning into connected, traversable, inspectable and operational structure.

Gartner’s terms are Minimum Viable Ontology and Minimum Viable Graph. My delivery interpretation is that they must also be minimum valuable: small enough to build, but useful enough to change the quality of work.

For autonomous agents, the semantic layer must become more than a map. It must become part of control.

It must tell the agent what something means, where it comes from, what it is connected to, what state it is in, which policy applies, which evidence supports it, which tool may act, which human must approve and which decision must be recorded.

That is the difference between semantic decoration and semantic infrastructure.

The future semantic layer will not be won by the purest ontology, the biggest catalogue, the cleverest prompt or the most impressive demo.

It will be won by the architecture that people trust enough to reuse and agents can rely on safely.

Model the core concepts.
Define the relationships.
Agree what is governed and what is local.
Make the model queryable.
Make it explainable.
Attach evidence.
Represent time.
Operationalise policy.
Start with an MVO and MVG.
Use LPG where context and decisions matter.
Use ontology where alignment matters.
Choose tooling after the semantics are understood.

Because the best semantic layer is not the one that claims the most.

It is the one that makes agreed meaning usable.

1. A plain definition of a Knowledge Graph

2. Knowledge Graph does not mean one graph standard

3. Why the Labelled Property Graph model is a strong foundation for Knowledge Graphs

4. What makes a Knowledge Graph applied

5. Why agentic systems need a runtime layer

6. The Applied Knowledge Graph as execution substrate

7. State: knowing where the work stands

8. Memory: making context durable and useful

9. Evidence: grounding actions in sources

10. Tool routing: choosing the right capability

11. Policy: turning rules into operational controls

12. Decision traceability: showing what happened and why

13. Health example: a clinical pathway agent

14. Legal example: a contract review agent

15. Benefits of the Applied Knowledge Graph

16. What this means for graph-based retrieval and generation

17. Closing view

1. A plain definition of a Knowledge Graph

A Knowledge Graph (KG) is a structured representation of information that captures relationships, entities, and attributes to provide a comprehensive and interconnected understanding of a subject.

That definition matters because it keeps us focused on the real point.

A KG is not just a database. It is not just a semantic model. It is not just a diagram of concepts. It is a connected model of the things that matter in a domain, how those things relate to each other, and what we know about them.

For an AI system, this is valuable because most professional work is not flat. It is relational.

A patient is connected to observations, diagnoses, medicines, allergies, clinicians, care pathways, and guidelines.

A contract is connected to parties, clauses, obligations, jurisdictions, playbooks, risks, approvals, and negotiation history. A KG gives these connections a structure that machines can query and humans can inspect.

For professionals working in graph, GraphRAG, AI, and agentic flow, this is the starting point. The graph is not only a way to store knowledge. It is a way to organise context for action.

2. Knowledge Graph does not mean one graph standard

One common mistake is to treat a KG and RDF as the same thing.

They are not the same.

RDF is one way to build a KG. It is important, mature, and useful in many settings, especially where interoperability, shared vocabularies, ontologies, and formal reasoning are central requirements.

But a KG is a broader idea. It is the structured, connected representation of information. That representation can be implemented using RDF, a Labelled Property Graph (LPG), or a combination of both.

From an LPG practitioner’s point of view, this distinction is important.

If we assume that KG means RDF only, we miss a practical and powerful design path for applied systems. Many operational KGs are built more naturally as LPGs because the model fits how enterprise and workflow data often appears in the real world.

People, documents, events, tasks, cases, policies, decisions, and tool calls all have rich attributes. Relationships also have attributes. Those attributes change over time. The model evolves as the use case becomes clearer. This is exactly where LPGs are strong.

3. Why the Labelled Property Graph model is a strong foundation for Knowledge Graphs

The LPG model is a strong foundation for KGs because it is flexible, direct, and well suited to operational systems.

In an LPG, nodes can have labels and properties. Relationships can have types and properties. This allows the model to represent both entities and the meaningful connections between them without forcing every detail into a more complex structure.

For example:

(:Patient {nhsNumber, ageBand, riskStatus})
(:Medication {name, doseForm, activeIngredient})
(:Patient)-[:PRESCRIBED {startDate, dose, status}]->(:Medication)

The relationship is not just a link. It carries facts that are essential to the work.

The same applies in legal work:

(:Contract {contractId, valueBand, governingLaw})
(:Clause {clauseType, extractedText, riskLevel})
(:Contract)-[:CONTAINS {page, section, extractionConfidence}]->(:Clause)

This is a natural fit for applied AI because agents need to work with context that is rich, changing, and connected.

LPGs are also practical because they support efficient traversal. In many graph systems, relationships are stored and indexed in a way that makes connected queries fast. That matters when an agent needs to move from a user request to the relevant entities, evidence, policies, prior decisions, and allowed tools.

The schema-free or schema-optional nature of LPGs is also useful. Applied AI systems rarely start with a perfect model. They evolve. New node types appear. New relationship types are added. New properties become important. LPGs make this incremental evolution easier.

There is also a standards point. LPGs are now aligned with the wider graph database ecosystem through the Graph Query Language (GQL), the ISO standard graph query language. This helps position LPG not as an informal alternative to semantic technology, but as a serious foundation for graph applications.

RDF has built-in reasoning strengths. That should be recognised. But reasoning is not exclusive to RDF. In LPG systems, reasoning can be realised through graph algorithms, rule engines, constraints, path queries, embeddings, inference pipelines, ontology alignment, and application logic. The form differs, but the practical outcome can still be achieved.

In many real-world systems, the best answer is not RDF or LPG. It is often RDF and LPG. LPG can provide high-performance operational querying and flexible modelling, while RDF can support interoperability, vocabularies, and semantic exchange where needed.

A practical KG can be LPG-native, RDF-native, or hybrid.

4. What makes a Knowledge Graph applied

An Applied Knowledge Graph (AKG) is a KG designed to support real work.

It does not only describe a domain. It participates in a process.

A general KG may represent medical concepts, legal terms, products, organisations, people, or documents. An AKG connects those concepts to live tasks, workflows, policies, evidence, decisions, and outcomes.

This is the key shift.

In an AKG, we still model things like:

Patient
Condition
Medication
Guideline
Contract
Clause
Matter
Jurisdiction

But we also model operational things like:

Task
AgentRun
ToolCall
Evidence
PolicyCheck
Decision
Exception
HumanReview

This turns the graph from a knowledge structure into an execution structure.

The AKG becomes a place where the agent can find the right context, understand the state of the work, select tools, check policy, record decisions, and show evidence.

That is why the AKG is so important for agentic AI.

5. Why agentic systems need a runtime layer

Agentic AI systems do more than generate answers.

They plan, call tools, inspect results, update state, retrieve evidence, ask for approval, and act across systems. Once an AI system starts doing these things, the architecture needs more than a prompt and a vector store.

A prompt can guide behaviour, but it is not a reliable runtime layer.

A vector store can retrieve text, but it does not naturally represent task state, policy logic, tool permissions, decision history, or the difference between a draft, a recommendation, and an approved action.

A log can record events, but it is usually linear and technical. It does not provide a connected model of why something happened.

Agentic AI needs somewhere to hold the working context of the process.

It needs a way to answer questions such as:

• What is the current state of this case?

• What does the agent know, and how does it know it?

• Which evidence supports this recommendation?

• Which tools are allowed for this task?

• Which policies apply?

• Which human approved the final action?

An AKG can provide this runtime layer.

6. The Applied Knowledge Graph as execution substrate

Calling the AKG an execution substrate may sound technical, but the idea is simple. The AKG becomes the operating layer that the agent uses while doing work.

It holds the domain model. It holds case-specific context. It holds workflow state. It holds policy. It holds evidence. It holds memory. It records the agent’s actions and decisions.

The language model still matters. It is used for interpretation, generation, summarisation, planning, classification, and interaction. But the AKG gives the model a governed environment to work in.

From an LPG practitioner’s point of view, this is a natural evolution.

We are used to modelling entities and relationships. Agentic AI asks us to model the work as well.

That means the AKG should not only contain:

(Patient) -[HAS_CONDITION]-> (Condition)

or:

(Contract) -[CONTAINS]-> (Clause)

It should also contain:

(AgentRun) -[USED_TOOL]-> (Tool)
(Decision) -[SUPPORTED_BY]-> (Evidence)
(Task) -[REQUIRES_REVIEW_BY]-> (Role)
(PolicyCheck) -[APPLIED_TO]-> (ProposedAction)

This is where the AKG becomes active. It does not merely describe the world. It helps manage what the agent does in the world.

7. State: knowing where the work stands

State is one of the most important parts of agentic AI.

In a simple chat interaction, state may sit inside the conversation history. In a professional workflow, that is not enough.

A health agent may need to know that a lab result has arrived, a guideline has been checked, a risk has been flagged, a clinician has reviewed the draft, and the patient has not yet been contacted.

A legal agent may need to know that a clause has been extracted, compared with the playbook, marked as high risk, sent to a partner for approval, and returned with amended fallback language.

This state should not be hidden inside a prompt. In an AKG, the state is explicit and queryable.

A task can be connected to the case, the user, the evidence, the tool calls, the policy checks, the draft outputs, and the current status.

For example:

(ReviewTask) -[ABOUT]-> (Clause)
(ReviewTask) -[HAS_STATUS]-> (AwaitingPartnerApproval)
(ReviewTask) -[BASED_ON]-> (RiskAssessment)
(RiskAssessment) -[SUPPORTED_BY]-> (Evidence)

This makes the system easier to inspect, continue, audit, and improve.

The agent can resume work without guessing. A human can inspect the case without reading a long transcript. Another system can query the state without calling the language model.

8. Memory: making context durable and useful

Agent memory is often treated as a prompt problem. More context is added to the next request and the agent is expected to behave better.

That is a weak form of memory.

Professional systems need memory that is selective, structured, current, and connected.

In health, memory might include a known allergy, a previous adverse reaction, a care preference, a recent medicine change, or a clinician’s note that a patient needs extra support.

These are not the same kind of information. They should not be treated as one flat summary.

In legal work, memory might include a client’s preferred governing law, standard fallback wording, previous negotiation outcomes, risk appetite, and positions that require partner approval.

An AKG gives memory a shape.

It can distinguish facts from assumptions. It can record who supplied information. It can show when something was last updated. It can mark information as superseded. It can connect memory to the cases, documents, decisions, and people it relates to.

This gives the agent a better way to use context.

It can retrieve the specific memory needed for the task, rather than carrying a large and vague history into every interaction.

9. Evidence: grounding actions in sources

GraphRAG already shows the value of connecting retrieval to graph structure. But in agentic AI, evidence has to do more than support an answer. It has to support action.

If an agent flags a clinical risk, recommends a review, drafts a legal response, or routes a case to a specialist, the system needs to show what evidence was used.

In an AKG, evidence is modelled directly.

A decision can be connected to a source document, guideline, clause, record, policy, or previous case. The connection can carry properties such as confidence, date accessed, extraction method, version, and relevance.

For example:

(Decision) -[SUPPORTED_BY {confidence: 0.86}]-> (Evidence)
(Evidence) -[EXTRACTED_FROM]-> (GuidelineVersion)
(Evidence) -[REFERS_TO]-> (LabResult)

Or in legal work:

(RiskAssessment) -[SUPPORTED_BY]-> (ClauseText)
(ClauseText) -[EXTRACTED_FROM]-> (ContractVersion)
(RiskAssessment) -[ASSESSED_AGAINST]-> (PlaybookRule)

This matters because many AI failures are grounding failures.

The agent may use an old document. It may rely on a weak extraction. It may apply a policy that does not fit the jurisdiction. It may answer with confidence but without a valid source.

The AKG gives teams a way to inspect grounding as part of the runtime, not after the fact.

10. Tool routing: choosing the right capability

Agents need tools.

They may need to query a database, search a document store, run a calculation, check a policy, call a terminology service, generate a draft, validate a form, or create a workflow task.

The challenge is not only calling tools. It is knowing which tool should be used, when, with what data, and under which constraints.

An AKG can model tool routing as part of the graph.

A tool can be connected to the task types it supports, the data it can access, the roles allowed to use it, the policies that restrict it, and the evidence it produces.

In health, a medicine safety agent may need to choose between a drug interaction checker, a formulary lookup, a patient record query, and a clinical guideline search.

In legal work, a contract agent may need to choose between a clause extraction tool, a precedent search, a playbook rule check, a jurisdiction lookup, and a redline generator.

The AKG can help the agent answer:

• Which tools are approved for this task?

• Which tool has already been used?

• Which tool result is current?

• Which tool requires human approval before action?

• Which tool is allowed to access this type of data?

This makes tool use more governable.

Instead of tool routing being an invisible model choice, it becomes part of the system design.

11. Policy: turning rules into operational controls

Professional work is full of policy.

Some policy is clinical. Some is legal. Some is organisational. Some is client-specific. Some is regulatory. Some is ethical.

A prompt can tell an agent to follow policy, but that does not make policy operational.

An AKG can turn policy into connected knowledge that is available at runtime.

A policy can be broken into requirements, conditions, exceptions, approvals, roles, jurisdictions, thresholds, and review triggers.

In health, an agent may be allowed to draft a patient summary but not finalise a diagnosis. It may be allowed to recommend clinician review but not directly notify a patient about a serious result without approval.

In legal work, an agent may be allowed to flag risk and suggest fallback wording, but not accept a non-standard liability clause without partner approval. It may treat the same clause differently depending on deal value, governing law, data sensitivity, and client risk appetite.

In the AKG, policy is not just a document in a repository. It is part of the execution environment.

For example:

(ProposedAction) -[CHECKED_AGAINST]-> (PolicyRule)
(PolicyRule) -[REQUIRES_APPROVAL_FROM]-> (Role)
(PolicyRule) -[APPLIES_WHEN]-> (Condition)
(PolicyCheck) -[RESULTED_IN]-> (BlockedAction)

This does not mean policy becomes simple. It means policy becomes visible, testable, and connected to the agent’s actions.

12. Decision traceability: showing what happened and why

In professional settings, users do not only want the answer. They want to understand how the answer was reached.

They need to know what the agent saw, what it used, which tools it called, which policy checks were applied, and whether a human approved the result.

This is especially important when the agent is part of a wider workflow.

A graph is a strong structure for decision traceability because agent decisions are connected. They are not just lines in a log.

A decision may be connected to the original user request, the case or matter, the retrieved evidence, the tool calls, the policy checks, the model output, the human reviewer, and the final action.

These connections let teams ask practical questions.

• Which decisions used this outdated guideline?

• Which contract reviews relied on this version of the playbook?

• Which agent outputs were approved by a human?

• Which high-risk actions were blocked by policy?

• Which recommendations had weak evidence?

This is one of the strongest benefits of the AKG. It gives organisations a way to trace agent behaviour across evidence, action, and governance.

13. Health example: a clinical pathway agent

Consider a clinical pathway agent that supports follow-up after abnormal blood results.

The agent is not replacing the clinician. It is helping organise the work.

The AKG contains nodes for the patient, observations, lab results, medicines, conditions, guidelines, pathway steps, clinicians, review tasks, alerts, decisions, and evidence.

When a new result arrives, the agent checks the patient context. It looks at recent observations, current medicines, known conditions, and the relevant pathway. It retrieves the applicable guideline section and checks whether the result crosses a threshold.

If action is needed, it creates a review task, drafts a short summary, and links the summary to the supporting evidence.

A simplified graph path might be:

(Patient) -[HAS_OBSERVATION]-> (LabResult) -[TRIGGERS]-> (PathwayStep) -[GOVERNED_BY]-> (GuidelineVersion)

The agent action is also captured:

(AgentRun) -[PRODUCED]-> (DraftSummary) -[SUPPORTED_BY]-> (Evidence) -[SOURCED_FROM]-> (GuidelineVersion)

The practical benefit is clear.

A clinician can see why the task was created, which result triggered it, which guideline was used, whether the patient context was complete, and whether escalation rules applied.

The AKG helps the agent act with context, but it also helps the human remain in control.

14. Legal example: a contract review agent

Now consider a contract review agent working on supplier agreements.

The agent extracts clauses, compares them with a playbook, identifies risk, suggests fallback language, and routes exceptions for review.

The AKG contains nodes for the contract, parties, clauses, obligations, jurisdictions, playbook rules, client preferences, risk assessments, fallback positions, review tasks, and decisions.

A limitation of liability clause may be connected to a playbook rule. That rule may depend on deal value, governing law, data sensitivity, and whether the supplier is business-critical.

For example:

(Contract) -[CONTAINS]-> (Clause)
(Clause) -[CLASSIFIED_AS]-> (LimitationOfLiability)
(Clause) -[ASSESSED_AGAINST]-> (PlaybookRule)
(PlaybookRule) -[REQUIRES_APPROVAL_WHEN]-> (DealValueAboveThreshold)
(RiskAssessment) -[SUPPORTED_BY]-> (ClauseText)

The agent does not only say, “This clause is risky.”

It can explain that the clause conflicts with the client’s preferred position because the liability cap is below the required threshold for this kind of agreement. It can show the clause text, the relevant playbook rule, the deal context, and the suggested fallback wording.

It can then route the issue to the correct reviewer and record the outcome.

For legal teams, this creates value beyond speed. It supports consistency, review quality, reuse of institutional knowledge, and defensible decision-making.

15. Benefits of the Applied Knowledge Graph

The AKG provides several practical benefits for agentic AI.

• It gives agents structured context. Instead of relying only on prompt text, the agent can work with a connected model of people, cases, documents, rules, evidence, tasks, and decisions.

• It makes state explicit. The system can show where the work stands, what has been done, what remains open, and what needs review.

• It improves grounding. Outputs and actions can be linked to evidence, source documents, policy rules, and tool results.

• It supports safer tool use. Tools can be selected based on task type, data access, role, policy, and previous use.

• It makes memory more useful. The agent can retrieve relevant, structured, current memory rather than carrying large conversation histories.

• It improves governance. Policy checks, approvals, blocked actions, exceptions, and human reviews can be modelled directly.

• It supports traceability. Decisions can be followed back to the evidence, policy, context, and process that shaped them.

• It also helps systems evolve. LPG models can grow incrementally as new tasks, entities, relationships, tools, and policies are added.

These benefits are especially important in health and legal work, where accuracy, context, evidence, accountability, and human oversight are not optional.

16. What this means for graph-based retrieval and generation

GraphRAG is often described as a better way to retrieve context for generation.

That is true, but agentic AI pushes the idea further.

Traditional GraphRAG asks:

• What context should we retrieve to answer this question?

• Agentic GraphRAG also asks:

• What is the current state of the task?

• What does the agent already know?

• Which evidence applies?

• Which tools are allowed?

• Which policy checks are required?

• What needs to be recorded for traceability?

This changes the role of the graph.

The graph is no longer only a retrieval layer. The AKG becomes part of the runtime.

It helps before generation by selecting context. It helps during action by guiding tool use and policy checks. It helps after action by recording evidence, decisions, and outcomes.

For LPG practitioners, this is a natural next step. We already think in entities, relationships, paths, properties, and traversals. Agentic AI gives those modelling skills a new operational role.

The AKG becomes the structure through which the agent understands, acts, and explains.

17. Closing view

The strongest next move for KGs is to treat the applied form as the runtime layer for agentic AI.

A KG is a structured representation of entities, relationships, and attributes. But an AKG goes further. It connects knowledge to work.

It holds state. It gives memory structure. It grounds decisions in evidence. It helps route tools. It makes policy operational. It records what happened and why.

This is where the LPG model has real strength. It is flexible enough for evolving domains, expressive enough for rich relationships, fast enough for operational traversal, and practical enough for agent workflows.

RDF remains important. Semantic interoperability and formal reasoning remain important. But KG does not mean RDF only. LPGs can provide a strong foundation for applied graph systems, and hybrid approaches can combine LPG performance with RDF interoperability.

For health, legal, and other professional domains, the question is not whether agents can generate fluent output. They already can.

The harder question is whether agents can act with context, evidence, control, and traceability.

That is the role of the AKG.

It is not just a knowledge layer for AI. It is the operating layer for agentic work.

1. Introduction

2. The Core Evaluation Mistake

3. GraphRAG Must Be Evaluated as a System

4. Retrieval Coverage

5. Path Faithfulness

6. Provenance Completeness

7. Cost

8. Latency

9. Decision Usefulness

10. Why Answer Quality Still Matters

11. The Benchmark Problem

12. What Better GraphRAG Evaluation Looks Like

13. Summary

1. Introduction

Retrieval-augmented generation (RAG) is now a common way to improve large language model outputs by supplying external context at query time. Graph Retrieval-Augmented Generation (GraphRAG) extends that idea by introducing structure. Instead of retrieving only isolated text chunks, it can retrieve entities, relationships, paths, and connected evidence.

That promise matters because some questions depend not just on facts, but on how facts connect. Multi-hop dependencies, lineage, policy context, and entity disambiguation are all cases where graph structure can help. In systems built on a Labelled Property Graph (LPG) or an Applied Knowledge Graph (AKG), that structural layer is often central to how retrieval is assembled and explained.

The problem is that GraphRAG is often evaluated too narrowly. Many teams still focus mainly on the final answer: whether it sounds relevant, complete, or convincing. But a graph-based retrieval pipeline is not only a text generation layer. It is a multi-stage system with extraction assumptions, modelling choices, traversal logic, ranking behaviour, provenance handling, cost, and latency.

If evaluation looks only at the answer, much of the system remains untested.

That creates a real risk. A weak GraphRAG pipeline can still produce a polished answer because a large language model can smooth over missing evidence and broken paths. A stronger system may produce a more cautious answer while being far more reliable in practice. In production settings, the second system is usually the one that matters.

This article argues that GraphRAG should be evaluated as a retrieval and decision system, not only as an answer generator. The key questions are not just whether the answer looked good, but whether the system retrieved the evidence it needed, followed the graph faithfully, preserved provenance, operated within acceptable cost and latency, and improved the user’s decision.

That is where serious evaluation begins.

2. The Core Evaluation Mistake

The core mistake is simple. Teams collapse a multi-stage graph retrieval system into a single output judgement.

That usually happens in one of four ways. Human reviewers score the answer for relevance or helpfulness. A large language model acts as a judge and compares the answer to a reference response. A benchmark measures overlap between the answer and an expected text. Or a team runs a set of internal demos and decides that the graph improved quality because the outputs looked more complete.

Each of these methods can tell you something. None tells you enough.

The problem is not that answer quality is irrelevant. The problem is that answer quality is downstream of many other system behaviours, and a good-looking answer can hide poor retrieval. A model may compensate for missing nodes, missing edges, weak provenance, or incorrect paths simply by generating plausible language around what it has. The answer looks clean, but the mechanism underneath is brittle.

Consider a running example from supplier risk management.

A user asks:

Which suppliers are affected by the new sanctions policy, and which live contracts depend on them?

Now imagine two systems.

System A retrieves the sanctions policy, the affected supplier entities, the contract records, their current status, and the dependency relationships linking suppliers to products and products to contracts. It misses one supporting note, but the graph path is largely correct. The answer is concise and slightly cautious.

System B retrieves the policy text and several supplier mentions, but misses two key contract dependencies. The model fills in the missing logic from general context and produces a smoother answer with more confident language.

If a reviewer only reads the final response, System B may look better. It sounds more complete. It uses more polished phrasing. It offers a crisp conclusion.

But System A is the better GraphRAG system.

This is not a theoretical concern. It happens all the time. Large language models are strong at narrative repair. They can smooth over gaps in retrieval and still produce text that feels coherent. That makes answer-only evaluation actively misleading, because it rewards rhetorical fluency even when structural grounding is weak.

Example: The danger of answer-only scoring

Suppose the graph contains these facts:

• Supplier NovaChem supplies Component-17

• Component-17 is required by Device-A

• Device-A is used in contracts C-102 and C-208

• NovaChem is flagged by policy Sanctions-2026-04

• Contract C-208 expired last month

A strong GraphRAG system should answer:

NovaChem is affected by the new sanctions policy. The current active dependency is contract C-102 through Component-17 and Device-A. Contract C-208 is related historically but is no longer active.

A weaker system might answer:

NovaChem affects contracts C-102 and C-208 under the new sanctions policy.

That second answer sounds fine until someone acts on it. It is short, direct, and wrong in a way that matters operationally. If evaluation scores only readability or apparent completeness, it can reward the wrong system.

The mistake becomes even more serious in domains where graph structure carries the real meaning. In GraphRAG, the answer is often less important than the path by which the system got there. If a claim depends on a supplier relationship, a policy version, a temporal constraint, and a contract status edge, those are not optional details. They are the core semantics of the problem.

Most shallow evaluations cannot distinguish those cases. A useful evaluation framework must.

3. GraphRAG Must Be Evaluated as a System

A serious GraphRAG evaluation must treat the pipeline as a system, not as a single text output. That sounds obvious, but in practice, many teams do not do it. They evaluate the final answer and treat everything upstream as an implementation detail. In a graph-based architecture, those upstream stages are where most of the value, and most of the failure risk, actually lives.

A GraphRAG system usually includes at least these stages:

1. Source ingestion

2. Entity extraction and normalisation

3. Relationship extraction or creation

4. Graph modelling and storage

5. Indexing and retrieval setup

6. Query interpretation

7. Graph traversal or neighbourhood expansion

8. Re-ranking and context assembly

9. Prompt construction

10. Large language model generation

11. Output presentation and explanation

Each stage can fail independently. Each failure has a different consequence. Entity extraction may miss an organisation alias. Relationship extraction may create a weak or incorrect edge. Traversal may over-expand into irrelevant neighbourhoods. Re-ranking may down-rank the one critical source that should have been kept. Prompt assembly may drop the temporal qualifier that makes a fact valid only for a limited period. The model may then produce a confident answer that hides the defect.

That is why GraphRAG needs multi-layer evaluation.

At minimum, six dimensions should be measured directly:

1. Retrieval coverage: did the system retrieve the necessary evidence?

2. Path faithfulness: did the answer follow supported graph paths?

3. Provenance completeness: can the claims be traced to sources and transformations?

4. Cost: what does the system consume to build, maintain, and run?

5. Latency: can it respond at operational speed?

6. Decision usefulness: did it improve the user’s action or judgement?

These six dimensions are not arbitrary. Together they answer the practical question that matters in production: is the graph doing meaningful work, or is it an expensive stage prop around a language model?

A system view changes how you measure success

When GraphRAG is treated as a system, success criteria become much more concrete.

You no longer ask only whether the answer is relevant. You ask whether the necessary entities were present, whether the correct relationships were traversed, whether the temporal or policy qualifiers were preserved, whether the answer can be justified, and whether the additional graph logic paid for itself in time, money, and user value.

This changes the culture of evaluation. Instead of celebrating attractive demos, teams begin to inspect retrieval traces, compare required subgraphs to retrieved subgraphs, log edge-level support, and measure decision outcomes. That is a much stronger basis for engineering.

Example: Two different evaluation cultures

An answer-centric team says:

Our GraphRAG assistant scored 4.6 out of 5 for helpfulness in a user review.

A system-centric team says:

For policy impact queries, the system retrieved 92 per cent of required entities, 88 per cent of required relationships, and 95 per cent of required source documents. Claim-level provenance was complete for 90 per cent of material assertions. Median latency was 2.1 seconds, with the 95th percentile at 4.9 seconds. Analysts reached the correct decision 18 per cent faster and reversed 27 per cent fewer cases on review.

Only one of those statements tells you whether the graph is working.

Diagram 3: The GraphRAG evaluation stack

Layer 6  Decision usefulness
Layer 5  Cost and latency
Layer 4  Provenance completeness
Layer 3  Path faithfulness
Layer 2  Retrieval coverage
Layer 1  Graph and source quality

Final answer quality sits across all layers, but does not replace them.

This stack is helpful because it shows dependency. Weak source quality undermines coverage. Weak coverage undermines faithfulness. Weak faithfulness undermines provenance. Weak provenance limits decision trust. Cost and latency determine whether any of it is deployable. The final answer sits on top of all of that. It is not the foundation.

4. Retrieval Coverage

Retrieval coverage is the first major metric, and one of the least well measured.

In GraphRAG, retrieval coverage is not simply about whether the system returned something relevant. It is about whether it retrieved the entities, relationships, documents, and qualifiers required to answer the question correctly. This is a stricter standard than ordinary information retrieval because graph questions often depend on connected evidence rather than isolated facts.

A system can have high surface relevance and still have poor coverage.

Take this question:

Which suppliers became non-compliant after the 2025 policy revision, and which active customer commitments are exposed through those suppliers?

This is not a chunk retrieval problem in the ordinary sense. A correct answer may require:

The policy revision event

1. The version or effective date of the policy

2. Supplier entities mapped to the right canonical identifiers

3. Compliance status changes after the revision date

4. Product or component dependencies

5. Customer commitments or contracts that are currently active

6. Temporal validity on those dependencies

If the system retrieves supplier names and the revised policy but misses the edge that links the supplier to currently active commitments, the coverage is incomplete. If it retrieves the dependency path but misses the date logic that says the policy took effect after the supplier event, coverage is incomplete. If it retrieves a contract that was active last quarter but not today, coverage is incomplete.

This is why GraphRAG coverage must be defined against required evidence, not just retrieved evidence.

Types of retrieval coverage that matter

Coverage in GraphRAG usually has several components:

Entity coverage
Did the system retrieve the right people, organisations, products, policies, cases, locations, or other entities?

Relationship coverage
Did it retrieve the links that make those entities meaningful in context, such as dependency, ownership, membership, amendment, approval, or exception?

Document coverage
Did it retrieve the source materials from which those entities and relationships are supported?

Constraint coverage
Did it retrieve the qualifiers that govern meaning, such as time, jurisdiction, status, policy version, confidence, or scope?

Subgraph coverage
Did it retrieve the connected portion of the graph required to answer the question, rather than only isolated nodes?

These distinctions matter because a graph answer can fail even when the right nodes are present. If the linking edges are missing, or the temporal qualifiers are absent, the answer may still be wrong.

Example: Coverage failure hidden by a plausible answer

Suppose the graph includes the following:

• Policy-47 revised supplier controls on 15 January 2026

• Supplier-Orbit failed a compliance review on 20 January 2026

• Supplier-Orbit supplies Module-K

• Module-K is used by Service-Bundle-9

• Service-Bundle-9 underpins contracts A91 and A95

• A95 was terminated on 1 February 2026

Now imagine that retrieval returns everything except the termination fact for A95.

The model may answer:

Supplier-Orbit affects contracts A91 and A95 under Policy-47.

That answer is structurally incomplete. It is not enough to say it is “mostly right”. A decision-maker may escalate the wrong contract, trigger unnecessary work, or lose trust in the system when they later discover the error.

How to measure retrieval coverage properly

A useful coverage evaluation starts with a representative set of tasks. For each task, you define the minimum evidence needed for a correct answer. That evidence may be represented as a gold subgraph, a gold set of entities and edges, or a labelled collection of required source passages and graph objects.

For each query, you then compare what the system retrieved against what it should have retrieved.

A practical scoring template might include:

• required entities retrieved / total required entities

• required relationships retrieved / total required relationships

• required source documents retrieved / total required documents

• required temporal or policy qualifiers retrieved / total required qualifiers

• irrelevant expansion size, meaning how much extra material was retrieved beyond what was needed

This last point matters. Over-retrieval is not harmless. A system that retrieves everything may appear to have strong coverage while actually reducing answer quality through noise, prompt bloat, and latency. Coverage must therefore be balanced with precision and context discipline.

Diagram 4: Gold subgraph versus retrieved subgraph

Gold subgraph needed for the question:

[Policy-47] -> affects -> [Supplier-Orbit]
[Supplier-Orbit] -> supplies -> [Module-K]
[Module-K] -> used_by -> [Service-Bundle-9]
[Service-Bundle-9] -> underpins -> [A91]
[Service-Bundle-9] -> underpins -> [A95]
[A95] -> status -> [Terminated]

Retrieved subgraph:

[Policy-47] -> affects -> [Supplier-Orbit]
[Supplier-Orbit] -> supplies -> [Module-K]
[Module-K] -> used_by -> [Service-Bundle-9]
[Service-Bundle-9] -> underpins -> [A91]
[Service-Bundle-9] -> underpins -> [A95]

Missing edge:
[A95] -> status -> [Terminated]

That missing edge is not a minor defect. It changes the operational answer.

Why coverage is especially important in Applied Knowledge Graph systems

In an Applied Knowledge Graph, the graph is expected to support actual work. It is not only a conceptual map. It is part of the runtime architecture for decisions, workflows, and evidence assembly. That makes retrieval coverage especially important because the user is not reading the graph directly. They are relying on the GraphRAG layer to assemble the right connected context on their behalf.

If coverage is poor, the problem is not merely that the answer is incomplete. The problem is that the system is not doing the applied part of the job.

5. Path Faithfulness

Coverage answers one question: did the system retrieve the right pieces? Path faithfulness answers the next: did it use those pieces correctly?

This is where GraphRAG should clearly distinguish itself from plain chunk-based retrieval. In GraphRAG, the graph is supposed to constrain reasoning. It introduces a structure that says which entities are related, how they are related, and along which routes the system is allowed to assemble an explanation. If the final answer ignores that structure and improvises links that are not present, then the graph is not grounding the result. It is merely decorating it.

Path faithfulness means that the claims in the answer can be supported by the nodes, edges, and traversed paths retrieved for that query.

This is stronger than general factual correctness. An answer might contain a true statement drawn from background knowledge, but if that statement is not supported by the retrieved graph for the case at hand, it is still not faithful to the GraphRAG mechanism.

Example: Correct-sounding but unfaithful reasoning

Assume the retrieved graph contains:

• Device-X depends on Battery-Pack-2

• Battery-Pack-2 is supplied by Voltis

• Voltis failed a safety audit in March

• Device-X is active in the United Kingdom

The system is asked:

Which active products in the United Kingdom are exposed to suppliers that failed recent safety audits?

A faithful answer is:

Device-X is exposed through Battery-Pack-2 because Voltis, the supplier of that component, failed a recent safety audit.

An unfaithful answer might be:

Device-X and Device-Y are exposed because Voltis supplies critical battery infrastructure across the product line.

That may sound plausible, especially if Device-Y exists elsewhere in the knowledge base, but if the retrieved graph for this query did not connect Device-Y through a valid path, the answer is unfaithful. It has gone beyond the graph and inferred a broader relationship than the retrieved evidence supports.

Why unfaithful paths happen

Path faithfulness breaks for several reasons.

The model fills gaps
The large language model may bridge missing edges with general world knowledge or patterns it has seen before.

Traversal over-expands
The system may retrieve a large neighbourhood around a relevant node, giving the model many nearby but not actually connected facts.

Ranking obscures path logic
A re-ranking stage may mix evidence from different branches of the graph without preserving which branch supports which claim.

Prompt design blurs support
If the prompt presents graph findings as a flat list rather than as structured paths, the model may recombine them incorrectly.

The second answer may be fluent, but the graph does not support it.

How to evaluate path faithfulness

A robust evaluation checks whether each material claim in the answer can be mapped to a supported path in the retrieved subgraph.

That requires a claim decomposition step. For instance, this answer:

Contracts A91 and B17 are at risk because Supplier-Orbit became non-compliant after Policy-47, and both contracts depend on Module-K.

can be decomposed into claims such as:

1. Supplier-Orbit became non-compliant after Policy-47

2. Contract A91 depends on Module-K

3. Contract B17 depends on Module-K

4. The dependency path from Supplier-Orbit to each contract implies exposure

Each claim should then be checked against the retrieved graph. This can be done manually on small evaluation sets or semi-automatically if the system stores path traces, traversal logs, or edge-level evidence identifiers.

A useful faithfulness score might consider:

• percentage of claims backed by explicit paths

• percentage of claims backed only by node co-occurrence

• percentage of unsupported claims

• average path length per supported claim

• number of claims relying on inferred but unrecorded steps

The last item matters. If the system applies inference rules, that is fine, but the inference must be explicit and inspectable. Hidden inference is just guessing with better branding.

Path faithfulness is central to trust

In many production environments, users do not only want an answer. They want to know why that answer follows. Graph structure is powerful because it can provide that why. It can show that a conclusion came from a dependency chain, a chain of ownership, a policy amendment path, or a sequence of approvals.

If the answer is not faithful to those paths, GraphRAG loses one of its strongest advantages.

This is especially important in an LPG-based Applied Knowledge Graph, where relationships often carry explicit business meaning. The edge is not merely a navigational convenience. It represents something operational, such as supports, depends_on, approved_by, replaced_by, governed_by, or valid_until. If the final answer does not respect those semantics, it is not just loose. It is structurally wrong.

6. Provenance Completeness

If coverage is about retrieving the right evidence, and faithfulness is about using that evidence correctly, provenance completeness is about being able to prove where the answer came from.

Many GraphRAG systems make broad claims about explainability because they use a graph. That is not enough. A graph can still have poor provenance. Nodes may exist without clear source spans. Edges may be created by extraction pipelines whose evidence is not preserved. Re-ranking decisions may not be logged. Summaries may compress multiple sources into a single statement without showing which source contributed which part.

In those cases, the graph may look explainable, but the explanation is hollow.

Provenance completeness means that material claims in the answer can be traced back through the retrieval chain to source documents, source spans, extracted entities, extracted or asserted relationships, and any transformation steps applied along the way.

This has several layers.

Source provenance
Which documents, records, events, or databases support the claim?

Extraction provenance
How was the entity or relationship created? Was it directly asserted from a system of record, or extracted from unstructured text?

Transformation provenance
What normalisation, aggregation, summarisation, or inference steps were applied?

Selection provenance
Why was this evidence selected rather than other evidence?

Example: A graph node with weak provenance

Suppose the graph contains:

• Supplier-Orbit

• non_compliant_with -> Policy-47

That edge may look useful, but where did it come from?

A complete provenance trail might show:

• Source document: audit_report_2026_01_20.pdf

• Source span: paragraph 14

• Extraction rule: compliance_event extractor v3.4

• Normalisation: Orbit Ltd mapped to canonical entity Supplier-Orbit

• Policy mapping: new supplier controls resolved to Policy-47

• Confidence: 0.91

• Human review: approved

A weak provenance trail might show only:

• Source: audit report
  

Those are not equivalent. In a production environment, the first is usable and auditable. The second is merely suggestive.

That is what explainability should look like. Anything less is partial.

Why provenance matters beyond compliance

It is easy to say provenance matters for audit and regulation, which is true. But its value is broader.

Provenance helps debugging. When the answer is wrong, provenance tells you whether the issue was in the source, the extraction pipeline, the graph model, the traversal, or the prompt. Without provenance, everything looks like a vague model problem.

Provenance helps user trust. People are far more willing to rely on a system if they can inspect the path back to evidence and understand why the answer appeared.

Provenance helps maintenance. As graphs evolve, provenance makes it easier to detect stale relationships, outdated extraction logic, and brittle assumptions.

Provenance also helps adjudicate conflict. If two sources disagree, provenance allows the system to show recency, authority, and source quality rather than merely presenting a blended summary.

How to measure provenance completeness

A practical approach is claim-level provenance scoring. For each material claim in an answer, ask:

1. Is there at least one source document or system record?

2. Is the supporting entity or relationship linked to that source?

3. Can the retrieval path be reconstructed?

4. Are transformation steps visible?

5. Is temporal or version information preserved where relevant?

A claim with all five elements has strong provenance. A claim with only the source document has weak provenance. A claim with no traceable evidence is ungrounded.

This can be summarised as percentages across an evaluation set:

• claims with full provenance

• claims with partial provenance

• claims with missing provenance

• edges with source support

• entities with source-span support

In an Applied Knowledge Graph, provenance should be treated as an operational primitive, not as decorative metadata. It is part of how the system earns the right to be trusted.

7. Cost

Cost is one of the most neglected dimensions in GraphRAG evaluation, which is remarkable because it is often where projects quietly fail.

Graphs are not free. Entity extraction is not free. Relationship extraction, entity resolution, normalisation, indexing, graph maintenance, provenance storage, traversal, re-ranking, and context packaging all carry cost. If the graph is updated continuously, those costs are recurring rather than one-off. If the system also uses embeddings, hybrid retrieval, or multiple model calls, the cost profile can become much larger than teams expected.

Yet many GraphRAG evaluations discuss answer quality as if the graph came at zero cost.

That is not a minor omission. Cost determines whether a GraphRAG design is economically rational.

Build-time versus run-time cost

GraphRAG cost should be divided into at least two broad classes.

Build-time cost includes:

• source ingestion and cleaning

• entity and relationship extraction

• entity resolution and deduplication

• schema evolution or graph model maintenance

• indexing and embedding generation

• provenance capture and storage

Run-time cost includes:

• graph query execution

• traversal and neighbourhood expansion

• filtering and re-ranking

• context assembly

• large language model inference

• explanation and provenance packaging

A system may have moderate run-time cost but extreme build-time cost if the graph is expensive to maintain. Another system may have low build cost but very high run-time cost because traversal and packaging are inefficient. Evaluation should surface both.

GraphRAG must justify its structural premium

GraphRAG often introduces an architectural premium. That premium may be worth paying if the graph truly improves retrieval, explanation, and decision support. In high-value workflows, even a relatively expensive system can be justified if it reduces regulatory exposure, speeds case review, or lowers error rates in a measurable way.

But that value must be shown.

An Applied Knowledge Graph is supposed to be applied. That means it must earn its place in the operating model. If the graph increases cost substantially but provides only marginal gains over simpler retrieval methods, the evaluation should make that visible.

A sensible evaluation asks which of those stages dominate, whether they scale linearly or non-linearly, and whether they correspond to user value.

What to measure

A useful GraphRAG cost evaluation may include:

• cost per ingested document

• cost per resolved entity

• cost per relationship extracted

• storage cost for graph plus provenance

• cost per user query

• average number of graph operations per query

• model cost per query

• total monthly cost by workload type

For comparison purposes, it is also useful to measure the equivalent cost of a simpler baseline, such as vector-only retrieval or keyword plus vector search. GraphRAG should not be protected from comparison merely because it sounds more architecturally ambitious.

Cost should be linked to benefit

A common mistake is to measure cost in isolation. That can lead to unhelpful conclusions, because a costly system may still be worthwhile in the right domain. The key is cost relative to gain.

For example:

• If GraphRAG cuts analyst review time by 25 per cent and reduces escalations, its higher cost may be justified.

• If GraphRAG improves answer phrasing but does not improve decision quality, the same cost may not be justified.

• If graph maintenance cost rises sharply as the domain expands, but decision benefit does not, the architecture may need redesign.
  

Cost is therefore not only a financial metric. It is part of architectural truthfulness. It tells you whether the graph is earning its keep.

8. Latency

Latency is often pushed aside as an implementation detail, but in GraphRAG it is a first-order property of the system. A beautifully grounded answer that arrives too late for the workflow is not a high-quality answer. It is a missed opportunity.

GraphRAG can introduce several sources of delay that plain retrieval pipelines do not have to the same degree: graph lookup, neighbourhood expansion, path scoring, provenance packaging, and sometimes multiple model calls to compress or synthesise graph evidence. If these stages are not measured carefully, a system can appear successful in tests while failing in actual use.

Latency is contextual

Different workflows have different latency tolerances.

A real-time customer support tool may need to respond in a couple of seconds. A fraud investigation assistant may tolerate more delay if the answer is materially better. A legal review workflow may accept several seconds for stronger evidence and provenance. A background report generator can tolerate even more.

That means latency targets must be tied to the use case, not discussed in the abstract. The question is not “Is this fast?” but “Is this fast enough for the operational context?”

Example: Same accuracy, different deployability

Consider two GraphRAG designs for internal contract risk review.

Design A returns answers in 1.8 seconds on average and 4.2 seconds at the 95th percentile.

Design B returns slightly richer answers in 3.9 seconds on average and 11.5 seconds at the 95th percentile.

If the tool is used during live calls with account teams, Design B may be unacceptable despite better answer detail. If the tool is used for offline risk preparation, Design B may be acceptable. Latency evaluation must therefore include operational context, not just raw timings.

Why average latency is not enough

Teams often report only the mean or median response time. That is rarely enough. Users experience the slow tail, not just the average. A system with acceptable median latency but poor high-percentile latency can feel unreliable, especially under load.

That is why high-percentile measures matter. If the 95th percentile latency is too high, the system may still be unfit for real use even if the median looks good.

A useful latency profile should include:

• median latency

• 90th percentile latency

• 95th percentile latency

• tail behaviour under concurrent load

• stage-by-stage timing

The stage-by-stage view is particularly important because it tells you where optimisation effort should go. Is the delay in graph traversal? In re-ranking? In provenance assembly? In prompt size inflation? In the model call itself? Without breakdown, latency becomes a generic complaint rather than an engineering signal.

Diagram 8: Latency decomposition

Query received
   |
   +-> graph lookup ............. 120 ms
   +-> neighbourhood expansion .. 450 ms
   +-> re-ranking ............... 180 ms
   +-> provenance packaging ..... 260 ms
   +-> prompt assembly .......... 90 ms
   +-> LLM generation ........... 1400 ms
   |
Total ........................... 2500 ms

A diagram like this is far more useful than saying “response time was 2.5 seconds”.

Latency and graph design

Latency is not only a runtime tuning issue. It is also influenced by graph design choices.

A graph with overly dense, weakly typed relationships may cause traversal explosion. A graph with poor entity normalisation may require extra search and merge steps at query time. A graph that stores provenance in a way that is expensive to reconstruct may slow explanation packaging. A graph that mixes operational and archival relationships without careful filtering may retrieve too much and force expensive downstream pruning.

This is one reason why an LPG is often helpful in enterprise GraphRAG. Explicit relationship types, attributes, status flags, and temporal properties can make query-time filtering more direct and more operationally aligned. But the model only helps if the evaluation actually measures latency consequences.

Latency must be evaluated with workload realism

Demo queries are often too clean. Real workloads include:

• ambiguous names

• broad questions that trigger large expansions

• spikes in concurrent use

• stale cache conditions

• difficult policy or lineage queries that need more path analysis

A credible latency evaluation should include realistic query mixes and realistic load patterns. It should also measure the trade-off between stronger grounding and response time, because that trade-off is often where product decisions need to be made.

Latency is therefore not a side metric. It is part of system quality. It determines whether GraphRAG can operate where it claims to add value.

9. Decision Usefulness

Decision usefulness is the most important metric and the one most often ignored.

GraphRAG is rarely deployed simply to produce nicer prose. In enterprise settings, it is usually deployed because someone needs to make a better decision, faster, with stronger evidence. If evaluation stops at answer quality, it may completely miss whether the system improved the actual work.

This is a crucial distinction. A long, polished answer may not help a user act. A shorter answer with the right dependency path, the right warning, and the right provenance may be much more useful.

What decision usefulness means

Decision usefulness asks whether the system improved the quality, speed, confidence, or consistency of the user’s judgement or action.

That might mean:

• fewer false escalations in supplier risk review

• faster resolution of compliance questions

• better consistency across analysts reviewing the same case

• lower rate of decision reversal on second review

• better handling of edge cases that plain retrieval misses

• stronger confidence because evidence is inspectable

These outcomes are closer to the real purpose of the system than readability scores.

Example: A useful answer versus an impressive answer

A procurement analyst asks:

Do we need to freeze customer onboarding for accounts dependent on Supplier-Orbit?

Answer A says:

Supplier-Orbit is associated with recent compliance concerns. Affected accounts may include several high-value contracts across current service bundles. Further investigation is recommended.

Answer B says:

No immediate freeze is required for all accounts. The exposure is limited to contracts A91 and A93 through Module-K. Contract A95 appears in historical dependency records but is terminated. The compliance issue is linked to Policy-47, effective 15 January 2026. Review only active bundles using Module-K.

Answer B is more useful even if it is less stylistically elegant. It narrows the action, shows why, and points to the relevant evidence and constraint. That is what decision support should do.

Why answer-centric metrics miss usefulness

Readability, fluency, and generic relevance do not necessarily capture whether the answer supports action. A fluent answer may still leave the user unsure what to do. It may overstate risk, understate uncertainty, or fail to highlight the key qualifying relationship that changes the operational decision.

This is particularly important in GraphRAG because the graph is often introduced precisely to improve structural judgement. It is supposed to expose dependencies, exceptions, lineage, and context that ordinary retrieval misses. If evaluation never measures whether those structural advantages changed the decision, it misses the whole point of adding the graph.

How to measure decision usefulness

Decision usefulness should be measured against the domain, not through generic text scoring. Useful measures may include:

• time to justified decision

• decision accuracy against expert review

• rate of false positives or false negatives

• rate of escalation or rework

• reviewer agreement across users

• confidence with evidence inspection

• decision reversal rate after secondary review
  

These can be assessed in offline evaluation or controlled user studies. Even a small but well-designed study can reveal more than a thousand answer ratings if it measures real task performance.

Diagram 9: From answer quality to decision value

Low-value evaluation:
Question -> Answer -> “Looks helpful”

High-value evaluation:
Question -> Retrieved evidence -> Supported answer -> User action -> Outcome

The right-hand side is more difficult to measure, but it is where business value lives.

Decision usefulness is where GraphRAG should win

GraphRAG is strongest when the decision depends on structure. That includes:

• identifying impact through multi-hop dependencies

• tracing which policy version governs a case

• explaining why a record falls within or outside a rule

• resolving which entity a document actually refers to

• showing how evidence from several systems connects

These are not cosmetic benefits. They are operational benefits. Evaluation should therefore ask whether GraphRAG improved those decisions relative to simpler approaches.

If not, the architecture may still be interesting, but it is not yet justified.

10. Why Answer Quality Still Matters

None of this means that final answer quality is unimportant. It still matters. Users need answers that are clear, concise, correct, and usable. An answer that is perfectly grounded but unreadable is not a success. Likewise, a system that retrieves the right graph paths but produces confusing explanations has an adoption problem.

The point is not to remove answer quality from evaluation. The point is to place it in the correct position.

Answer quality is one layer in a broader evaluation framework. It is the visible surface of the system, but it should not be mistaken for the system itself. A strong GraphRAG evaluation therefore keeps answer quality, but treats it as downstream of retrieval integrity, provenance, performance, and decision value.

A better order of evaluation

A sensible evaluation sequence looks like this:

1. Did the system retrieve the required evidence?

2. Did it follow supported graph paths?

3. Are material claims traceable to provenance?

4. What did the system cost to build and run?

5. How quickly did it respond under realistic conditions?

6. Did it improve the user’s decision?

7. Only then, how clear and useful was the answer text?

This order matters because it reflects how the system actually works. If steps 1 to 6 are weak, step 7 can still look good because the large language model is capable of producing polished output from imperfect input. That is exactly why answer quality must not dominate evaluation.

Answer quality is still useful for product fit

There is a place for human judgement of answer clarity, tone, structure, and usefulness. It matters for adoption. Users prefer systems that communicate well. A technically strong GraphRAG pipeline can still fail in practice if the answer is too verbose, too hedge-heavy, too difficult to inspect, or too vague about action.

That is why answer quality should remain part of the scorecard. It should simply be understood for what it is: a user-facing quality layer, not proof that the graph worked.

11. The Benchmark Problem

A major reason GraphRAG evaluation remains weak is that many available benchmarks are poorly aligned with the value proposition of graph-based retrieval.

A lot of public benchmarks focus on short factual questions with narrow answer targets. That makes scoring convenient. It also makes the graph less necessary. If a question can be answered from one or two well-matched chunks, then GraphRAG has little room to demonstrate its advantage. The benchmark may end up testing general retrieval quality rather than graph utility.

This leads to two problems.

First, GraphRAG can appear unimpressive because the benchmark does not require structure.

Second, weak GraphRAG can appear successful because the benchmark rewards polished answers instead of structural grounding.

What kinds of questions actually test GraphRAG

GraphRAG becomes valuable when the task depends on one or more of the following:

• multi-hop relationships

• entity disambiguation

• lineage or impact analysis

• temporal validity

• policy exceptions and overrides

• source reconciliation across systems

• decision justification through connected evidence

A benchmark that does not include these characteristics is not really testing the graph.

Failure modes that benchmarks should capture

A useful GraphRAG benchmark should also capture the ways graph-based systems fail. For example:

• missing entities from extraction

• incorrect entity resolution

• spurious relationships

• path over-expansion

• temporal qualifier loss

• provenance gaps

• ranking collisions between relevant branches

These failure modes are central to GraphRAG quality, yet many benchmarks ignore them entirely because they score only final answers.

Diagram 10: Benchmark alignment

Factoid benchmark:
Question -> one chunk -> answer
Graph adds little value

Structural benchmark:
Question -> entities + relationships + qualifiers + path -> answer
Graph has room to prove value

Without structurally demanding tasks, evaluation can become a marketing exercise rather than a real test.

Benchmark design should reflect the intended use

If your GraphRAG system is meant to support procurement, compliance, fraud, legal review, or operational analysis, then the benchmark should reflect those tasks. It should include ambiguity, dependency, conflicting sources, changing status, and user questions that require path-sensitive reasoning.

Otherwise, you may end up optimising for a public leaderboard while learning very little about production readiness.

12. What Better GraphRAG Evaluation Looks Like

A better evaluation framework is not mysterious. It is simply more disciplined and more aligned to how graph-based retrieval systems actually work.

A practical approach can be organised into a sequence.

Step 1: Define the operational task

Start with the actual job. What is the user trying to decide or do? Not “answer questions about documents” in the abstract, but something concrete such as:

• identify exposed live contracts after a policy change

• explain why a supplier is classified as high risk

• trace which customers depend on a failed component

• determine which regulation version applies to a case

This matters because the evaluation must reflect the intended decision environment.

Step 2: Specify the required evidence

For each representative query, define what evidence is required for a correct answer. This may be expressed as:

• a gold subgraph

• a set of required entities and relationships

• a set of required source records

• required temporal or policy qualifiers

This step is often skipped because it takes effort. Without it, however, coverage cannot be measured meaningfully.

Step 3: Measure retrieval coverage

Check whether the system retrieved the required entities, edges, sources, and qualifiers. Measure both missing evidence and irrelevant expansion. A system that retrieves too little fails on recall. A system that retrieves too much may create noise, cost, and latency.

Step 4: Measure path faithfulness

Break the answer into material claims and verify which claims are supported by explicit graph paths. Distinguish between:

• directly supported claims

• claims supported only by weak co-occurrence

• unsupported claims

• claims that rely on unlogged inference

This reveals whether the graph is constraining reasoning or merely ornamenting it.

Step 5: Measure provenance completeness

For each material claim, verify source support, extraction support, transformation history, and any relevant temporal or version information. Provenance must be checked at claim level, not only at whole-answer level.

Step 6: Record cost and latency

Measure both build-time and run-time cost. Record median and high-percentile latency under realistic workloads. Break timings down by stage so the results are useful to engineers and architects rather than just to programme managers.

Step 7: Measure decision usefulness

Run user tasks or offline simulations to see whether the system improved action. Did it reduce review time? Lower decision error? Improve consistency? Reduce reversals? Increase confidence with inspectable evidence?

Step 8: Score answer quality last

Now evaluate clarity, completeness, tone, and usefulness of the answer itself. This is still valuable, but it comes after retrieval integrity, provenance, performance, and decision value have been established.

Example: A compact GraphRAG evaluation scorecard

Use case: Supplier risk impact analysis

Coverage
- required entities retrieved: 18/20
- required relationships retrieved: 14/16
- required source documents retrieved: 9/9
- required temporal qualifiers retrieved: 6/8

Faithfulness
- material claims: 12
- claims with explicit path support: 10
- claims with weak support: 1
- unsupported claims: 1

Provenance
- claims with full provenance: 9/12
- claims with partial provenance: 2/12
- claims with missing provenance: 1/12

Performance
- median latency: 2.4 seconds
- 95th percentile latency: 5.1 seconds
- average cost per query: £0.19

Decision usefulness
- analyst task completion time improved by 21 per cent
- false escalation rate reduced by 17 per cent
- reviewer agreement improved by 11 per cent

Answer quality
- average user rating: 4.2/5

A scorecard like this is far more revealing than a generic statement that users “liked the results”.

Better evaluation also improves design

One of the hidden benefits of this framework is that it supports better architecture. If coverage is weak, you know to inspect extraction and retrieval. If faithfulness is weak, you know to inspect traversal and prompting. If provenance is weak, you know to improve evidence capture. If latency is weak, you know where to optimise. If decision usefulness is weak despite strong technical scores, you may have chosen the wrong task or the wrong product experience.

This is why serious evaluation is not bureaucracy. It is design feedback.

13. Summary

Most GraphRAG evaluations are wrong because they reward systems for sounding right rather than being structurally right.

That mistake is easy to make. Final answers are visible, easy to score, and convenient to compare. Retrieval coverage, path faithfulness, provenance completeness, cost, latency, and decision usefulness are harder to measure. They require more careful task design and more engineering discipline.

But GraphRAG makes structural claims. It claims that graphs improve retrieval, support connected evidence, enable explanation, and help people make better decisions. If those are the claims, then those are the things the evaluation must test.

A serious GraphRAG evaluation therefore asks:

• did the system retrieve the evidence it needed?

• did it follow graph paths faithfully?

• can the answer be traced to sources and transformations?

• what did it cost?

• how quickly did it respond?

• did it improve the user’s decision?

Only after those questions are answered should we ask how polished the prose looked.

This matters even more in systems built on a Labelled Property Graph or an Applied Knowledge Graph, where relationships are expected to carry operational meaning. In those systems, the graph is not a visual accessory around a large language model. It is part of the runtime logic. If evaluation ignores that logic, it is not evaluating GraphRAG at all.

The way forward is not complicated, but it is stricter. Define the task. Specify required evidence. Measure coverage. Check faithfulness. Trace provenance. Record cost and latency. Test decision value. Then score the answer itself.

That is how GraphRAG should be judged.

Otherwise, we will keep rewarding elegant responses built on weak retrieval and incomplete support, and we will learn very little about whether the graph actually helped. That is not a GraphRAG success story. It is just another language model demo with a graph-shaped prop.

1. Introduction

2. Why financial documents are graph-shaped problems

3. Why LPG is the right operational model for this workload

4. Applied Knowledge Graph in finance: the missing middle layer

5. A reference architecture for financial document intelligence

6. GraphRAG for finance: where it works and where it breaks

7. Why Graph Data Science matters after graph construction

8. A practical LPG schema for filings, notes, facts, controls and obligations

9. Code examples

10. What to measure in production

11. Common failure modes

12. Closing view

1. Introduction

Most discussion about GraphRAG still starts from retrieval. In financial document processing, that is often the wrong starting point.

The hard part is rarely retrieving another chunk. The hard part is preserving identity, time, dependency, control, provenance, and numerical context across filings, footnotes, tables, ownership structures, policies, and regulations. Structured reporting formats such as eXtensible Business Reporting Language, or XBRL, and Inline XBRL already expose a machine-readable layer, but the real value appears only when those facts are connected to narrative disclosures, entities, obligations, and decisions in a graph that supports traversal and computation.

From the perspective of a Labelled Property Graph (LPG), practitioner, this is where the centre of gravity shifts. The question is not whether a graph can represent financial reporting semantics. It can. The question is which graph model best supports runtime decision support, multi-hop investigation, graph-native analytics, and graph-grounded artificial intelligence in systems that need to work under operational constraints.

2. Why financial documents are graph-shaped problems

Financial reports are not just long documents. They are relational systems disguised as documents.

A Form 10-K annual report, or an equivalent statutory report, contains issuers, subsidiaries, segments, instruments, covenants, jurisdictions, auditors, risks, definitions, footnotes, tables, dimensions, periods, and cross-references. Inline XBRL gives tagged facts with periods, units, and taxonomy concepts, but it does not by itself answer operational questions such as which obligations apply to which entity under which conditions, how an exposure propagates across a control chain, or what evidence supports a conclusion about a risk disclosure.

That means the important questions are usually path questions, neighbourhood questions, and subgraph questions. A consolidation question is a traversal problem. A covenant applicability question is a dependency problem. A control-to-obligation mapping question is a provenance problem. A risk concentration question is a network problem. A cross-period comparison question is a temporal graph problem.

Vector retrieval can help with entry points, but on its own it is usually not a strong operating model for those tasks. In finance, meaning often emerges from relationships rather than from isolated fragments of text.

3. Why LPG is the right operational model for this workload

A Resource Description Framework (RDF), stack is excellent when formal semantics, interoperability, and ontology-driven validation dominate the architecture. That matters in finance and should not be dismissed.

But once the centre of gravity moves from knowledge representation to operational intelligence, LPG often has distinct advantages.

In LPG, adjacency is native, properties live directly on nodes and relationships, and variable-length traversals are natural. For financial document intelligence, those strengths show up quickly.

Temporal ownership and control chains are easier to execute as relationship-rich traversals than as an ontology-first exercise. Evidence paths are first-class, so it is natural to move from entity to filing section to text unit to table cell to fact. Graph-native analytics can run on the same operational structure with minimal impedance mismatch. GraphRAG local retrieval aligns naturally with neighbourhood expansion. Most importantly, decision systems care about runtime behaviour. In finance, the graph is not just a store of meaning. It is the substrate for live questions: what applies, what changed, what is connected, what is missing, what is anomalous, and what should happen next.

That is why the architecture should be framed this way: ontology and taxonomy provide semantic discipline where needed, but LPG is often the workhorse for an operational Applied Knowledge Graph (AKG), in document-heavy financial workflows.

4. Applied Knowledge Graph in finance: the missing middle layer

A lot of financial artificial intelligence work still jumps from document parsing straight to retrieval-augmented generation. That misses the layer that matters most: the Applied Knowledge Graph.

By AKG here, I mean a graph designed not just to represent facts, but to support a bounded set of business decisions and investigations. It sits between source documents and graph-enabled applications. It carries provenance, confidence, temporal validity, canonical identity, and operationally meaningful relationships.

In finance, the AKG is the layer that links authoritative facts, narrative claims and disclosures, legal entities and identifiers, obligations, controls and evidence, periods, events and state changes, and graph features used for ranking, anomaly detection, or retrieval.

That AKG layer is what allows GraphRAG to become more than document retrieval. It becomes graph-grounded reasoning over a structured operational substrate.

5. A reference architecture for financial document intelligence

This architecture reflects the shape of the problem.

On ingestion, use structured filings wherever possible. For the United States reporting, the Securities and Exchange Commission, or SEC, exposes filings through the Electronic Data Gathering, Analysis, and Retrieval system, or EDGAR. In Europe, annual financial reporting is standardised through the European Single Electronic Format, or ESEF. On document conversion, table quality matters disproportionately. For graph construction, finance-specific extraction requires closed-schema control, table-aware chunking, strong provenance, and careful entity normalisation. On retrieval, the common query modes are Local Search, Global Search, and DRIFT Search, together with evidence expansion across both high-level communities and local text units.

6. GraphRAG for finance: where it works and where it breaks

GraphRAG is useful in finance, but only if you are clear about the task.

It works well for cross-reference-heavy questions, entity-centred investigations, and corpus-level thematic synthesis. Local Search is strong when the question is about a known entity, concept, contract, or event. Global Search is strong when the question asks for dominant themes or patterns across many filings. DRIFT Search is useful for workflows that need expansion across both high-level communities and local evidence.

It breaks when people expect it to compensate for poor source structure.

If the table parser fractures the statement, GraphRAG inherits the fracture. If entity resolution confuses issuer and subsidiary, GraphRAG amplifies the confusion. If periods are attached incorrectly, GraphRAG distorts time. If the schema drifts into uncontrolled labels, GraphRAG becomes noisy. If provenance is not preserved at text-unit level, trust in the outputs falls.

That is why finance should treat GraphRAG as a query layer over AKG, not as a substitute for AKG.

A good rule is simple. Use GraphRAG after you have a graph worth retrieving from.

7. Why Graph Data Science matters after graph construction

This is where many GraphRAG discussions still underplay the graph.

Once the AKG exists, Graph Data Science (GDS), becomes more than an optional extra. It becomes the bridge between graph structure and operational scoring.

For financial documents and reports, GDS is useful in several ways. Centrality can highlight entities or obligations that disproportionately influence downstream reporting or exposure. Community detection can surface structural clusters in counterparties, obligations, risks, or disclosure topics beyond text-only grouping. Similarity and embedding methods can help rank neighbourhood relevance, detect duplicate entities, or identify concept drift. Anomaly detection can surface unusual disclosure connectivity patterns, suspicious control gaps, or unexpected changes in corporate structure.

For an LPG practitioner, the practical point is simple: do not stop at retrieval. Run graph algorithms on the same operational graph and feed the results back into ranking, monitoring, and analyst workflows.

8. A practical LPG schema for filings, notes, facts, controls and obligations

This model is intentionally operational.

FACT is not just an attribute on a node. It is a first-class object with provenance, period, unit, dimensionality, and lineage back to the filing.

TEXT_UNIT is not a disposable chunking. It is the provenance spine of the whole system.

OWNS, ISSUES, FACT_OF, EVIDENCED_BY, and AFFECTS are high-value relationships because they are the basis for both traversal and analytics.

That is the LPG advantage in practice. Relationships are not metadata around the model. They are the model.

9. Code examples

9.1 Cypher for consolidation scope and revenue roll-up

MATCH (parent:LegalEntity {cik: $cik})
MATCH p = (parent)-[r:OWNS*1..6]->(sub:LegalEntity)
WHERE ALL(rel IN r WHERE rel.pct >= 0.5 AND rel.validFrom <= date($asOf))
WITH DISTINCT sub
MATCH (sub)<-[:FACT_OF]-(f:Fact)-[:HAS_CONCEPT]->(:Concept {code: “Revenue”})
MATCH (f)-[:HAS_PERIOD]->(per:Period {kind: “annual”})
RETURN sub.name AS subsidiary,
       per.endDate AS period_end,
       f.value AS revenue,
       f.unit AS unit
ORDER BY revenue DESC

This is the sort of query LPG handles very naturally: recursive ownership, fact retrieval, and time constraint in one traversal-oriented pattern.

9.2 Cypher for obligation-to-evidence traversal

MATCH (o:Obligation {id: $obligationId})-[:MITIGATED_BY]->(c:Control)
MATCH (c)-[:EVIDENCED_BY]->(tu:TextUnit)<-[:CHUNKED_INTO]-(s:Section)<-[:CONTAINS]-(f:Filing)
RETURN o.name AS obligation,
       c.name AS control,
       f.form AS filing_form,
       s.title AS section,
       tu.text AS evidence
ORDER BY f.filedAt DESC

This is a better fit than vector-only retrieval because the answer is inherently path-based.

9.3 A GraphRAG workflow that respects financial structure

1. Parse Inline XBRL and preserve tagged facts as authoritative objects
2. Convert document layout with table-aware chunking
3. Resolve entities to external and internal identifiers
4. Populate LPG with provenance and validity intervals
5. Run GDS for centrality, communities, and anomaly signals
6. Build GraphRAG artefacts over graph plus text units
7. Route query:
   - fact-first for numeric questions
   - Local Search for entity-centred investigations
   - Global Search for corpus-wide themes
   - DRIFT Search for audit or compliance exploration

This sequencing matters. It matches the structure of financial reporting instead of pretending retrieval is the primary design decision.

10. What to measure in production

A finance-grade system should be evaluated as a pipeline, not a demo.

Table extraction should be measured for structural fidelity. Retrieval should be measured for context precision and recall. Generation should be measured for faithfulness and hallucination risk. Finance-specific question answering should also be benchmarked against tasks that require mixed table-plus-text reasoning.

The more important point, though, is architectural. If your evaluation only measures answer quality, you will not know which layer failed. In practice, financial AKG systems need separate checks for parsing fidelity, graph quality, schema compliance, temporal correctness, retrieval coverage, and answer faithfulness.

11. Common failure modes

The biggest failure mode is confusing semantic richness with operational readiness.

A graph can look sophisticated long before it becomes useful. A large model with many labels and relationships may still fail to support reliable traversal, stable identity, explainable evidence paths, or repeatable decision workflows. In financial document intelligence, the test is not whether the graph looks expressive. The test is whether it works under real investigative pressure.

A second failure mode is treating table extraction as a commodity step. In financial reporting, table errors are graph errors. Broken headers, fractured rows, and lost footnote references lead directly to broken facts, broken evidence chains, and broken retrieval.

A third failure mode is flattening time. Financial meaning is period-sensitive, event-sensitive, and validity-sensitive. If ownership, controls, facts, or obligations are modelled as if they were timeless, the graph becomes easy to query but hard to trust.

A fourth failure mode is weak entity resolution. If the same issuer, subsidiary, instrument, or business unit appears under multiple unresolved identities, the graph fragments. Traversals become incomplete, analytics become unreliable, and GraphRAG assembles context from only part of the real picture.

A fifth failure mode is poor provenance design. In finance, a correct answer without traceable evidence is still weak. If facts and relationships cannot be traced back to filing sections, text units, tables, or extraction steps, trust collapses quickly.

A sixth failure mode is uncontrolled schema drift. As more pipelines and use cases are added, labels and relationships can multiply without discipline. The graph becomes noisier, queries become harder to maintain, and retrieval quality declines.

A seventh failure mode is expecting GraphRAG to repair poor graph design. It cannot. GraphRAG amplifies graph quality, good or bad. If the AKG is weak, GraphRAG simply makes the weakness harder to inspect because the answer still sounds fluent.

An eighth failure mode is stopping at retrieval and leaving graph analytics out of the loop. If the graph only helps users find evidence, but never computes centrality, concentration, similarity, or anomaly signals, then much of the graph’s operational value is left unused.

12. Closing view

For financial document intelligence, the most productive framing is not graph versus retrieval-augmented generation, and not even knowledge graph versus GraphRAG.

It is this:

authoritative structured facts + applied LPG knowledge graph + graph data science + graph-grounded retrieval

That stack is far better suited to financial reports than a chunk-first approach because it respects what the material actually is: a dense network of facts, entities, controls, obligations, events, and dependencies spread across time.

Ontology and taxonomy remain essential where semantic discipline and interoperability matter. But when the goal is to build systems that investigate, traverse, rank, detect, and support decisions over financial reporting, LPG is a strong operational backbone. That is not a philosophical preference. It is an architectural judgement shaped by the workload.

1. Introduction

2. The Nature of Time in Legal Documents

3. Why Naive GraphRAG Fails Without Temporal Context

4. Temporal Modelling in Labelled Property Graphs (LPG)

5. Applied Knowledge Graph (AKG) Design for Legal Time

6. Querying for Point-in-Time Accuracy in GraphRAG

7. Integrating Temporal Reasoning into Large Language Model Pipelines

8. Implementation Patterns and Practical Trade-offs

9. RDF-based Knowledge Graphs versus LPG-based Applied Knowledge Graphs

10. Why the Term “Context Graph” is Misleading

11. Conclusion

1. Introduction

Legal documents are fundamentally temporal, and each clause, amendment, and reference carries a time dimension that is critical for legal reasoning. Contracts evolve over time, obligations expire, and regulations are amended retroactively. Despite this, many GraphRAG implementations treat legal knowledge bases as static, ignoring temporal constraints. This can result in outputs that are linguistically plausible but factually inaccurate.

For example, asking, “Was Clause 14 of Contract X valid in March 2021?” requires a system that can determine which clauses existed and were effective at that exact point in time. Without explicit temporal modelling, retrieved content may reflect outdated or future clauses, rendering the answer legally unsound.

Labelled Property Graphs (LPGs) offer the ability to attach properties—including temporal attributes—to nodes and relationships. Applied Knowledge Graphs (AKGs) further operationalise this structure by embedding rules, constraints, and retrieval logic to ensure point-in-time determinism. When integrated with GraphRAG, these structures provide temporally accurate, legally defensible context for LLMs.

Temporal modelling must account for three primary aspects: validity intervals, defining when a clause or contract is effective; transaction times, capturing when a record was stored; and event times, marking when legal actions such as amendments occurred. Explicit representation of these times transforms a graph from a passive archive into a powerful operational tool for legal queries.

2. The Nature of Time in Legal Documents

Legal documents are more than static text; they are instruments whose applicability evolves across multiple temporal dimensions. Each clause, amendment, or reference can involve valid time, transaction time, and event time.

• Valid Time reflects the period during which a legal statement is effective. For instance, a confidentiality clause may commence on the signing date and expire on contract termination.

• Transaction Time records when a change is stored or registered, which is critical for auditing, compliance, and provenance.

• Event Time corresponds to when a legal action, such as signing an amendment, actually occurs. Event time may differ from valid time, especially in retroactive amendments.

For illustration, consider a contract scenario:

Contract Signed: 1 January 2020 (Event Time)
Clause Effective: 1 March 2020 (Valid Time)
Amendment Passed: 1 June 2021 (Event Time)
Amendment Retroactive Validity: 1 April 2021 (Valid Time)

Here, the validity of the clause at a query date may not align with either the original signing date or the amendment date, highlighting the need for precise temporal modelling. Overlapping validity periods and retroactive changes add further complexity. Legal structures contain hierarchical timelines: contract-level, clause-level, and relationship-level. Queries that ignore these hierarchies risk returning semantically correct but temporally invalid information.

In GraphRAG, temporal modelling ensures that point-in-time queries return deterministic, auditable results. This enables compliance-grade answers and prevents the generation of misleading LLM outputs.

3. Why Naive GraphRAG Fails Without Temporal Context

GraphRAG pipelines typically combine semantic vector similarity with graph traversal. While sufficient for domains with static knowledge, this approach fails in legal reasoning. Without temporal filtering, retrieved clauses may originate from periods that are inconsistent with the query, producing outputs that are plausible but incorrect.

For example, querying, “Which clauses governed liability for Contract X in April 2021?” may return:

• Original clauses from 2020

• Amendments from 2022

• Commentary from 2023

An LLM synthesising this data might produce a hybrid answer that combines clauses across periods, which is legally invalid. The failure here is not semantic but temporal: traversal alone cannot enforce valid-time constraints. Therefore, naive GraphRAG lacks determinism and compliance guarantees.

4. Temporal Modelling in Labelled Property Graphs (LPG)

Labelled Property Graphs provide flexibility to model temporality explicitly. Nodes and relationships can carry valid_from and valid_to properties, allowing traversal queries to filter entities active at a specific time.

Example Clause Node:

CREATE (c:Clause {id: ‘C14’, valid_from: date(’2020-03-01’), valid_to: date(’2021-06-01’)})

Versioned Clause Modelling:

CREATE (clause:Clause {id: ‘C14’})
CREATE (v1:ClauseVersion {version: 1, valid_from: date(’2020-03-01’), valid_to: date(’2021-06-01’)})
CREATE (clause)-[:HAS_VERSION]->(v1)
CREATE (event:AmendmentEvent {date: date(’2021-06-01’), description: ‘Amendment to C14’})
CREATE (v1)-[:AMENDED_BY]->(event)

Event-based modelling allows the system to represent amendments and other legal events as nodes connected to clause versions, capturing both sequence and causality.

Querying clauses valid on a specific date:

MATCH (v:ClauseVersion)
WHERE v.valid_from <= date(’2021-04-01’) AND (v.valid_to IS NULL OR v.valid_to > date(’2021-04-01’))
RETURN v

This query guarantees deterministic point-in-time retrieval. Immutability, explicit intervals, versioning, and consistency are crucial: amendments should not overwrite nodes but create new versions, ensuring historical integrity.

5. Applied Knowledge Graph (AKG) Design for Legal Time

Applied Knowledge Graphs operationalise the temporal structure of LPGs. They prioritise decision-readiness over mere semantic storage. Contract, clause, and party entities are versioned, and relationships carry validity intervals, enabling queries that reflect the system’s state at any point in time.

Each contract node may have multiple ContractVersion nodes, each linked to ClauseVersion nodes. ClauseVersion nodes connect to textual representations or document paragraphs. This design ensures that GraphRAG pipelines retrieve both structured and textual information that is temporally consistent.

AKG example with text linkage:

CREATE (contract:Contract {id:’CX’})
CREATE (cver:ContractVersion {version:’V1’, valid_from: date(’2020-01-01’), valid_to: date(’2021-06-01’)})
CREATE (contract)-[:HAS_VERSION]->(cver)
CREATE (clause:Clause {id:’C14’})
CREATE (clver:ClauseVersion {valid_from: date(’2020-03-01’), valid_to: date(’2021-06-01’)})
CREATE (clause)-[:HAS_VERSION]->(clver)
CREATE (clver)-[:LINKED_TEXT]->(:TextChunk {doc_id:’doc123’, paragraph:14})

This structure allows deterministic retrieval for GraphRAG, ensures auditable history, and supports compliance-grade decision-making.

6. Querying for Point-in-Time Accuracy in GraphRAG

Point-in-time querying ensures the retrieved subgraph represents the world as it existed at a specific date.

Steps

1. Extract time parameter from user query

2. Filter nodes and relationships by validity intervals

3. Resolve conflicts between overlapping versions

4. Collect linked textual content for GraphRAG

Example Workflow

• Query: “What clauses were valid for Contract X in April 2021?”

• Graph Query: Filter ClauseVersions with
  valid_from <= ‘2021-04-01’ AND (valid_to IS NULL OR valid_to > ‘2021-04-01’)

• GraphRAG Retrieval: Collect linked text chunks

• LLM Input: Only temporally valid clauses

Optimisations

• Materialised snapshots: Precompute frequently queried time points

• Temporal indices: Ensure queries scale with large legal corpora

• Conflict resolution rules: Determine precedence when multiple versions overlap

Correct point-in-time retrieval reduces ambiguity, prevents misleading LLM outputs, and ensures compliance-grade answers.

7. Integrating Temporal Reasoning into Large Language Model Pipelines

Large Language Models (LLMs) cannot reliably infer temporal validity. Integration must externalise temporal reasoning to the graph retrieval layer.

Integration Steps

1. Temporal intent extraction: Identify relevant dates or periods from query

2. Graph filtering: Retrieve only temporally valid nodes/relationships

3. Context construction: Build LLM input using deterministic, temporally scoped subgraph

4. Prompt design: Explicitly reference time, e.g., “Based on Contract X as of 1 April 2021…”

Additional Techniques

• Include version IDs and validity intervals in LLM context

• Provide amendment metadata to improve traceability

• Optionally enforce symbolic rules to guide retrieval and LLM reasoning

This hybrid approach allows LLMs to focus on synthesis, not temporal inference, which is unreliable in purely generative models.

8. Implementation Patterns and Practical Trade-offs

RDF is widely used for semantic knowledge graphs. It provides formal logic foundations and standardised modelling. Temporal modelling in RDF often relies on:

• Reification of triples with attached temporal properties

• Named graphs to scope validity

• OWL-Time ontology for interval representation

Limitations for Legal GraphRAG

• Queries are more complex and less performant than LPG

• Graph traversal and temporal filtering require reasoning engines or SPARQL rules

• Readability and maintainability are reduced for operational teams

Advantages of LPG-based AKG

• Temporal attributes attached directly to nodes/edges

• Point-in-time queries are concise and efficient

• GraphRAG integration is simpler and more predictable

Example:

(:ClauseVersion {valid_from: date1, valid_to: date2})

LPG-based AKGs better align with enterprise operational needs, ensuring deterministic retrieval and minimal latency, critical for legal compliance systems.

9. RDF-based Knowledge Graphs versus LPG-based Applied Knowledge Graphs

RDF provides a formally defined model for representing knowledge as triples, consisting of subject, predicate, and object. This model is well suited for semantic interoperability, ontology-driven systems, and environments where logical inference and standardisation are primary concerns. In theory, RDF is capable of representing temporal information, but it does not natively support properties on relationships or statements. This limitation becomes particularly relevant when modelling temporal validity in legal documents.

To represent temporal aspects in RDF, additional modelling constructs must be introduced. One common approach is reification, where a statement is transformed into a resource that can then be annotated with temporal properties. Another approach is the use of named graphs, where a set of triples is grouped and associated with metadata such as validity intervals. A more formal approach involves ontologies such as OWL-Time, which define temporal entities and relationships.

A simplified example of RDF reification for a clause validity statement might look as follows:

:stmt1 rdf:type rdf:Statement .
:stmt1 rdf:subject :c14 .
:stmt1 rdf:predicate ex:isValid .
:stmt1 rdf:object true .
:stmt1 ex:validFrom “2020-03-01”^^xsd:date .
:stmt1 ex:validTo “2021-06-01”^^xsd:date .

While this is technically correct, it introduces structural overhead. A single business fact now requires multiple triples and an intermediate node. When scaled across thousands of clauses, amendments, and relationships, this leads to a graph that is significantly more complex to query and maintain.

Named graphs provide an alternative:

GRAPH :validity_2020_2021 {
:c14 ex:isValid true .
}
:validity_2020_2021 ex:validFrom “2020-03-01”^^xsd:date .
:validity_2020_2021 ex:validTo “2021-06-01”^^xsd:date .

However, this approach shifts complexity to query construction. SPARQL queries must explicitly reference graph scopes and temporal metadata, which complicates both development and optimisation.

In contrast, Labelled Property Graphs allow temporal attributes to be attached directly to nodes and relationships. This provides a more direct mapping between the business concept and its representation.

Equivalent LPG representation:

(:ClauseVersion {
id: ‘C14_v1’,
valid_from: date(’2020-03-01’),
valid_to: date(’2021-06-01’)
})

This difference is not merely syntactic. It has several practical consequences for enterprise GraphRAG systems.

First, query complexity is significantly reduced. In LPG, temporal filtering can be expressed as a simple predicate on properties. In RDF, the same query often requires joins across multiple triples, graph scopes, or reified statements.

Second, performance characteristics differ. LPG engines are optimised for traversal with property filtering, which aligns well with point-in-time queries. RDF systems often rely on SPARQL query planning and optional reasoning layers, which can introduce latency, especially in large graphs.

Third, maintainability becomes a critical factor. Engineering teams working with LPG models can reason about the graph structure more intuitively because it aligns closely with domain concepts such as “clause version” or “valid interval”. RDF models, while semantically rich, often require a deeper understanding of ontologies and modelling patterns, which can slow down development in operational environments.

From a GraphRAG perspective, the most important distinction is deterministic retrieval. LPG-based Applied Knowledge Graphs allow temporal constraints to be embedded directly in traversal queries that feed the retrieval pipeline. This ensures that the subgraph provided to the Large Language Model (LLM) is already temporally consistent.

In RDF-based systems, achieving the same level of determinism often requires additional reasoning steps or carefully constructed SPARQL queries. This introduces variability in execution time and increases the risk of incomplete or inconsistent retrievals if queries are not precisely defined.

It is important to emphasise that RDF is not unsuitable for temporal modelling. It is capable, but the cost of expressiveness is complexity. For use cases where formal semantics and interoperability are the primary goals, RDF remains a strong choice. However, in enterprise GraphRAG scenarios focused on performance, determinism, and operational simplicity, LPG-based Applied Knowledge Graphs provide a more pragmatic foundation.

10. Why the Term “Context Graph” is Misleading

The term “Context Graph” has gained popularity in discussions around GraphRAG and Large Language Models. It is often used to describe a graph that provides additional information to support generation. While the term is intuitively appealing, it lacks precise technical meaning and introduces ambiguity when applied to temporal legal reasoning.

The core problem is that “context” is not a well-defined construct in graph modelling. It is typically used as a catch-all term that combines several distinct concerns, including structural relationships, relevance to a query, temporal validity, and provenance of information. Treating these as a single concept obscures the actual requirements for building reliable systems.

In legal GraphRAG, the distinction between context and state is critical. Context is often interpreted as a collection of related information that may help answer a question. State, on the other hand, is a precise and consistent representation of the system at a specific point in time.

A “context graph” in practice often includes:

• Historical versions of clauses

• Current active clauses

• Future amendments

• Commentary or annotations

If such a graph is provided to an LLM without temporal filtering, the model receives conflicting signals. For example, a clause that was valid in 2020 and another that replaced it in 2022 may both appear relevant from a semantic perspective. The LLM may then produce an answer that blends these versions, resulting in a response that is coherent but incorrect.

This is not a limitation of the LLM alone. It is a failure of the retrieval layer to provide a consistent input. The LLM operates on the assumption that the provided context is internally consistent. When that assumption is violated, the output cannot be trusted.

To illustrate the issue, consider the difference between two retrieval strategies.

A context-driven approach might execute a query such as:

MATCH (c:Clause)-[:HAS_VERSION]->(v)
WHERE c.id = ‘C14’
RETURN v

This query retrieves all versions of a clause, regardless of their temporal validity. The result is a “context graph” containing multiple, potentially conflicting states.

A state-driven approach introduces temporal constraints:

MATCH (c:Clause)-[:HAS_VERSION]->(v)
WHERE c.id = ‘C14’
AND v.valid_from <= date(’2021-04-01’)
AND (v.valid_to IS NULL OR v.valid_to > date(’2021-04-01’))
RETURN v

This query constructs a point-in-time subgraph, representing the state of the clause at a specific date. The result is deterministic and free of temporal conflicts.

The difference between these two approaches is fundamental. The first relies on the LLM to interpret context and resolve inconsistencies, which it is not designed to do reliably. The second ensures that the input to the LLM is already consistent, allowing the model to focus on synthesis rather than validation.

Another issue with the term “Context Graph” is that it encourages under-modelling. Teams may assume that building a loosely connected graph of related entities is sufficient, without investing in proper temporal modelling, versioning, or validity constraints. This leads to systems that appear to work in simple scenarios but fail under real-world conditions where temporal precision is required.

In enterprise legal applications, this is not acceptable. Queries must be auditable, reproducible, and legally defensible. This requires:

• Explicit modelling of temporal validity

• Deterministic filtering of nodes and relationships

• Clear separation between historical, current, and future states

A more accurate description of what GraphRAG requires is not a “context graph” but a temporally scoped subgraph derived from an Applied Knowledge Graph. This subgraph represents the exact state of the system relevant to the query and serves as the input to the LLM.

Only after this deterministic state is constructed does it become meaningful to refer to the result as context. At that point, context is not a loosely defined collection of information, but a precisely defined dataset that satisfies temporal and structural constraints.

In summary, the term “Context Graph” is misleading because it hides the complexity of temporal reasoning and shifts responsibility to the wrong component. Reliable legal GraphRAG systems are built not on vague notions of context, but on explicit modelling of state, enforced through deterministic retrieval.

11. Conclusion

The central requirement in legal GraphRAG is not relevance, but correctness at a specific point in time. Every query implicitly or explicitly asks for the state of the legal domain at a given date. If temporal semantics are not enforced, the system will return outputs that are linguistically coherent but legally incorrect.

The key idea is straightforward. GraphRAG must not retrieve “relevant context” in a general sense. It must construct a temporally consistent subgraph, representing only the clauses, relationships, and documents that were valid at the requested time. This subgraph is the only acceptable input for a Large Language Model (LLM).

From this perspective, the role of the graph is to guarantee correctness, while the role of the LLM is limited to synthesis and explanation. Any attempt to shift temporal reasoning into the LLM leads to ambiguity and unreliable outputs.

The comparison between RDF-based Knowledge Graphs and Labelled Property Graph based Applied Knowledge Graphs reinforces this. RDF can model temporal semantics, but often at the cost of complexity, query overhead, and reduced operational clarity. LPG-based AKGs provide a more direct and efficient way to encode validity intervals and execute point-in-time queries, which is critical for GraphRAG pipelines in enterprise environments.

The same principle applies to the notion of a “Context Graph”. This term is misleading because it suggests that collecting related information is sufficient. In legal use cases, it is not. What matters is not context, but state. A graph that includes multiple temporal versions without filtering is not useful input, it is a source of error.

The correct pattern is therefore:

• Encode temporal validity explicitly in the graph

• Enforce time constraints during retrieval

• Construct a deterministic, point-in-time subgraph

• Use this subgraph as the sole input to the LLM

When this pattern is applied, GraphRAG produces outputs that are temporally accurate, auditable, and suitable for legal and compliance use. Without it, the system remains a semantic search tool with no guarantees of correctness.

1. Introduction

2. The Semantic Web Assumption About Meaning

3. How Ontologies Encode Semantics in RDF Systems

4. Why LLM Systems Do Not Execute Ontological Semantics

5. Graphs in AI Pipelines: Context Instead of Logical Closure

6. Labelled Property Graphs as Operational Semantic Substrates

7. The Rise of the Applied Knowledge Graph

8. Why Ontology-Heavy Systems Struggle in Artificial Intelligence Architectures

9. Graph Summarisation Instead of Logical Inference

10. The Architectural Shift in Enterprise Graph Systems

11. Questions from RDF Practitioners

12. Conclusion

1. Introduction

For more than two decades the architecture of the Semantic Web has been built around a powerful and elegant idea. If knowledge can be expressed through formal ontologies, machines will be able to derive meaning through logical reasoning. In this vision a knowledge graph functions as a logical knowledge base. Ontologies define the conceptual structure of the domain and reasoning engines derive additional knowledge from those definitions.

This paradigm shaped the ecosystem around the Resource Description Framework (RDF). RDF provides the structural data model for representing information as triples. RDF Schema (RDFS) and the Web Ontology Language (OWL) extend that model with constructs for expressing semantic relationships. Reasoners analyse the ontology and derive new facts that logically follow from the model.

The emergence of modern artificial intelligence systems, particularly large language models (LLMs), introduces a different computational paradigm. These systems do not reason through symbolic logic. Instead, they interpret patterns and relationships through probabilistic models trained on large corpora of text and code.

As a consequence the role of knowledge graphs in data architectures is changing. In many AI systems graphs function less as logical inference engines and more as structured contextual memory. Their primary value lies in organising relationships so that downstream systems, including LLMs, can interpret them.

This shift has important implications for how knowledge graphs are designed and deployed. In practice the Labelled Property Graph (LPG) model and the emerging architecture of the Applied Knowledge Graph (AKG) align naturally with modern AI pipelines. Their emphasis on relationships, flexible modelling and operational querying supports the dynamic environments in which contemporary AI systems operate.

The argument presented here is not that RDF is obsolete. Rather, it is that the assumptions about where meaning resides in a knowledge system are evolving in the era of LLM-driven architectures.

2. The Semantic Web Assumption About Meaning

The original vision of the Semantic Web rests on a foundational assumption: meaning can be encoded explicitly in formal ontologies. If the conceptual structure of a domain is described precisely enough, machines can derive new knowledge from existing information through logical reasoning.

This idea originates in symbolic artificial intelligence. In symbolic systems knowledge is represented as logical statements and inference engines manipulate those statements according to formal rules.

In the RDF ecosystem, ontologies express domain knowledge through classes, relationships and constraints. Hierarchical relationships between classes allow reasoning engines to infer implicit knowledge.

For example:

:Animal rdf:type owl:Class .
:Mammal rdf:type owl:Class .
:Dog rdf:type owl:Class .

:Mammal rdfs:subClassOf :Animal .
:Dog rdfs:subClassOf :Mammal .

If a knowledge graph contains the statement:

:Fido rdf:type :Dog .

a reasoner can derive the following implicit facts:

:Fido rdf:type :Mammal .
:Fido rdf:type :Animal .

The ontology therefore defines the conceptual structure of the domain, and the reasoning engine derives new knowledge that logically follows from that structure.

This model works well in domains where conceptual structures are stable and precisely defined. Biomedical ontologies, taxonomies of organisms and regulatory classifications often benefit from formal reasoning.

However the same approach becomes more challenging in dynamic enterprise environments where data sources change frequently and new relationships appear continuously.

3. How Ontologies Encode Semantics in RDF Systems

Ontologies encode semantics through several structural mechanisms that together form the conceptual framework of a domain.

The most fundamental mechanism is the class hierarchy. Classes represent conceptual categories and subclass relationships define how those categories relate to one another.

:Vehicle rdf:type owl:Class .
:Car rdf:type owl:Class .
:ElectricCar rdf:type owl:Class .

:Car rdfs:subClassOf :Vehicle .
:ElectricCar rdfs:subClassOf :Car .

Properties describe the relationships that can exist between entities.

:manufacturedBy rdf:type owl:ObjectProperty .
:manufacturedBy rdfs:domain :Vehicle .
:manufacturedBy rdfs:range :Company .

Logical restrictions allow ontologies to specify more precise semantic conditions.

:ElectricCar rdfs:subClassOf [
  rdf:type owl:Restriction ;
  owl:onProperty :energySource ;
  owl:hasValue :Electricity
] .

A reasoning engine analyses these constructs and derives implicit knowledge that follows logically from the ontology.

This approach offers strong guarantees about consistency and formal semantics. However it also introduces modelling overhead. Ontologies must be carefully designed, governed and maintained. Changes in the conceptual model can propagate across the system and require recomputation of inferred knowledge.

4. Why LLM Systems Do Not Execute Ontological Semantics

Large language models operate according to a fundamentally different computational paradigm than ontology reasoning systems. Ontology reasoners belong to the tradition of symbolic artificial intelligence, where knowledge is represented through formal logical axioms and conclusions are derived through deterministic inference rules. Large language models belong to the paradigm of statistical machine learning, where meaning emerges from patterns in large datasets rather than from explicit symbolic rules.

Ontology reasoning operates through strict logical evaluation. Given a set of axioms and facts, the system determines whether a statement logically follows.

Consider the following ontology fragment:

:Person rdf:type owl:Class .
:Employee rdf:type owl:Class .

:Employee rdfs:subClassOf :Person .

:Alice rdf:type :Employee .

A reasoning engine deterministically derives the statement:

:Alice rdf:type :Person .

The conclusion follows directly from the ontology.

An LLM answering a question about Alice may produce the same answer, but for a different reason. It does not execute the subclass rule. Instead it recognises a common linguistic pattern: employees are people. The answer emerges from statistical associations learned during training rather than from formal logical inference.

In modern AI architectures knowledge graphs therefore serve a different role. Rather than acting as logical theorem provers, they function as structured context providers.

A typical AI pipeline may operate as follows:

1. A user question is received.

2. Relevant entities are identified.

3. Graph queries retrieve connected relationships.

4. The retrieved information becomes context for the prompt.

5. The LLM interprets that context and generates an answer.

In this architecture the graph provides structured information while the language model performs semantic interpretation.

Many OWL constructs are effectively invisible to LLMs unless they are translated into textual explanations. For example the following OWL restriction expresses a formal rule:

:ElectricCar rdfs:subClassOf [
  rdf:type owl:Restriction ;
  owl:onProperty :energySource ;
  owl:hasValue :Electricity
] .

A reasoner can infer that every electric car uses electricity as an energy source. A language model will not automatically execute this rule unless the relevant context is explicitly included in the prompt.

For AI systems the practical consequence is that the graph primarily provides structure. The interpretation of meaning often occurs within the language model.

5. Graphs in AI Pipelines: Context Instead of Logical Closure

Traditional Semantic Web architectures aim to compute logical closure. If a fact can be derived from the ontology and the stored triples, the reasoning engine should eventually infer it.

AI pipelines rarely pursue this objective. Instead they focus on retrieving the most relevant contextual information for a particular question.

A typical query retrieves a local neighbourhood within the graph rather than computing all possible inferences.

MATCH (drug:Drug)-[:TREATS]->(disease:Disease)
MATCH (drug)-[:HAS_SIDE_EFFECT]->(effect)
WHERE disease.name = “Hypertension”
RETURN drug, disease, effect

The result is a contextual subgraph describing drugs, diseases and side effects.

This structure becomes input for the language model, which interprets the relationships and generates a response.

The graph therefore functions as structured memory while the LLM performs semantic interpretation.

6. Labelled Property Graphs as Operational Semantic Substrates

The Labelled Property Graph model represents knowledge through nodes, relationships, labels and properties.

Nodes represent entities. Relationships connect those entities. Labels classify nodes, and properties attach attributes to nodes or relationships.

CREATE (p:Person {name: “Alice”})
CREATE (c:Company {name: “Neo Systems”})
CREATE (p)-[:WORKS_FOR {since: 2021}]->(c)

The semantics of the graph emerge from the structure of these relationships.

Labels act as lightweight semantic anchors. They provide enough information for graph queries and AI models to interpret entities without requiring a fully formalised ontology.

This model is particularly well suited for operational environments where the data model evolves over time. New relationship types can be introduced without redesigning a global ontology.

7. The Rise of the Applied Knowledge Graph

The concept of the Applied Knowledge Graph (AKG) reflects a shift from purely semantic modelling toward operational problem solving. Instead of attempting to represent an entire domain through formal ontologies, an Applied Knowledge Graph focuses on representing relationships that directly support analytics, decision making and artificial intelligence workflows.

Traditional knowledge graph initiatives often begin with ontology design. Domain experts define classes, properties and conceptual hierarchies before operational data is integrated. The result may be conceptually elegant but difficult to evolve when new requirements appear.

AKG reverse this sequence. They begin with operational questions.

• Which suppliers are connected to which factories?

• Which customers interact with which products?

• Which transactions link financial entities?

Relationships, therefore, become the primary modelling construct.

Consider a logistics network:

CREATE (s:Supplier {name:”Global Steel”})
CREATE (p:Product {name:”Industrial Beam”})
CREATE (f:Factory {name:”Rotterdam Plant”})

CREATE (s)-[:SUPPLIES]->(p)
CREATE (p)-[:PRODUCED_AT]->(f)

This structure immediately supports supply chain analysis. Analysts can trace the path from supplier to product to factory.

If geopolitical risk becomes relevant the graph can evolve incrementally.

CREATE (s)-[:LOCATED_IN]->(:Region {name:”Eastern Europe”, riskLevel:”High”})

Now analysts can identify factories exposed to geopolitical risk through their suppliers.

Similar patterns appear in fraud detection, recommendation systems and customer analytics. Across these domains the graph grows organically as new relationships become relevant.

This operational orientation explains why property graph technology dominates many real-world deployments of knowledge graphs.

8. Why Ontology-Heavy Systems Struggle in Artificial Intelligence Architectures

Ontology-centric architectures assume that the conceptual structure of a domain can be stabilised through careful modelling. Classes and properties are defined once and reused across the system.

AI environments rarely behave this way. Data pipelines continuously introduce new sources of information. AI agents may generate new relationship types that were not anticipated when the ontology was designed. Under these conditions ontology governance can become a constraint on system evolution. Each conceptual change may require ontology updates, validation and recomputation of inferred knowledge. This process can slow down experimentation and integration in rapidly evolving AI environments.

By contrast AI pipelines emphasise rapid retrieval of contextual information. Graph queries must execute quickly so that relevant context can be assembled for downstream models.

Property graph databases are optimised for relationship traversal and pattern matching. These capabilities align naturally with AI workloads that rely on exploring connections between entities.

9. Graph Summarisation Instead of Logical Inference

Graph summarisation is becoming an important technique in modern AI-driven graph systems. Rather than computing every possible logical inference, the system constructs a concise representation of the relevant region of the graph.

Large enterprise graphs may contain millions or billions of entities. Full logical reasoning over such structures is rarely necessary for answering a specific question.

Graph summarisation focuses on extracting a meaningful subgraph that captures the essential relationships surrounding an entity or event.

Consider a corporate analysis scenario:

MATCH (c:Company {name:”Atlas Holdings”})
OPTIONAL MATCH (c)-[:OWNS]->(subsidiary)
OPTIONAL MATCH (c)-[:HAS_SUPPLIER]->(supplier)
OPTIONAL MATCH (c)-[:OPERATES_IN]->(region)
RETURN c, collect(subsidiary), collect(supplier), collect(region)

This query produces a structural summary of the company’s network.

Graph algorithms can enrich this summary further by identifying communities, influential nodes or important paths.

Once the summary is assembled it becomes context for an AI model. The language model interprets the relationships and generates explanations.

In many modern AI architectures this workflow becomes the practical alternative to heavy logical reasoning.

9.1 Example: Ontology Reasoning vs Context Graph Reasoning

The difference between ontology reasoning and contextual graph reasoning becomes clearer through practical examples.

Consider a regulatory risk scenario. An organisation must identify companies whose supply chains depend on suppliers located in politically unstable regions.

An ontology-driven approach might encode rules describing supplier relationships, geographic hierarchies and risk classifications. A reasoning engine would evaluate these rules to derive indirect relationships.

A property graph approach can often express the same analysis through a structural query.

MATCH (supplier:Supplier)-[:LOCATED_IN]->(region:Region)
MATCH (company:Company)-[:DEPENDS_ON]->(supplier)
WHERE region.riskLevel = “High”
RETURN company, supplier, region

The result is a contextual subgraph describing the relationship between companies, suppliers and regions.

A language model can interpret this structure and generate a narrative explanation describing the supply chain risk.

A similar approach appears in financial investigations. Transaction graphs allow analysts to identify suspicious patterns such as circular money flows.

MATCH (a1:Account)-[:TRANSFERRED_TO]->(a2)
MATCH (a2)-[:TRANSFERRED_TO]->(a3)
MATCH (a3)-[:TRANSFERRED_TO]->(a1)
RETURN a1, a2, a3

The graph identifies structural patterns while the AI system interprets them.

10. The Architectural Shift in Enterprise Graph Systems

Modern enterprise graph architectures increasingly follow a layered design.

At the foundation lies the graph database. In many operational deployments this layer uses the Labelled Property Graph model because it supports efficient relationship traversal and flexible schema evolution.

Above the database sits the graph processing layer, which includes algorithms for community detection, centrality analysis and path finding.

The next layer retrieves and summarises contextual subgraphs relevant to a particular question.

Finally an artificial intelligence layer interprets the retrieved structure and produces explanations or insights.

In this architecture semantics emerge from the interaction between graph structure and AI interpretation rather than being derived exclusively from formal ontologies.

11. Questions from RDF Practitioners

Where does meaning come from if there is no ontology?

In operational graph systems meaning often emerges from the structure of relationships rather than from explicit axioms.

CREATE (p:Product {name:”Battery Pack”})
CREATE (c:Component {name:”Lithium Cell”})
CREATE (p)-[:CONTAINS]->(c)

Even without a formal ontology the relationship expresses a clear dependency between entities.

Language models interpret such relationships easily because they resemble natural language expressions.

How is interoperability preserved?

Many systems combine RDF identifiers with property graph structures.

CREATE (:Product {uri:”http://example.com/product/123”})

The graph retains global identifiers while supporting operational queries.

What about logical consistency?

Operational systems often enforce constraints through data pipelines and validation rules.

For example:

MATCH (p:Product)-[:BELONGS_TO]->(c:Category)
RETURN p, count(c)

Validation rules ensure each product belongs to one category.

Are RDF knowledge graphs becoming obsolete?

No. RDF continues to play an important role in data integration, vocabulary definition and linked data publication.

However operational analytics and AI systems increasingly rely on graph models optimised for traversal and contextual retrieval.

12. Conclusion

The Semantic Web introduced the idea that machines could understand meaning through formal ontologies and logical reasoning. This vision produced a rich ecosystem of semantic technologies.

The rise of artificial intelligence systems, particularly large language models, introduces a different architectural paradigm.

In many modern systems graphs act as structured context for AI models rather than as engines of formal inference.

The Labelled Property Graph model and the architecture of the Applied Knowledge Graph align naturally with this approach. They emphasise relationships, flexible modelling and operational querying.

Meaning in these systems emerges from the interaction between graph structure and AI interpretation.

For practitioners, this represents not the end of semantic technologies but the evolution of knowledge graphs into foundational infrastructure for intelligent systems.

1. Introduction and Problem Context

2. Historical Background of Graph Query Interfaces

3. GraphRAG and Natural Language Knowledge Access

4. Graph Models and Text2Query Behaviour: RDF vs Labelled Property Graph

5. Failure Modes of Text2Query Pipelines

6. Query Planning Versus Query Generation

7. Why Most GraphRAG Implementations Misuse Text2Query

8. Applied Knowledge Graph as the Structural Foundation

9. Summary

1. Introduction and Problem Context

The rapid development of large language models has renewed interest in natural language interfaces for structured data systems. Instead of forcing users to write formal queries, modern systems aim to allow interaction using conversational or descriptive language.

In graph-based information systems this paradigm is usually implemented through Text2Query pipelines. A user expresses a question in natural language and the system interprets the request, converts it into a graph query and executes that query against a graph database. The results are then used to generate a final answer.

Graph Retrieval Augmented Generation architectures extend classical retrieval augmented generation by using graph traversal as the retrieval mechanism. Instead of retrieving document fragments from vector stores, these systems retrieve structured knowledge neighbourhoods.

Despite the intuitive simplicity of this approach, production deployment remains challenging.

The main difficulty is not syntax generation. Modern language models can usually generate syntactically valid queries. The core problem lies in semantic alignment between human intent and graph traversal logic.

Natural language rarely specifies exact traversal constraints. Users typically express relationships between entities without describing implementation-level details such as hop counts, relationship directionality or aggregation rules.

A successful system must therefore bridge the gap between descriptive language and deterministic graph execution.

A key enabler of such systems is the use of an Applied Knowledge Graph. An Applied Knowledge Graph is a graph model designed specifically for operational reasoning rather than passive storage of connected entities. In this architecture, taxonomy structure, relationship semantics and property schema design are treated as first-class engineering concerns.

Systems built on Applied Knowledge Graph principles tend to demonstrate more reliable Text2Query behaviour because the graph topology itself encodes reasoning constraints.

2. Historical Background of Graph Query Interfaces

Early attempts to build natural language interfaces for databases focused primarily on relational systems.

These systems attempted to translate English questions into SQL queries. The difficulty of the task became evident because it required solving multiple complex problems simultaneously.

First, the system had to understand the meaning of the question.

Second, it had to map linguistic expressions to database schema elements.

Third, it had to construct a valid query execution plan.

Each of these tasks is difficult in isolation. Combining them into a single pipeline produced unstable behaviour, which is why natural language database interfaces remained largely experimental.

Graph databases changed the modelling paradigm by explicitly representing relationships between entities.

Two major modelling approaches emerged.

The Resource Description Framework (RDF) represents knowledge as subject, predicate and object triples. This model is particularly useful for semantic web applications and ontology reasoning.

The Labelled Property Graph (LPG) model represents knowledge using nodes, relationships and local properties attached directly to graph elements.

From a Text2Query engineering perspective, the LPG model often provides a more practical interface for language model integration because traversal paths are explicit.

ISO Graph Query Language (GQL) is emerging as a standardised query language for LPG databases. Although vendor implementations are still evolving, the pattern matching semantics of GQL are well suited for language model query synthesis.

3. GraphRAG and Natural Language Knowledge Access

GraphRAG extends retrieval augmented generation by integrating graph traversal into the retrieval stage.

Traditional retrieval augmented generation focuses on document similarity search. GraphRAG instead retrieves structured knowledge fragments by exploring relationships between entities.

The architecture can be described as a multi stage pipeline.

• First, the system interprets the user question.

• Second, it determines the semantic intent of the request.

• Third, it plans how the graph should be traversed to obtain relevant knowledge.

• Fourth, the graph database executes the traversal.

• Finally, the retrieved structured context is used by the language model to generate the final answer.

One important engineering principle is that GraphRAG systems should not attempt to generate complex traversal queries for every question.

In many cases neighbourhood retrieval is sufficient. For example, if a question concerns a specific entity, retrieving its surrounding relationships may already provide enough context.

Dynamic traversal synthesis should be reserved for analytical queries that require multi-hop reasoning across the graph.

4. Graph Models and Text2Query Behaviour: RDF vs Labelled Property Graph

Natural language questions tend to describe relationship paths rather than isolated entities.

Consider the question:

Which projects depend on systems maintained by teams located in Germany?

The implicit conceptual path is:

Project → System → Team → Country

In a LPG, this path can be represented directly using pattern-matching traversal syntax.

Example GQL pattern:

MATCH
  (p:Project)-[:DEPENDS_ON]->(s:System)
  -[:MAINTAINED_BY]->(t:Team)
  -[:LOCATED_IN]->(c:Country)
WHERE c.name = ‘Germany’
RETURN p.name

This structure mirrors the narrative structure of the question itself.

Node properties such as names, categories and identifiers are stored locally on graph elements. This simplifies mapping linguistic references to graph schema attributes.

Relationship properties are also important in operational knowledge modelling.

For example, delivery delay metrics, confidence scores or temporal validity indicators can be stored directly on relationships.

MATCH
  (s:Supplier)-[d:DELIVERED]->(p:Product)
WHERE p.category = ‘Battery’
  AND d.delay_days > 5
RETURN s.name, d.delay_days
ORDER BY d.delay_days DESC

In RDF-based models, similar structures often require reification patterns or intermediate nodes. These modelling patterns increase query synthesis complexity because language models must reconstruct auxiliary structural elements.

5. Failure Modes of Text2Query Pipelines

Several characteristic failure patterns appear in production Text2Query systems.

• The first is hallucinated schema construction. Language models may generate node labels, relationship names or property keys that do not exist in the graph schema. This problem is particularly common when schema grounding is weak or absent.

• The second is traversal uncertainty. Natural language questions rarely specify how far graph traversal should continue. The system must therefore decide traversal depth and pruning strategy.

• The third failure pattern is misuse of graph traversal for simple filtering tasks. Some implementations reduce graph retrieval to property text matching. This effectively turns the graph database into a keyword search index and removes the advantages of graph topology.

• The fourth issue is operational governance. Automatically generated queries can be expensive to execute or may expose data that should remain restricted. Production systems therefore, require execution safety layers.

These safety layers should include query complexity estimation, traversal depth limitation, policy enforcement checks and sandboxed execution environments.

6. Query Planning Versus Query Generation

Query planning and query generation are fundamentally different computational tasks.

Query generation focuses primarily on constructing syntactically correct query strings. This task is mostly a language modelling problem.

Query planning is more complex. It requires semantic reasoning about how information is distributed across the graph and how traversal should be performed to obtain meaningful results.

Planning must answer several questions before query construction begins.

The system must determine the starting entity or entities relevant to the user request. For example, if a user asks about suppliers, the planner must identify which supplier nodes are relevant.

The planner must also determine which relationships should be traversed. In an enterprise graph there may be multiple relationship types connecting entities. Selecting the correct relationship path is essential for obtaining meaningful results.

Traversal horizon is another important planning parameter. Some questions require only one hop traversal, while others require multi-hop reasoning across multiple entity types.

Aggregation semantics must also be planned. Questions such as “largest supplier” or “most delayed delivery” require the system to determine which metric defines the comparison.

Temporal constraints are also common. Expressions such as “recent”, “last quarter” or “historically” must be mapped to explicit temporal filters.

Modern GraphRAG architectures increasingly resemble planning systems rather than pure query translators.

Language models are used to interpret intent and help synthesise reasoning context, but deterministic planning layers are responsible for traversal strategy construction.

7. Why Most GraphRAG Implementations Misuse Text2Query

Many GraphRAG systems treat Text2Query as the primary retrieval mechanism.

This design assumption is often incorrect.

In production knowledge systems, retrieval should be primarily driven by structural graph exploration rather than dynamic query synthesis alone.

The most common mistake is attempting to solve interpretation, planning and query construction inside a single model inference step.

This approach increases hallucination probability because the model must simultaneously perform semantic understanding, schema mapping and traversal logic construction.

Another frequent problem is excessive reliance on prompt schema injection. Some implementations attempt to solve grounding by inserting entire graph schemas into prompts.

This approach is inefficient for large enterprise graphs because schema size can be significant. More importantly, it introduces noise into the prompt context and increases the probability that the model will generate relationships that do not exist.

A third common problem is treating graph databases as semantic search indices rather than structural reasoning systems.

If traversal logic is ignored and only property text matching is performed, the graph database behaves similarly to a document store.

In such cases the engineering value of graph topology is lost.

8. Applied Knowledge Graph as the Structural Foundation

The reliability of GraphRAG and Text2Query systems depends primarily on knowledge modelling quality.

An Applied Knowledge Graph is a graph structure designed to support operational reasoning. Knowledge modelling discipline is therefore more important than model size or embedding dimensionality.

AKG design requires several principles.

• First, taxonomy structure must be stable. Node labels should represent meaningful domain categories that do not change frequently.

• Second, relationship semantics must be explicitly defined. Relationship names should describe operational meaning rather than being artefacts of extraction pipelines.

• Third, property schema design must be controlled. Properties should follow consistent naming conventions and data typing rules.

• Fourth, traversal paths should reflect real world reasoning patterns. Graph topology should encode domain logic rather than simply storing extracted connections.

Many knowledge graphs built through automated document extraction fail to meet these criteria. Although such graphs may contain entities and relationships, they often lack operational semantics.

Without operational semantics traversal queries cannot reliably capture domain reasoning.

9. Summary

• Natural language interaction with graph databases is becoming increasingly important as LLM are integrated into enterprise knowledge (EKG) platforms.

• Reliable Text2Query and GraphRAG behaviour is primarily a knowledge modelling problem rather than a purely machine learning problem.

• The labelled property graph (LPG) model provides a practical foundation for conversational graph interaction because its traversal patterns align closely with narrative relationship descriptions.

• ISO GQL pattern matching semantics further support language model query synthesis.

• Applied Knowledge Graph (AKG) design is a key enabler of production grade GraphRAG systems. Future enterprise knowledge architectures will likely combine three components.

• Structured AKGs will serve as the reasoning backbone.

• Language models will focus on intent interpretation and answer synthesis.

• Controlled planning layers will be responsible for traversal construction and execution governance.

• The long term objective is not conversational query generation alone but reliable operational reasoning over structured enterprise knowledge.

1. Introduction

2. The Category Mistake in the LPG versus RDF Debate

3. What RDF Actually Optimises For

4. What LPG Actually Optimises For

5. Knowledge Representation versus Decision Infrastructure

6. GraphRAG as a Stress Test

7. Applied Knowledge Graph Revisited

8. Where RDF Excels

9. Where LPG Dominates

10. Architectural Consequences

11. Conclusion

1. Introduction

The debate between a Labelled Property Graph (LPG) and RDF has been ongoing for more than a decade. It is often framed as a question of which model is more expressive, more semantic, or more suitable for a Knowledge Graph. That framing misses a more important distinction.

RDF, standardised by the World Wide Web Consortium, is fundamentally a knowledge representation framework. It defines how facts are expressed and how those facts can be interpreted through formal semantics. A LPG, by contrast, is a structural model optimised for computation over relationships.

In the current landscape of AI systems, this difference is no longer theoretical. When graphs power retrieval pipelines, digital twins, decision support systems, or contextual reasoning engines, their runtime behaviour matters more than their declarative purity. The question shifts from how knowledge is represented to how decisions are enabled.

This article argues that RDF and LPG operate at different architectural layers. One formalises meaning. The other operationalises context.

2. The Category Mistake in the LPG versus RDF Debate

Most discussions comparing LPG and RDF assume they compete for the same architectural role. This assumption is rarely examined and almost never justified.

RDF defines a formal data model grounded in model theory. It specifies how statements can be interpreted and how entailments may be derived. LPG defines a structural graph model in which nodes and relationships are explicit and property bearing. It specifies how connected data is organised and traversed.

These are fundamentally different design problems.

When LPG is criticised for lacking formal semantics, it is being evaluated against criteria it was not designed to satisfy. When RDF is criticised for operational complexity in traversal heavy workloads, it is being evaluated as though it were intended to be a high-performance relationship processing engine.

The category error lies in collapsing three distinct layers:

• Semantic layer: how meaning is defined and aligned.

• Structural layer: how entities and relationships are physically organised.

• Operational layer: how the system behaves under analytical and decision workloads.

RDF tightly integrates semantic and structural concerns around triple representation. LPG separates structural representation from formal semantic commitments and instead optimises for operational graph behaviour.

The result is predictable. RDF excels when the central concern is shared meaning and logical entailment. LPG excels when the central concern is relational computation and contextual evaluation.

Debating which is “better” without specifying the layer under discussion leads to conceptual noise. The real question is which architectural layer is dominant in the system being built.

3. What RDF Actually Optimises For

RDF represents information as subject, predicate, object triples. This atomic structure ensures that every statement is individually addressable and semantically precise. It supports globally unique identifiers through IRIs, enabling cross system reference and integration.

Through RDFS and OWL, RDF allows inference rules to derive new facts from existing ones. This makes it powerful for domains where logical consistency and ontological rigour are essential. Healthcare terminologies, regulatory reporting, and cross organisational data exchange are typical examples.

The trade off is structural fragmentation. A simple real world relationship may require multiple triples. If that relationship has attributes such as time validity, confidence, or provenance, reification or additional modelling constructs are required. Querying complex patterns often involves multiple joins across triples that reconstruct adjacency at runtime.

RDF excels at expressing meaning in a machine interpretable way. It was designed for distributed semantic integration across the web. It was not designed primarily as a high velocity decision engine.

3.1 Code Examples

Example Domain

Assume a simple domain:

• Alice works for Acme Ltd

• Her role is Risk Analyst

• The employment is valid from 2022-01-01

• Confidence score is 0.92

3.1.1 Basic RDF Triple Representation

In RDF Turtle syntax:

@prefix ex: <http://example.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:Alice ex:worksFor ex:AcmeLtd .
ex:Alice ex:hasRole ex:RiskAnalyst .

This expresses atomic facts. It is semantically precise. Each statement is independently addressable.

3.1.2 Adding Relationship Attributes in RDF (Reification Pattern)

Now we need:

• Validity period

• Confidence score

RDF does not allow properties directly on predicates. Therefore we introduce a resource to represent the employment relation.

ex:Employment123
a ex:Employment ;
ex:employee ex:Alice ;
ex:employer ex:AcmeLtd ;
ex:role ex:RiskAnalyst ;
ex:validFrom “2022-01-01”^^xsd:date ;
ex:confidence “0.92”^^xsd:decimal .

The original simple triple:

ex:Alice ex:worksFor ex:AcmeLtd .

is now replaced or complemented by an intermediate node.

This is semantically clean. The employment becomes a first-class resource. It can be reasoned about, classified, or extended.

However, structurally:

• Adjacency between Alice and AcmeLtd is indirect.

• Queries must traverse via Employment123.

• The model grows in triple count.

3.1.3 Querying in SPARQL

To retrieve Alice’s employer with validity and confidence:

SELECT ?employer ?validFrom ?confidence
WHERE {
?employment a ex:Employment ;
ex:employee ex:Alice ;
ex:employer ?employer ;
ex:validFrom ?validFrom ;
ex:confidence ?confidence .
}

This is expressive and standardised. It supports reasoning if RDFS or OWL rules are applied.

The optimisation target here is semantic correctness and interoperable statement modelling.

4. What LPG Actually Optimises For

A LPG models nodes and relationships as first class objects. Both can carry properties. Nodes can have multiple labels. Relationships are directed and explicitly connect two nodes.

This modelling choice introduces several optimisation characteristics.

• First, explicit adjacency. Connections are materialised directly in the graph structure. Traversing from one node to its neighbours does not require reconstructing relationships from atomic statements. Multi hop navigation is therefore structurally aligned with storage.

• Second, relationship property locality. In many real world domains, the relationship is as important as the entity. Time validity, weight, status, provenance, probability, and confidence are properties of relationships. In LPG, these attributes are native to the edge. This supports modelling of dynamic, weighted, and temporal networks without indirection.

• Third, identity stability. Nodes are distinct entities with persistent identity. This simplifies entity resolution, deduplication, and incremental updates. It also aligns with how AI systems anchor references during contextual retrieval.

• Fourth, schema flexibility with controlled structure. Labels provide lightweight typing without enforcing rigid ontology structures. This enables iterative evolution of the model while preserving structural clarity. Engineers can evolve domains without destabilising the entire graph.

• Fifth, alignment with graph algorithms. Most graph data science techniques assume nodes and edges with weights or attributes. Centrality, community detection, similarity scoring, and path finding operate directly on the structural representation. LPG aligns naturally with these assumptions.

• Sixth, mutation efficiency. Decision systems frequently update state. Transactions, risk scores, event outcomes, and relationship statuses change over time. LPG structures support incremental updates at node and edge level without reconstructing declarative statement sets.

• Seventh, subgraph materialisation efficiency. Many operational systems require extraction of bounded contextual neighbourhoods. LPG’s structure makes subgraph extraction conceptually and computationally straightforward.

These optimisations do not imply superiority in all contexts. They reflect a different optimisation target: relational computation under evolving state conditions. That target corresponds closely to decision infrastructure requirements.

4.1 Code Examples

Example Domain

Assume a simple domain:

• Alice works for Acme Ltd

• Her role is Risk Analyst

• The employment is valid from 2022-01-01

• Confidence score is 0.92

4.1.1 Basic LPG Representation (Cypher)

In a property graph model:

CREATE (a:Person {name: “Alice”})
CREATE (c:Company {name: “Acme Ltd”})
CREATE (a)-[:WORKS_FOR]->(c)

The relationship is explicit and directly connects the two nodes.

4.1.2 Adding Relationship Properties

Now include role, validity, and confidence directly on the edge:

MATCH (a:Person {name: “Alice”})
MATCH (c:Company {name: “Acme Ltd”})
CREATE (a)-[:WORKS_FOR {
role: “Risk Analyst”,
validFrom: date(”2022-01-01”),
confidence: 0.92
}]->(c)

No intermediate node is required.

The relationship remains:

• Direct

• Navigable

• Attribute rich

Adjacency is preserved as a first-class structural property.

4.1.3 Querying in Cypher

To retrieve employer and edge attributes:

MATCH (a:Person {name: “Alice”})-[r:WORKS_FOR]->(c:Company)
RETURN
c.name AS employer,
r.role AS role,
r.validFrom AS validFrom,
r.confidence AS confidence

This pattern aligns directly with how the graph is stored:

• Node → relationship → node

• Relationship carries metadata natively

4.1.4 Multi Hop Traversal Example

Suppose we want to find companies connected through shared employees.

MATCH
(p:Person)-[:WORKS_FOR]->(c1:Company),
(p)-[:WORKS_FOR]->(c2:Company)
WHERE c1 <> c2
RETURN DISTINCT c1.name, c2.name

Traversal logic mirrors conceptual adjacency.

5. Knowledge Representation versus Decision Infrastructure

Knowledge representation is concerned with formal meaning. It asks how facts can be encoded so that machines interpret them consistently. It focuses on ontology design, logical consistency, entailment rules, and semantic interoperability.

Decision infrastructure is concerned with system behaviour under evaluation pressure. It asks how context is assembled, how constraints are checked, how relationships are weighted, and how outcomes are produced.

The distinction becomes clearer when examining real systems.

A regulatory knowledge base prioritises definitional clarity and logical validation. It may tolerate slower traversal if semantic correctness is paramount.

A fraud detection engine must traverse transaction networks rapidly, compute centrality, evaluate temporal patterns, and update risk scores in near real time. Logical completeness is less important than contextual responsiveness.

An AI assistant grounded in enterprise data must extract relevant neighbourhoods quickly, filter by temporal validity, and assemble coherent context windows for prompt construction. The graph functions as a contextual accelerator.

These are infrastructure requirements.

Decision infrastructure must handle:

• Continuous mutation of state

• Temporal modelling of validity and change

• High frequency traversal across dense neighbourhoods

• Integration with analytical and machine learning workflows

• Operational latency constraints

Knowledge representation does not disappear in such systems. It remains essential for conceptual clarity. However, it becomes one component within a broader operational architecture.

RDF formalises how meaning is expressed and reasoned about. LPG frequently underpins how relational context is computed and evaluated.

Confusing these concerns leads to over engineered semantic systems that struggle operationally, or high performance graph systems with unmanaged conceptual drift. Recognising the distinction enables deliberate architectural layering rather than ideological positioning.

6. GraphRAG as a Stress Test

GraphRAG pipelines combine large language models with structured graph retrieval. In such architectures, the graph is not a passive store of facts. It becomes a dynamic context provider that shapes what the model sees, how it reasons, and ultimately what it outputs.

A typical GraphRAG flow includes entity extraction, entity resolution, neighbourhood expansion, path evaluation, filtering by relationship attributes, optional graph algorithm execution, and finally structured context assembly for prompt construction. Each of these steps exercises the underlying graph model differently.

The key requirement is not logical entailment in the classical sense. It is contextual density. The system must quickly assemble a coherent subgraph that captures relevant entities, their relationships, their attributes, and often their temporal state. This subgraph is not a theoretical construct. It is an operational object that directly influences downstream AI behaviour.

In a triple based system, adjacency is implicit. It must be reconstructed by joining triples on shared identifiers. If relationships carry attributes such as confidence scores, weights, time ranges, or provenance, these must be expressed through additional triples or reification patterns. Query complexity grows, and the mental model for engineers becomes less direct.

In a property graph, adjacency is explicit and physically aligned with storage. Relationship properties are native. Weighted edges, temporal validity, and contextual attributes are directly attached to the edge. Subgraph extraction corresponds closely to the physical structure of the graph. This reduces impedance between conceptual query and runtime execution.

GraphRAG therefore acts as a stress test. It exposes whether a graph model behaves naturally under iterative traversal, attribute filtering, and path based scoring. It reveals whether the graph is merely a representational layer or a true computational substrate.

It is not that RDF cannot support GraphRAG. It clearly can. The question is where the optimisation pressure sits. RDF optimises for semantic precision and interoperability. GraphRAG optimises for contextual retrieval and decision support under time constraints. The difference becomes visible under load, not in theoretical comparison.

When the graph is part of an AI control loop, runtime characteristics are no longer secondary. They define system viability.

7. Applied Knowledge Graph Revisited

The term Applied Knowledge Graph (AKG) suggests a transition from abstract modelling to practical use. However, the phrase often obscures more than it clarifies.

A Knowledge Graph, in the classical sense, emphasises semantic modelling, ontology alignment, and formal representation of meaning. When the term Applied is added, it implies that the graph now supports operational decisions, analytics, or AI systems.

The problem is that application is not a property of the data model. It is a property of the architecture in which the model participates.

A graph becomes applied when it sits inside a decision loop. It influences credit scoring, fraud detection, recommendation ranking, risk evaluation, or regulatory reporting. In these systems, the graph must handle state changes, temporal validity, incremental updates, and often streaming inputs. It must integrate with machine learning pipelines and support iterative experimentation.

This is where the distinction between representation and infrastructure becomes critical.

RDF based architectures can certainly underpin applied systems. In domains where formal ontologies are non negotiable, this may be the correct choice. However, such systems often introduce auxiliary layers for caching, analytics, or traversal heavy workloads. The representation layer remains semantically rigorous, but operational concerns are handled elsewhere.

LPG based architectures often collapse this separation. The same graph that stores the domain model also powers traversal, scoring, community detection, and contextual retrieval. The structural alignment between data model and computational needs reduces architectural friction.

Calling something an AKG does not resolve this structural difference. It simply labels a usage context.

A more precise framing is this: RDF formalises knowledge for interoperability and reasoning. LPG frequently functions as the operational backbone of decision systems. Both can participate in applied architectures, but they enter from different design assumptions.

Understanding this distinction prevents conceptual inflation. It also clarifies why certain systems scale naturally under decision pressure while others require compensating layers. The debate is not about which model is more intelligent. It is about which model aligns structurally with the demands of real time, AI driven, decision centric systems.

8. Where RDF Excels

RDF remains the most robust standard for semantic interoperability. Its global identifier model enables integration across organisations and domains. Ontologies allow shared understanding of concepts and relationships.

In environments where regulatory compliance, cross-border data exchange, or standards alignment are central, RDF provides unmatched formal grounding. It supports logical validation and inferencing in a principled way.

For publishing linked data at web scale, RDF is the natural foundation. Its design assumptions were shaped by precisely that challenge.

In these contexts, LPG does not replace RDF. It solves a different problem.

9. Where LPG Dominates

LPG dominates when the graph is an active computational substrate. Fraud detection, recommendation systems, supply chain optimisation, and digital twins require high-performance traversal and mutation.

Graph data science workflows operate directly on nodes and relationships with properties. Relationship weighting, path scoring, and community detection are native operations in property graph engines.

In AI systems built around GraphRAG, the graph functions as a contextual accelerator. It must deliver dense, coherent subgraphs quickly. The property graph model aligns directly with this need.

In such scenarios, semantic elegance without computational efficiency becomes insufficient. The infrastructure must sustain load, mutation, and analysis simultaneously.

10. Architectural Consequences

If RDF is a knowledge representation model and LPG is a decision infrastructure, then architecture must reflect that separation explicitly. Treating them as interchangeable leads to systems that are either semantically over engineered or operationally constrained.

The first consequence is layered responsibility.

A mature graph architecture distinguishes between:

• A semantic alignment layer

• A structural and operational graph layer

• An analytical and AI execution layer

In this model, RDF naturally occupies the semantic alignment layer. It defines canonical vocabularies, ontologies, and cross-domain mappings. It ensures that the concept of Customer, Policy, Risk Event, or Legal Obligation carries a stable meaning across organisational boundaries.

LPG naturally occupies the operational graph layer. It materialises entities and relationships in a way that supports traversal, filtering, scoring, and mutation under runtime conditions. It encodes topology in a form directly usable by decision systems.

Above that, analytics and AI components consume the operational graph. Graph algorithms, feature extraction pipelines, and GraphRAG orchestration rely on the structural characteristics of the LPG layer.

The second consequence is clear optimisation boundaries.

If RDF is used as the primary operational store in traversal heavy systems, architects must compensate for structural indirection with caching layers, denormalised projections, or auxiliary graph engines. This increases complexity and introduces additional synchronisation challenges.

If LPG is used without semantic governance, conceptual drift can occur. Labels may proliferate without formal alignment. Domain meaning becomes implicit in engineering conventions rather than explicitly managed in ontologies.

Recognising the different optimisation targets allows architects to avoid forcing one model to satisfy incompatible constraints.

The third consequence concerns evolution and change management.

Semantic models evolve through ontology versioning and governance processes. Changes are deliberate and controlled. Operational graph models evolve through product iteration, new features, and shifting decision logic. Changes are frequent and often incremental.

By separating semantic representation from operational structure, organisations can allow rapid evolution in the decision layer while preserving stability in the semantic layer. This reduces friction between governance and engineering velocity.

The fourth consequence is AI system design clarity.

In AI grounded systems, especially those using GraphRAG, the graph is part of the control loop. It selects context, constrains generation, and sometimes provides structured evidence for outputs.

If the graph is treated purely as a semantic store, engineers may underestimate the performance requirements of contextual retrieval. If it is treated purely as a high performance graph without semantic discipline, AI outputs may reflect inconsistent or poorly aligned domain meaning.

A layered architecture makes responsibilities explicit:

• RDF or equivalent semantic frameworks ensure conceptual integrity.

• LPG ensures computational integrity.

• AI components orchestrate contextual reasoning using the operational graph.

The fifth consequence is organisational alignment.

Semantic web specialists, ontology engineers, and standards bodies often focus on RDF centric concerns. Data engineers, graph data scientists, and AI engineers focus on traversal, scoring, and performance.

When the architecture clarifies that these are complementary layers rather than competing ideologies, collaboration improves. Each discipline understands where its optimisation effort belongs.

Finally, there is a strategic consequence.

As enterprises move towards decision intelligence systems, digital twins, and AI augmented workflows, the graph increasingly becomes a real time evaluation engine. In such systems, infrastructure properties dominate design discussions. Latency, scalability, mutation handling, and algorithmic integration are primary constraints.

Recognising LPG as decision infrastructure does not demote RDF. It positions RDF where it is strongest: defining meaning and ensuring interoperability. It positions LPG where it is strongest: enabling computation over relational context at scale.

Architectural maturity is not choosing sides. It is understanding which layer solves which problem, and designing systems that respect those boundaries rather than collapsing them.

11. Conclusion

The LPG versus RDF debate often confuses different optimisation targets. RDF is a knowledge representation model. It formalises meaning with atomic triples, optimising for semantic interoperability, logical entailment, and ontology alignment. Its strength lies in preserving conceptual clarity across systems.

LPG is a decision infrastructure model. It structures nodes and relationships as first-class, property-bearing elements embedded in explicit topology. It optimises for:

• Direct adjacency and traversal efficiency

• Rich relationship attributes (weights, time validity, confidence)

• Incremental state updates and mutation under evolving conditions

• Contextual subgraph extraction for AI and decision loops

• Alignment with graph algorithms and analytics pipelines

The structural contrast is architectural:

In RDF:

• Relationships are predicates within statements.

• Relationship metadata requires reification or extra constructs.

• Adjacency is reconstructed at query time.

In LPG:

• Relationships are structural primitives with native properties.

• Adjacency is intrinsic, traversal is direct.

• Computation over relationships is first-class and efficient.

AI-driven systems, GraphRAG, graph analytics, digital twins, or decision intelligence, stress the graph as an operational substrate, not just a semantic layer. Fast neighbourhood expansion, weighted relationships, temporal modelling, and iterative updates are essential.

Key takeaway: RDF formalises meaning. LPG operationalises context.

Recognising this distinction allows deliberate layering of semantic alignment and decision infrastructure. The question shifts from which model is “better” to which constraint dominates your system: knowledge representation or decision execution.

Previous posts

• Digital Twins Need Relationship Native Architecture

• When a Labelled Property Graph Can Legitimately Be Considered an Applied Knowledge Graph

• RAG vs GraphRAG vs KAG

• How MCP Influences Graph Data Modelling

• GraphQL Is Not Graph Tech

• GraphRAG Is a Pipeline, Not a Pattern

• GraphRAG and Graph Data Science for Financial Crime Document Processing

• Topological and Temporal Aspects of Graphs

• Labelled Property Graphs as a Foundation for Neuro-Symbolic Architecture

• LPG, PG and RDF: Structural Models, Semantics, and Applied Reality

• Why You Should Not Compare In-Memory LPG Graphs with LPG Storage Graphs

• 12 reasons why MCP over Applied Knowledge Graph is what you should try

• Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective

• Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path

• A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache

• Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs

• LPG: Understanding the Model Beyond the Market Brands

• GraphRAG Engineering Patterns: From Lexical Graphs to Knowledge Traversal

• The Schema Paradox: Why LPGs Are Both Structured and Free

• Why GraphRAG Outperforms RAG in Real-World Applications

• Why Large Graphs Fail Small: When LPG Scalability Breaks Cognitive Coherence

• Applied Knowledge Graph vs Knowledge Graph Layer: Practical Insights from a Labelled Property Graph Perspective

• Cooking with GraphRAG: A Practical Recipe for Your PoC

1. Introduction

2. What a Digital Twin Actually Is

3. Structural Requirements of a Production Digital Twin

4. Why Conventional Data Models Fail

5. The Labelled Property Graph Model

6. Modelling a Digital Twin in LPG

7. Operational Architecture Pattern

8. LPG Versus RDF in Digital Twin Systems

9. Integration with AI and Advanced Analytics

10. Limitations and Boundary Conditions

11. Strategic Implications

12. Conclusion

1. Introduction

Digital Twins are widely discussed across manufacturing, energy, transport and smart infrastructure. Despite the volume of marketing material, implementation maturity remains uneven. Many initiatives deliver visualisation platforms and telemetry dashboards but struggle to evolve into true system models capable of reasoning about structure, dependency and change.

The central issue is architectural. A Digital Twin is not primarily a data collection problem. It is a modelling problem. Physical systems are networks of interdependent components. If the data model does not treat relationships as first class constructs, the twin cannot represent systemic behaviour accurately.

This article addresses the structural foundation required for production grade Digital Twins. It argues that the Labelled Property Graph model provides the most practical and scalable backbone for modelling complex physical systems in an operational context. The discussion is technical and aimed at architects, engineering leads and enterprise data strategists.

2. What a Digital Twin Actually Is

The concept of the Digital Twin emerged from lifecycle engineering, particularly within programmes associated with NASA. The initial objective was to maintain a dynamic digital counterpart of physical assets to support predictive maintenance, fault simulation and lifecycle optimisation.

Later, industry analysts such as Gartner broadened the definition to encompass digital representations of real world entities and systems across industries.

A technically rigorous understanding of a Digital Twin includes the following elements:

1. A structural model describing components and their topology.

2. A behavioural model describing how components operate under different conditions.

3. Continuous synchronisation with operational telemetry.

4. Temporal awareness of configuration and state transitions.

5. Contextual knowledge that captures dependencies, constraints and policies.

The structural model is foundational. Without it, behavioural and predictive layers lack contextual grounding. A Digital Twin that cannot represent and traverse dependencies between components is limited to monitoring rather than system reasoning.

3. Structural Requirements of a Production Digital Twin

Production environments involve complex, layered systems. These systems evolve continuously. Any Digital Twin architecture must therefore support a number of structural capabilities.

First, hierarchical modelling is essential. Facilities contain production lines. Production lines contain machines. Machines contain assemblies and components. The twin must represent these containment relationships explicitly and support traversal across multiple levels without performance degradation.

Second, cross cutting dependencies must be represented. A component may depend on electrical supply, network connectivity, upstream pressure or control signals. These are not attributes of a single entity. They are relationships between entities.

Third, impact propagation must be computable. If a pump fails, which downstream valves are affected. If a controller is reconfigured, which subsystems operate under new logic. The twin must support multi hop queries that reflect real world propagation paths.

Fourth, temporal validity must be modelled. Configurations change. Components are replaced. Relationships may only be valid within specific time intervals. The twin must be able to reconstruct historical topology at a given moment.

Fifth, lifecycle traceability must be maintained. Installation events, maintenance actions, inspections and upgrades must remain linked to structural elements. Historical records must not be detached from the topology in which they occurred.

These requirements are relational in nature. They demand a data model where relationships are explicit, quarriable and capable of carrying metadata.

4. Why Conventional Data Models Fail

Traditional enterprise systems rely on relational databases. While relational technology provides strong transactional integrity and structured storage, it does not naturally model deep networks of interdependency.

Recursive queries and join chains can represent relationships, but complexity grows rapidly with graph depth. Query readability declines, optimisation becomes difficult and performance becomes unpredictable under evolving workloads. Engineering change requests often require schema adjustments, which introduce operational risk.

Document databases offer flexible schemas and nested structures. They are effective for representing isolated aggregates. However, Digital Twins require reasoning across aggregates. Cross document traversal demands secondary indexing and application level logic. Denormalisation strategies can lead to duplication and inconsistency as the system evolves.

Time series databases address telemetry storage efficiently but do not model topology. Attempting to encode structural relationships in tag structures results in opaque designs that are difficult to query semantically.

Across these paradigms, the same limitation appears. Relationships are secondary constructs. They are expressed through foreign keys, embedded arrays or tag conventions. They are not primary modelling elements. As a result, reasoning about dependency and impact becomes an application responsibility rather than a data capability.

5. The Labelled Property Graph Model

The Labelled Property Graph model represents data as nodes connected by directed relationships. Both nodes and relationships can carry properties. Nodes can have one or more labels that classify their type.

Several characteristics make LPG particularly suitable for Digital Twins.

Relationships are first class citizens. They are not inferred from foreign keys. They are stored explicitly and can be indexed and traversed efficiently.

Relationships can carry properties. This allows modelling of capacity limits, validity periods, dependency strength and configuration metadata directly on the edge connecting two entities.

Traversal operations are optimised. Graph databases are designed to follow paths across multiple hops without requiring expensive join operations across large tables.

Schema evolution is flexible. New node labels or relationship types can be introduced incrementally without requiring disruptive migrations.

The LPG model therefore aligns with the way engineers conceptualise systems. Components are connected to components. Dependencies have attributes. Topology is central.

6. Modelling a Digital Twin in LPG

To illustrate the modelling approach, consider a manufacturing environment. A pump is connected to a valve. A sensor measures the pump. The pump is part of a subsystem. The subsystem is located within a facility.

In an LPG representation, each of these elements is a node with one or more labels that define its role. Relationships such as CONNECTED_TO, MEASURES, PART_OF and LOCATED_IN are explicit edges between nodes.

(:Pump)-[:CONNECTED_TO]->(:Valve)
(:Sensor)-[:MEASURES]->(:Pump)
(:Pump)-[:PART_OF]->(:Subsystem)

If the connection between the pump and the valve has attributes such as installation date, maximum pressure rating or maintenance status, these attributes are stored as properties of the CONNECTED_TO relationship.

This modelling approach offers several advantages.

First, structural clarity is maintained. The topology is readable and directly queryable.

Second, dependency metadata remains attached to the relationship itself. There is no need for additional tables or reification constructs.

Third, extensions are straightforward. Introducing a new relationship type or attribute does not require redesigning the entire schema.

Fourth, temporal modelling can be implemented by attaching validity intervals to relationships. Historical topology reconstruction becomes a matter of querying relationships with appropriate time constraints.

The result is a model that remains close to domain language and engineering reasoning.

7. Operational Architecture Pattern

A robust Digital Twin architecture typically separates functional concerns while maintaining strong integration.

Telemetry ingestion systems process streaming sensor data and store it in specialised time series infrastructure. This layer focuses on throughput, compression and temporal aggregation.

The graph layer maintains the structural model. It stores components, subsystems, facilities and their interdependencies. It links telemetry streams to structural entities through explicit relationships.

Analytics and simulation services operate across both layers. For example, a predictive maintenance algorithm retrieves recent vibration data from the time series store and queries the graph to determine upstream dependencies and downstream impact.

The graph layer acts as the contextual backbone. It answers structural questions that cannot be resolved by telemetry alone. It provides the semantic map that allows operational data to be interpreted correctly.

IoT → Stream Processor → Time-Series Store
                     ↓
               LPG Graph Layer
                     ↓
        Simulation + AI + Monitoring

Without this structural layer, advanced analytics remain isolated from system topology and risk-generating context blind insights.

8. LPG Versus RDF in Digital Twin Systems

Resource Description Framework technology provides a formal semantic foundation for knowledge representation. It supports ontology driven integration and reasoning.

However, RDF represents data as subject predicate object triples. Relationships do not natively support properties. When relationship metadata is required, reification patterns or named graphs must be introduced. This increases storage volume and query complexity.

In operational Digital Twin environments, frequent updates and deep traversal queries are common. The simplicity of native relationship properties in LPG reduces modelling overhead and improves performance for traversal intensive workloads.

RDF may be advantageous in scenarios that prioritise cross organisational knowledge sharing and formal reasoning. LPG is often better suited to operational dependency modelling where performance, clarity and ease of development are primary concerns.

The choice should be driven by workload characteristics rather than theoretical elegance.

9. Integration with AI and Advanced Analytics

Advanced Digital Twins increasingly incorporate machine learning and optimisation models. These models require context to operate effectively.

Graph structured data provides that context. Neighbourhood topology can be used to enrich feature sets. Dependency paths can explain why a predicted failure in one component affects another. Graph traversal can constrain optimisation search space to structurally feasible solutions.

Explainability is particularly important in industrial environments. When an AI model predicts a component failure, engineers require an explanation rooted in system structure. Graph based context allows tracing the dependency chain that led to the prediction.

Without relationship native modelling, AI systems operate on isolated features and risk producing results that are difficult to justify or operationalise.

An LPG backbone ensures that AI operates within the structural reality of the physical system.

10. Limitations and Boundary Conditions

It is important to recognise that LPG is not a complete Digital Twin solution in isolation.

High frequency telemetry ingestion requires time series systems optimised for write throughput and temporal aggregation.

Complex physical simulations require domain specific engines capable of modelling thermodynamics, fluid dynamics or electrical behaviour.

Formal ontology reasoning across federated domains may require semantic web technologies.

The strength of LPG lies in structural integration. It provides the coherent topology that connects specialised subsystems. It does not replace them.

An effective Digital Twin architecture is layered and modular. LPG occupies the structural core.

11. Strategic Implications

From a strategic perspective, the modelling decision has long term consequences.

Organisations that treat Digital Twins as enhanced dashboards risk stagnation. Their systems remain limited to monitoring and retrospective analysis.

Organisations that adopt relationship native modelling gain the ability to compute systemic impact, manage configuration complexity and integrate AI with structural awareness.

Over time, system complexity increases. Assets multiply. Interdependencies deepen. Without explicit relationship modelling, technical debt accumulates rapidly.

Selecting a relationship native backbone early in the programme lifecycle reduces long term architectural friction and enables gradual expansion toward system of systems modelling.

The decision is not merely technical. It shapes the organisation’s ability to evolve its Digital Twin from descriptive to predictive and eventually prescriptive capability.

12. Conclusion

Digital Twins are representations of interconnected physical systems. Their value lies in modelling structure, dependency and change over time.

The Labelled Property Graph model provides a practical and scalable foundation for this task. It supports explicit relationships, relationship metadata, efficient traversal and flexible schema evolution.

While it must coexist with telemetry stores, simulation engines and analytic platforms, LPG provides the structural coherence necessary for a true system model.

Without relationship native architecture, Digital Twins remain fragmented and limited. With it, they become robust platforms for advanced analytics, optimisation and long term lifecycle management.

Previous posts

• When a Labelled Property Graph Can Legitimately Be Considered an Applied Knowledge Graph

• RAG vs GraphRAG vs KAG

• How MCP Influences Graph Data Modelling

• GraphQL Is Not Graph Tech

• GraphRAG Is a Pipeline, Not a Pattern

• GraphRAG and Graph Data Science for Financial Crime Document Processing

• Topological and Temporal Aspects of Graphs

• Labelled Property Graphs as a Foundation for Neuro-Symbolic Architecture

• LPG, PG and RDF: Structural Models, Semantics, and Applied Reality

• Why You Should Not Compare In-Memory LPG Graphs with LPG Storage Graphs

• 12 reasons why MCP over Applied Knowledge Graph is what you should try

• Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective

• Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path

• A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache

• Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs

• LPG: Understanding the Model Beyond the Market Brands

• GraphRAG Engineering Patterns: From Lexical Graphs to Knowledge Traversal

• The Schema Paradox: Why LPGs Are Both Structured and Free

• Why GraphRAG Outperforms RAG in Real-World Applications

• Why Large Graphs Fail Small: When LPG Scalability Breaks Cognitive Coherence

• Applied Knowledge Graph vs Knowledge Graph Layer: Practical Insights from a Labelled Property Graph Perspective

• Cooking with GraphRAG: A Practical Recipe for Your PoC

1. Fundamentals: LPG vs Applied Knowledge Graph

2. Enterprise Knowledge Graph vs Applied Knowledge Graph

3. From Structure to Meaning: When an LPG Becomes Semantic

4. The Litmus Test: Operational Dependence

5. Labels as the Real Semantic Layer

6. Constraints, Identity and Correctness

7. Applied Knowledge Graphs in AI and GraphRAG

8. Workflow Criticality and State Control

9. The Maturity Path from LPG to AKG

10. Bridging Enterprise and Applied Layers

11. The Real Transition: From Data Store to Knowledge Infrastructure

Introduction

Graph databases are now standard components in modern architectures. Teams use Labelled Property Graphs (LPGs) to model customers and transactions, services and dependencies, users and permissions, documents and entities. The LPG model is popular because it is expressive, intuitive for engineers and efficient for traversal-heavy workloads.

At the same time, the term “knowledge graph” is used widely and often imprecisely. Many systems described as knowledge graphs are simply well-modelled graph databases. Others genuinely function as a semantic infrastructure that shapes decisions, workflows and AI behaviour.

For engineers working with graph platforms, AI systems and GraphRAG pipelines, the distinction is not academic. Calling something a knowledge graph implies that it encodes domain meaning in a way that software systems depend on.

This article explains, in practical and architectural terms, when an LPG legitimately becomes an Applied Knowledge Graph (AKG). The focus is operational: how the graph is used, how it influences behaviour and when it becomes part of the system’s control path.

1. Fundamentals: LPG vs Applied Knowledge Graph

A Labelled Property Graph consists of:

• Nodes representing entities or things

• Relationships connecting those entities

• Labels defining node types

• Properties storing attributes on nodes and relationships

This model is powerful because it mirrors how engineers design systems: typed entities connected through explicit relationships. It supports efficient traversals and flexible schema evolution.

However, an LPG is fundamentally a structural model. It gives you expressive representation and performance benefits, but it does not automatically provide domain semantics or enforce correctness.

An Applied Knowledge Graph goes further. In an AKG:

• Labels represent meaningful domain types.

• Relationships encode valid domain interactions.

• Constraints enforce business rules.

• Applications rely on the graph’s structure to behave correctly.

An LPG is a modelling technique.
An AKG is a semantic component embedded in runtime behaviour.

2. Enterprise Knowledge Graph vs Applied Knowledge Graph

Two architectural patterns are often conflated.

Enterprise Knowledge Graph (EKG)

An Enterprise Knowledge Graph typically focuses on:

• Canonical identifiers across systems

• Controlled vocabularies

• Data governance and lineage

• Organisational consistency

Its purpose is alignment. It ensures that core concepts such as Customer, Product or Policy mean the same thing across departments and systems.

It is usually slower moving, more governed and designed for long-term stability.

Applied Knowledge Graph (AKG)

An Applied Knowledge Graph is embedded within a specific operational context. It exists to solve concrete problems in running systems.

It typically:

• Drives real-time decisions

• Supports workflow transitions

• Grounds AI systems

• Enforces policy or compliance rules

An AKG does not need to solve enterprise-wide semantic alignment. It needs to ensure that one operational system behaves correctly and predictably.

You can build an AKG without a fully formalised enterprise ontology. What matters is operational dependence, not global completeness.

3. From Structure to Meaning: When an LPG Becomes Semantic

Most LPG deployments begin as connected data platforms. They improve query performance and simplify modelling.

At this stage:

• Labels are used for grouping.

• Relationships describe associations.

• Properties store attributes.

The graph supports analytics and navigation, but it does not control behaviour.

The transition towards an AKG begins when structure starts to carry meaning:

• Labels define what an entity fundamentally is in the domain.

• Relationship types restrict which interactions are valid.

• Certain graph patterns are treated as valid or invalid states.

• Application logic assumes specific graph structures exist.

When domain meaning moves from documentation into graph structure, the graph becomes a semantic layer.

4. The Litmus Test: Operational Dependence

The most practical test is straightforward:

If this graph were removed or corrupted, would system behaviour degrade in a meaningful way?

If the graph only supports reporting, dashboards or optional analytics, the answer is usually no.

If the graph:

• Determines access permissions

• Drives eligibility or approval decisions

• Controls escalation paths

• Constrains AI outputs

• Validates state transitions

then removing it changes how the system behaves.

At that point, the graph is part of the control path. It is not just storage; it is operational infrastructure.

This is the defining characteristic of an Applied Knowledge Graph.

5. Labels as the Real Semantic Layer

In disciplined LPG systems, labels become the effective domain type system.

For example:

• Customer

• Account

• Transaction

• FraudAlert

• BlockedUser

If application code treats these labels as authoritative, then they define identity and capability.

Similarly, relationship types such as:

• OWNS

• APPROVED_BY

• DEPENDS_ON

• ASSOCIATED_WITH

can encode allowed interactions in the domain.

When engineers design business logic that assumes these labels and relationships are correct and complete, the graph becomes the semantic backbone.

Meaning is enforced structurally, not just procedurally.

6. Constraints, Identity and Correctness

A major step in becoming an AKG is structural discipline.

This includes:

• Enforcing one canonical node per real-world entity

• Resolving duplicate identities

• Restricting invalid relationships

• Ensuring mandatory connections exist

When correctness depends on the graph’s integrity, the graph is part of the system’s truth model.

For example:

• A transaction must be linked to exactly one account.

• A high-risk customer must be linked to at least one review process.

• A policy must be associated with specific assets.

If violating these patterns breaks business logic, then the graph encodes domain knowledge, not just data.

7. Applied Knowledge Graphs in AI and GraphRAG

In AI-driven systems, the distinction becomes critical.

In GraphRAG architectures, graphs are used to:

• Retrieve structured context for LLM prompts

• Disambiguate entities

• Provide provenance

• Reduce hallucinations

If the graph simply stores chunks and embeddings, it remains infrastructure.

However, when:

• Only entities present in the graph can be referenced

• Relationships constrain reasoning paths

• Policies in the graph gate responses

• LLM outputs are validated against graph constraints

the graph becomes a deterministic boundary around a probabilistic model. It limits what the AI is allowed to say or do based on structured knowledge. This is one of the strongest modern examples of an Applied Knowledge Graph.

8. Workflow Criticality and State Control

Many operational systems rely on structured state transitions.

Examples include:

• Claims moving through review stages

• Devices moving through health states

• Users moving through risk categories

If these states and transitions are represented in the graph and the application enforces them through graph queries and constraints, then:

• The graph defines valid progression.

• The graph constrains possible actions.

• The graph encodes business logic.

In this scenario, the graph acts as a domain state machine. It governs behaviour directly.

That is applied knowledge embedded in runtime execution.

9. The Maturity Path from LPG to AKG

Systems typically evolve through stages:

Stage 1 – Connected Data
The graph improves modelling and query performance.

Stage 2 – Structured Domain Representation
Labels and relationships align clearly with business concepts.

Stage 3 – Constraint Enforcement
Structural rules and validation logic are introduced.

Stage 4 – Workflow Integration
Applications depend on graph structure for runtime decisions.

Stage 5 – AI Grounding and Control
AI systems are constrained and guided by graph semantics.

Only at Stage 4 and beyond does the LPG legitimately function as an Applied Knowledge Graph.

Maturity reflects increasing semantic discipline and operational dependence.

10. Bridging Enterprise and Applied Layers

In larger organisations, a stable Enterprise Knowledge Graph may coexist with multiple Applied Knowledge Graphs.

The enterprise layer:

• Standardises identity

• Aligns terminology

• Provides governance

The applied layer:

• Implements domain-specific logic

• Supports operational systems

• Evolves with product requirements

A robust architecture often connects them. Applied graphs inherit stable identifiers from the enterprise layer, while enterprise models evolve based on operational insights.

This creates a stable semantic core with adaptable operational edges.

11. The Real Transition: From Data Store to Knowledge Infrastructure

An LPG becomes an Applied Knowledge Graph when:

• Labels are treated as domain types.

• Relationships encode domain commitments.

• Constraints enforce correctness.

• Workflows depend on graph structure.

• AI systems are grounded or constrained by it.

• System behaviour degrades if the graph semantics are wrong.

At that point, the graph:

• Defines what is valid.

• Defines what is possible.

• Defines what is allowed.

It is no longer simply a database optimised for traversal.

It is a semantic infrastructure embedded in your system’s runtime logic.

For engineers building GraphRAG platforms, AI copilots, fraud detection systems, cybersecurity tooling or digital twins, recognising this transition is essential.

Once your graph enters the control path, you are no longer just modelling data.

You are encoding applied knowledge.

Previous posts

• RAG vs GraphRAG vs KAG

• How MCP Influences Graph Data Modelling

• GraphQL Is Not Graph Tech

• GraphRAG Is a Pipeline, Not a Pattern

• GraphRAG and Graph Data Science for Financial Crime Document Processing

• Topological and Temporal Aspects of Graphs

• Labelled Property Graphs as a Foundation for Neuro-Symbolic Architecture

• LPG, PG and RDF: Structural Models, Semantics, and Applied Reality

• Why You Should Not Compare In-Memory LPG Graphs with LPG Storage Graphs

• 12 reasons why MCP over Applied Knowledge Graph is what you should try

• Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective

• Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path

• A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache

• Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs

• LPG: Understanding the Model Beyond the Market Brands

• GraphRAG Engineering Patterns: From Lexical Graphs to Knowledge Traversal

• The Schema Paradox: Why LPGs Are Both Structured and Free

• Why GraphRAG Outperforms RAG in Real-World Applications

• Why Large Graphs Fail Small: When LPG Scalability Breaks Cognitive Coherence

• Applied Knowledge Graph vs Knowledge Graph Layer: Practical Insights from a Labelled Property Graph Perspective

• Cooking with GraphRAG: A Practical Recipe for Your PoC

1. Introduction and Historical Context

2. Classical RAG

3. GraphRAG

4. KAG

5. Graph Models and Their Realisations

6. Comparative Analysis

7. Architectural Trade-offs

8. Practical Guidance

9. Conclusion

1. Introduction and Historical Context

Retrieval Augmented Generation (RAG), GraphRAG, and Knowledge Augmented Generation (KAG) represent successive attempts to ground large language models in structured or semi-structured knowledge. From a graph practitioner’s perspective, the key questions are not prompt engineering but representation, identity, semantics, and the execution model.

Historical Observations

Classical RAG emerged around 2020 as a pragmatic response to the limitations of large language models. Instead of attempting to encode all knowledge in model parameters, the approach externalised knowledge into vector indexes. Documents were chunked, embedded, and retrieved via similarity search. The architecture was intentionally simple: a retriever, a vector store, and a generator. It did not require graph modelling, ontology design, or explicit semantics.

GraphRAG appeared later as practitioners recognised that document chunks lack explicit structure. Real-world data contains entities, relationships, hierarchies, temporal aspects, and constraints. GraphRAG introduced graph traversal into the retrieval step. Instead of retrieving isolated chunks, it retrieves neighbourhoods of connected entities. It is important to emphasise that GraphRAG is an umbrella term rather than a formal standard. Implementations vary widely in how graphs are constructed, traversed, and integrated with embeddings and retrieval. This reflects a shift from similarity-based recall to structure-aware retrieval.

KAG developed in parallel as a broader architectural idea. Rather than only improving retrieval, it aims to integrate a knowledge graph as a reasoning substrate. In this view, the graph is not merely a retriever index but a semantic backbone. In practice, KAG varies significantly in implementation, from ontology-centric systems realised over RDF triple stores to Applied Knowledge Graphs implemented using the LPG model. From a graph engineering perspective, these approaches differ in how seriously they treat identity, relationships, inference, and graph execution engines.

2. Classical RAG

Architectural Overview

Classical RAG consists of three core components: a document corpus, a vector index, and a language model. Documents are split into chunks, embedded into vectors, and stored in a vector database. At query time, the system retrieves the most similar chunks and injects them into the prompt.

This approach treats knowledge as unstructured text. The retrieval mechanism is statistical rather than semantic. It relies on embedding similarity rather than explicit relationships.

Limitations from a Graph Perspective

From a graph practitioner’s viewpoint, classical RAG has several structural limitations. It lacks explicit identity management, so entities may appear in multiple chunks without canonical identifiers. There is no representation of relationships beyond co-occurrence in text, which means traversal or reasoning over connections is not possible. Furthermore, similarity search does not enforce domain constraints. It retrieves semantically similar text, not necessarily logically relevant facts. This is acceptable for loosely structured knowledge but problematic for domains requiring traceability and structured reasoning.

Where RAG Works Well

Classical RAG performs adequately in document-centric scenarios such as FAQ systems, support knowledge bases, and exploratory search. In these cases, the objective is contextual recall rather than structured reasoning.

3. GraphRAG

Conceptual Shift

GraphRAG extends classical RAG by introducing graph structure into the retrieval process. Instead of retrieving independent text chunks, the system retrieves entities and expands along relationships. This produces a context that reflects domain topology rather than embedding similarity alone. Implementations vary, and GraphRAG should be understood as an umbrella term rather than a formal standard.

GraphRAG systems are typically implemented using property graph databases, although RDF-based implementations are also possible.

How It Works

In a typical GraphRAG pipeline, entities are extracted from documents and materialised as nodes. Relationships are derived from co-occurrence, NLP extraction, or domain modelling. Each node may carry textual descriptions, embeddings, and structured properties.

When a query is issued, the system identifies relevant nodes using vector similarity or keyword search. The system then performs graph traversal, for example following relationships within a bounded depth. In practice, vector search often serves as candidate selection before structural expansion, ensuring efficient retrieval. The resulting subgraph is transformed into textual context for the language model.

Engineering Considerations

GraphRAG introduces identity and relationship semantics. Nodes represent real-world entities with stable identifiers, and edges encode explicit relations. This enables neighbourhood retrieval, path-based reasoning, and constraint-based filtering.

However, GraphRAG remains primarily a retrieval architecture. The language model still performs reasoning, while the graph organises context and enhances structure. Vector search is often an integral part of candidate selection, but the graph defines coherent context for generation.

4. KAG

Conceptual Scope

Knowledge Augmented Generation aims to integrate structured knowledge as a first-class component of the reasoning process. Unlike classical RAG, which retrieves documents, or GraphRAG, which retrieves structured context, KAG combines retrieval, semantics, and reasoning within a coherent architecture. From a graph practitioner’s perspective, KAG depends heavily on how the knowledge graph is realised.

Ontology-Centric Knowledge Graphs

An ontology-centric knowledge graph is a knowledge graph designed around formal ontologies. It is typically realised using RDF and stored in a triple store. In this model, entities and relationships are represented as triples, with semantics governed by RDFS or OWL. Reasoning may involve logical inference.

This approach emphasises formal semantics, interoperability, and standards compliance. It supports reasoning tasks such as classification and consistency checking. Modelling overhead and performance considerations are notable trade-offs.

Applied Knowledge Graphs

An Applied Knowledge Graph is a domain-focused knowledge graph realised using the labelled property graph model. It prioritises practical modelling, performance, and application integration. Nodes and relationships carry properties directly, and traversal-centric query languages such as Cypher or Gremlin support expressive pattern navigation.

In KAG systems based on AKG, the graph supports operational workloads, entity resolution, contextual reasoning, and application integration. The language model consumes structured outputs from graph queries rather than raw documents. Vector search is often used for candidate selection before graph-based expansion.

Practical Observations

KAG implementations vary. Some rely on RDF triple stores with SPARQL queries and reasoning engines. Others rely on LPG databases optimised for traversal performance. The critical distinction lies in the underlying graph model and engine capabilities. The inference engine is therefore best described as a graph reasoning engine plus LLM, where applicable, avoiding the implication that every KAG system performs formal logical inference.

5. Graph Models and Their Realisations

Ontology-centric knowledge graphs and Applied Knowledge Graphs are not graph models themselves. They are architectural patterns realised over specific graph models and engines.

• Ontology-centric knowledge graphs are realised over RDF using triple stores such as GraphDB, Stardog, or Blazegraph. These engines support SPARQL queries, reasoning, and schema alignment.

• Applied Knowledge Graphs are realised over labelled property graph databases such as Neo4j, JanusGraph, or Amazon Neptune in property graph mode. These engines support property-rich nodes and relationships, traversal-centric queries, and operational integration.

Graph Model Involvement in RAG Architectures

+----------------------+-------------------+--------------------+--------------------+
| Graph Model          | Classical RAG     | GraphRAG           | KAG                |
+----------------------+-------------------+--------------------+--------------------+
| RDF / Triple Store   | Rare              | Possible           | Common in          |
|                      |                   |                    | ontology-centric   |
|                      |                   |                    | realisations       |
+----------------------+-------------------+--------------------+--------------------+
| Labelled Property    | Rare              | Common             | Common in AKG      |
| Graph (LPG)          |                   |                    | realisations       |
+----------------------+-------------------+--------------------+--------------------+
| Vector Store Only    | Core component    | Candidate selection| Candidate selection|
+----------------------+-------------------+---------------------+-------------------+

Classical RAG relies primarily on vector stores. GraphRAG leverages LPG engines for traversal and structural expansion, while vector search often serves as candidate selection. KAG may use RDF triple stores in ontology-centric implementations or LPG engines in AKG-based systems, with vector search again assisting candidate selection.

6. Comparative Analysis

+----------------------+----------------+----------------+---------------------------+
| Dimension            | RAG            | GraphRAG       | KAG                       |
+----------------------+----------------+----------------+---------------------------+
| Identity Management  | Implicit       | Explicit       | Explicit                  |
| Relationship Model   | None           | Structural     | Structural                |
| Formal Semantics     | None           | Limited        | Optional                  |
| Inference Engine     | LLM only       | LLM only       | Graph reasoning engine    |
|                      |                |                | plus LLM, where applicable|
| Retrieval Unit       | Text chunk     | Subgraph       | Structured knowledge      |
+----------------------+----------------+----------------+---------------------------+

RAG is document-centric. GraphRAG is structure-aware retrieval. KAG aspires to integrate semantics and structured reasoning.

7. Architectural Trade-offs

Classical RAG is simple to deploy and scales horizontally with vector databases. It requires minimal modelling effort. However, it cannot enforce domain constraints or provide deterministic traversal.

GraphRAG introduces modelling overhead. Entity extraction and graph construction require engineering investment. In return, the system gains explicit identity, relationship traversal, and contextual precision. Vector search is typically integrated for candidate selection before graph expansion.

KAG introduces further complexity. Ontology-centric implementations require schema governance and reasoning infrastructure. AKG implementations require disciplined domain modelling and graph lifecycle management. The benefit is deeper integration between structured knowledge and generation. The decision depends on the required level of semantic control and reasoning determinism.

8. Practical Guidance

For document-heavy, low-structure domains, classical RAG is often sufficient. For domains where entity relationships matter, such as supply chains, biomedical data, or enterprise architecture, GraphRAG provides structural advantages. For domains requiring explicit semantics, domain ontologies, or operational graph workloads, KAG realised through either ontology-centric RDF systems or Applied Knowledge Graphs over LPG is more appropriate. The critical question is which graph model and engine capabilities align with the problem domain, not which acronym is chosen.

9. Conclusion

RAG, GraphRAG, and KAG are not merely variations of the same pattern. They represent increasing levels of structural commitment to explicit knowledge representation. From a graph practitioner’s perspective, the core distinction lies in how knowledge is represented and executed. Ontology-centric knowledge graphs rely on RDF triple stores and formal semantics. Applied Knowledge Graphs rely on the labelled property graph model and traversal-centric engines. Ultimately, the effectiveness of any generation architecture depends on identity management, relationship modelling, and the operational characteristics of the chosen graph engine. The acronym matters less than the underlying data model and execution semantics.

Previous posts

• How MCP Influences Graph Data Modelling

• GraphQL Is Not Graph Tech

• GraphRAG Is a Pipeline, Not a Pattern

• GraphRAG and Graph Data Science for Financial Crime Document Processing

• Topological and Temporal Aspects of Graphs

• Labelled Property Graphs as a Foundation for Neuro-Symbolic Architecture

• LPG, PG and RDF: Structural Models, Semantics, and Applied Reality

• Why You Should Not Compare In-Memory LPG Graphs with LPG Storage Graphs

• 12 reasons why MCP over Applied Knowledge Graph is what you should try

• Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective

• Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path

• A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache

• Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs

• LPG: Understanding the Model Beyond the Market Brands

• GraphRAG Engineering Patterns: From Lexical Graphs to Knowledge Traversal

• The Schema Paradox: Why LPGs Are Both Structured and Free

• Why GraphRAG Outperforms RAG in Real-World Applications

• Why Large Graphs Fail Small: When LPG Scalability Breaks Cognitive Coherence

• Applied Knowledge Graph vs Knowledge Graph Layer: Practical Insights from a Labelled Property Graph Perspective

• Cooking with GraphRAG: A Practical Recipe for Your PoC

1. MCP Is an Architectural Shift, Not an AI Feature

2. What MCP Architecture Actually Assumes

3. Why Graph Data Modelling Matters Under MCP

4. Applied Knowledge Graphs as the Natural MCP Backend

5. Why LPG Fits MCP Architecture Better Than Alternatives

6. MCP, LPG, and Temporal Reality

7. Where RDF Fits and Where MCP Exposes Its Limits

8. What This Means for GraphRAG and AI Systems

9. Conclusion

1. MCP Is an Architectural Shift, Not an AI Feature

Users often see Model Context Protocol (MCP) as a convenience layer for connecting large language models (LLMs) with external systems. While accurate, this description underplays MCP’s deeper significance. MCP is not merely a tool; it is an architectural paradigm that reshapes how AI systems interact with live data, operational graphs, and external tools. It defines the requirements that graph systems must satisfy to participate effectively in reasoning loops.

Historically, early AI systems were isolated reasoning engines operating over static datasets or curated knowledge bases. LLMs relied on embedded knowledge or bespoke connectors to external sources. Each integration required custom engineering, which scaled poorly and became fragile as AI workflows grew more complex.

MCP emerged to address these challenges. Initially proposed by Anthropic in 2024 and later adopted by other AI platforms, MCP formalised a standard for incremental, repeated, and mutable access to heterogeneous knowledge sources. It specifies how LLMs request context, receive structured or semi-structured data, and integrate results back into iterative reasoning cycles.

By doing so, MCP redefines success for graph backends. Success is no longer about perfect semantic completeness but about fast, context-relevant retrieval, mutability, and alignment with execution loops. Graph models that cannot satisfy these operational constraints struggle under MCP, while those that do—particularly Labelled Property Graphs (LPGs)—emerge as natural backends.

2. What MCP Architecture Actually Assumes

Understanding why certain graph models succeed under MCP requires examining the protocol’s architectural assumptions and history. MCP emerged as AI systems became increasingly complex and multi-modal. Early experiments with knowledge-augmented LLMs highlighted three persistent challenges:

1. Fragmented access patterns: LLMs needed knowledge from multiple heterogeneous sources simultaneously, including relational databases, graph stores, and procedural APIs. Without a standardised protocol, developers had to write custom connectors for each combination, resulting in fragile pipelines.

2. Contextual relevance and freshness: AI systems often required only partial context to answer a query or make a decision. Pulling entire datasets was inefficient or infeasible due to latency or scale. This created a structural need for incremental context retrieval, later formalised as a core MCP principle.

3. Dynamic, mutable knowledge: AI systems began operating over live data, such as events, logs, or operational states. Static graphs could not reflect these evolving realities, creating inconsistencies between reasoning and execution.

MCP addresses these challenges and codifies four assumptions that directly influence graph modelling:

• Incremental retrieval: Agents request subgraphs or partial context rather than entire datasets, reducing overhead. Graph models must support efficient subgraph extraction.

• Repeated, iterative access: Reasoning loops involve multiple passes over overlapping context fragments. Graph backends must support repeated traversals with predictable performance.

• Mutable, evolving data: MCP assumes the backend reflects current operational state. Nodes and relationships may change between retrievals, requiring incremental updates and temporal awareness.

• Composability with external tools: Graphs rarely operate in isolation. MCP assumes integration with APIs, procedural code, and other data sources. Data models must support flexible, real-time interactions rather than rigid ontology enforcement.

These assumptions imply that graphs optimised purely for semantic completeness or formal reasoning encounter inefficiencies. MCP demands execution-first design, privileging traversal efficiency, mutability, and local context over theoretical purity. While MCP does not mandate a particular graph model, its architecture naturally aligns with LPGs, which satisfy operational and traversal requirements efficiently.

3. Why Graph Data Modelling Matters Under MCP

Once MCP is deployed, graph databases are no longer passive knowledge stores. They become active participants in AI reasoning cycles, with data models directly influencing performance, reliability, and scalability.

Historically, knowledge graphs were dominated by RDF and ontology-first design, emphasising logical consistency, universal identifiers, and strict schema validation. In static or archival contexts, these assumptions worked well, enabling inference engines to enforce ontology rules and ensure data interoperability.

However, MCP exposes a gap between traditional RDF-centric models and live AI workflows. Consider a reasoning cycle in a GraphRAG pipeline:

1. An LLM requests context from the graph for a specific query.

2. The graph returns a relevant partial subgraph.

3. The agent reasons over this subgraph, potentially invoking external tools.

4. Results are written back, updating nodes and relationships.

5. The agent iterates, requesting additional or updated context.

Each loop depends on low-latency traversal, incremental retrieval, and mutable state. RDF-based systems, optimised for semantic completeness, often require multiple joins, reification, or complex query reconstruction to produce meaningful subgraphs. This adds latency, increases engineering complexity, and introduces fragility, especially when temporal or event-driven data is involved.

Applied Knowledge Graphs (AKGs) evolved as a response. Unlike ontology-first graphs, AKGs prioritise actionability over completeness. They model knowledge as it is applied, not as it is theoretically perfect. Nodes and edges carry operational metadata, relationships may include temporal or confidence attributes, and schema enforcement is local rather than global.

Under MCP, AKGs are structurally necessary. The protocol assumes live, actionable knowledge that can be retrieved, traversed, and updated iteratively. Graph data models embracing these principles—particularly LPGs—are inherently better suited to MCP. LPGs provide:

• Native support for properties on relationships, including temporal and operational metadata.

• Efficient traversal for partial subgraph extraction.

• Flexible schema, enabling incremental enrichment and tolerance for evolving knowledge.

• Direct alignment with operational loops, allowing AI agents to reason over live state without reconstruction overhead.

MCP does not merely influence graph modelling—it highlights the structural strengths of AKG and LPG approaches. Graphs optimised for formal reasoning or semantic completeness must adapt or risk underperformance, while LPGs naturally support AI-driven workflows under MCP.

4. Applied Knowledge Graphs as the Natural MCP Backend

Applied Knowledge Graphs (AKGs) did not appear overnight. They evolved organically from the demands of operational systems and AI workflows, long before MCP formalised context reasoning.

Historically, knowledge graphs focused on description and inference. RDF-based graphs prioritised formal semantics, strict ontologies, and global consistency, excelling in interoperability, compliance, and reasoning over curated datasets. However, these assumptions made modelling live operational data difficult without additional abstraction layers.

As AI systems required real-time, actionable knowledge, practitioners experimented with applied rather than purely descriptive graphs. Early AKGs appeared in financial risk, supply chain monitoring, and operational analytics. Focus shifted from “what is true everywhere” to “what is relevant here and now”. Knowledge became partial, evolving, and operationally linked.

MCP formalises and accelerates this evolution by requiring incremental, repeated, and mutable context retrieval, codifying principles already demonstrated in AKGs:

• Incremental retrieval: AKGs deliver slices of knowledge rather than entire datasets.

• Mutable, evolving state: Updates to nodes, edges, and properties are tracked over time.

• Operational metadata: Confidence, provenance, or temporal validity encoded directly on relationships.

MCP did not invent AKGs but enforces the operational, incremental, and temporal principles they embody. Graph models failing to support these aspects struggle under MCP, while LPG-aligned AKGs emerge as the natural backend.

5. Why LPG Fits MCP Architecture Better Than Alternatives

LPGs have evolved alongside operational graph systems for decades. Their rise reflects pressures formalised by MCP: mutable, traversable, and temporally aware graphs capable of responding to live queries.

RDF graphs excel in formal reasoning but often rely on indirect modelling for operational aspects. Representing temporal change, confidence, or state transitions frequently requires reification, named graphs, or event nodes, increasing complexity and query overhead. LPGs place properties directly on nodes and edges, enabling direct representation of operational and temporal knowledge, critical under MCP.

MCP assumes AI agents interact with graphs in iterative, context-driven loops, where each retrieval must be fast, predictable, and actionable. LPGs satisfy these assumptions because they provide:

• Direct edge properties: Temporal, confidence, or provenance information lives on relationships.

• Traversal efficiency: Subgraph extraction and path exploration are native operations.

• Flexible schema: LPGs tolerate evolving knowledge and support incremental enrichment.

• Temporal modelling: Time-aware edge properties enable historical queries and state evolution analysis.

MCP and LPG create structural synergy: MCP formalises execution loops and context retrieval, while LPG provides a graph model that naturally aligns with them. AKGs are the logical outcome: mutable, operational, and temporally aware graphs that support AI reasoning loops.

6. MCP, LPG, and Temporal Reality

Temporal modelling is central to AKGs and MCP-mediated AI reasoning. Agents rarely query only current states. Common queries include:

• “What relationships existed last week?”

• “How did the state of this entity evolve over a sequence of events?”

• “Which events contributed to the current state?”

These are traversal-centric queries, not purely semantic inferences. MCP formalises incremental, repeated, live context retrieval, making temporal awareness essential.

LPGs support temporal modelling via properties on nodes and edges (e.g., start_time, end_time, version, confidence). This allows direct temporal queries without reification. For example, an author-affiliation edge can carry start_date and end_date, enabling efficient historical queries.

AKGs embed operational metadata with temporal attributes, ensuring subgraphs reflect both current state and historical evolution, supporting decision-making loops rather than static analysis. MCP’s iterative retrieval pattern emphasises this: each loop may request context differently depending on time or prior reasoning outcomes.

RDF struggles operationally. Temporal representation typically requires reification, named graphs, or event nodes, adding query complexity and traversal cost. Each MCP retrieval may require subgraph reconstruction across datasets, incompatible with low-latency, iterative access.

LPGs excel here. Temporal and operational attributes live directly on the graph, making subgraph extraction efficient and semantically meaningful. In GraphRAG flows—which repeatedly extract, reason over, and enrich subgraphs—this efficiency is critical.

7. Where RDF Fits and Where MCP Exposes Its Limits

RDF remains valuable for formal reasoning, ontology validation, and cross-organisational knowledge sharing. Its standardised triples and logical foundations support semantic rigour and federated data integration, where adherence to shared ontologies is essential.

However, MCP exposes RDF’s limitations in operational, incremental, and temporal reasoning. MCP assumes:

• Incremental and repeated retrieval: Agents rely on contextually relevant subgraphs, not full traversal.

• Mutable and evolving state: Knowledge is updated continuously during reasoning loops.

• Temporal and operational awareness: Relationships and nodes change over time and must be queried efficiently.

RDF optimises for semantic completeness rather than operational efficiency. Temporal reasoning requires reification, named graphs, or event nodes, increasing complexity and latency. Incremental subgraph extraction is not native, so retrieval often involves costly reconstruction.

In MCP-mediated AI systems, these inefficiencies become operational bottlenecks. RDF can emulate incremental retrieval and mutability via extra layers, but doing so adds overhead and reduces responsiveness.

LPGs satisfy MCP requirements naturally: properties and temporal metadata live on nodes and edges, subgraph extraction is efficient, and iterative reasoning loops operate with minimal overhead. MCP does not diminish RDF’s value but exposes its limits for live, applied reasoning. RDF excels in federation and formal reasoning, but incremental, mutable, and temporal context access is LPG’s domain.

8. What This Means for GraphRAG and AI Systems

GraphRAG is both a pipeline, in the modern sense, and an architectural pattern for integrating LLMs with knowledge graphs. It defines an iterative reasoning cycle:

1. Context retrieval: The agent queries the graph for a relevant subgraph, optionally filtered by temporal or operational attributes.

2. Reasoning and tool invocation: The LLM reasons over context and may invoke APIs or external services.

3. Result integration: Outputs are written back, updating nodes, edges, or properties.

4. Iteration: The agent requests additional or updated context, refining outputs incrementally.

MCP formalises this flow, standardising interfaces and interaction patterns. It ensures predictable, efficient context retrieval, iterative reasoning, and live updates.

AKGs on LPG backends are particularly suited to GraphRAG flows:

• Efficient subgraph extraction for repeated retrieval.

• Temporal and operational metadata on nodes and edges, supporting historical reasoning.

• Mutable state allowing incremental enrichment without schema disruption.

• Flexible schema supporting evolving operational data.

RDF-based graphs struggle to support GraphRAG flows natively. Incremental retrieval and temporal reasoning require complex abstractions, adding latency and operational overhead. In MCP loops, RDF must reconstruct context each iteration, highlighting structural disadvantages.

GraphRAG demonstrates the structural advantage of LPG-backed AKGs under MCP. Agents iterate quickly, reason over live data, and incorporate temporal evolution efficiently, making LPG the natural choice for production-ready GraphRAG architectures.

9. Conclusion

MCP is not merely a convenience or AI feature; it is an architectural shift that reshapes success for graph data modelling. By privileging incremental context, repeated access, mutable state, and temporal reasoning, MCP determines which graph models thrive.

Applied Knowledge Graphs emerge as the default backend, and LPGs prevail because their architecture aligns naturally with MCP execution loops. Graph models optimised for semantic purity, ontological consistency, or formal reasoning struggle under operational demands.

MCP did not invent LPG dominance. It made operational, incremental, and temporal advantages impossible to ignore. In the era of AI-driven applied knowledge, LPGs are the graph model that survives in production.

Previous posts

• GraphQL Is Not Graph Tech

• GraphRAG Is a Pipeline, Not a Pattern

• GraphRAG and Graph Data Science for Financial Crime Document Processing

• Topological and Temporal Aspects of Graphs

• Labelled Property Graphs as a Foundation for Neuro-Symbolic Architecture

• LPG, PG and RDF: Structural Models, Semantics, and Applied Reality

• Why You Should Not Compare In-Memory LPG Graphs with LPG Storage Graphs

• 12 reasons why MCP over Applied Knowledge Graph is what you should try

• Graph Summarisation Is the New Retrieval: A Practical View from the LPG and AKG Perspective

• Enterprise Knowledge Graphs vs Applied Knowledge Graphs: Same Vision, Different Operational Path

• A Practical Architecture for LLM Memory: LPG as the Adaptive Knowledge Cache

• Labels as the Real Semantic Layer of LPG in GraphRAG and Applied Knowledge Graphs

• LPG: Understanding the Model Beyond the Market Brands

• GraphRAG Engineering Patterns: From Lexical Graphs to Knowledge Traversal

• The Schema Paradox: Why LPGs Are Both Structured and Free

• Why GraphRAG Outperforms RAG in Real-World Applications

• Why Large Graphs Fail Small: When LPG Scalability Breaks Cognitive Coherence

• Applied Knowledge Graph vs Knowledge Graph Layer: Practical Insights from a Labelled Property Graph Perspective

• Cooking with GraphRAG: A Practical Recipe for Your PoC

1. Introduction: The Interface Abstraction Fallacy

2. What GraphQL Actually Is, Mechanically

3. What Graph Technology Requires and Why GraphQL Does Not Provide It

4. Resolvers Versus Adjacency: Why Simulation Fails

5. Identity Loss and Semantic Degradation

6. Terminology Pollution and Its Impact on GraphRAG and AI Systems

7. GraphQL’s Legitimate Role Over Graph Databases

8. Conclusion: Architectural Precision Is Not Optional

1. Introduction: The Interface Abstraction Fallacy

GraphQL is one of the most successful API technologies of the last decade. Originally developed at Facebook to address the inefficiencies of REST-based mobile APIs, and later open-sourced and standardised under the GraphQL Foundation, it solved a real and persistent problem in distributed systems. REST interfaces frequently over-fetch data, under-fetch required context, and force teams into brittle endpoint proliferation. GraphQL replaced this with a declarative, contract-driven model that significantly improved client-server interaction and developer productivity.

What GraphQL did not do is introduce graph technology.

Despite this, the industry increasingly treats GraphQL as if it were part of the graph ecosystem. The word graph in its name, combined with nested queries and interconnected schemas, has created a persistent illusion of graph-native access. This illusion is reinforced by visual representations, marketing language, and informal explanations that blur the boundary between interface structure and data semantics.

The result is a category error. GraphQL presents a hierarchical interface abstraction, while graph technology operates on persistent networks of identity and relationships. Confusing these two paradigms leads to systems that look graph-like at the surface but fail under real connected-data workloads.

2. What GraphQL Actually Is, Mechanically

GraphQL is a query language for APIs combined with a strongly typed schema system. It defines how clients request data and how servers describe the shape of valid responses. Its execution model is resolver based.

When a GraphQL query is executed, the runtime performs a depth-first walk of the query document. Each field in the selection set triggers a resolver function responsible for producing that field’s value, often by invoking downstream services or databases. These resolvers are typically stateless, independent, and unaware of the broader data topology they are assembling.

GraphQL deliberately avoids defining anything about persistence, identity, or relationships. It does not specify how entities are stored, how relationships are represented, or how traversal should be executed. It does not preserve identity across field resolutions unless the application explicitly implements that behaviour. Nested objects are treated as subtrees of a response, not as entities with stable identities.

This is not a flaw. It is an intentional design decision. GraphQL is an interface abstraction, not a data model, storage engine, or computation framework.

3. What Graph Technology Requires and Why GraphQL Does Not Provide It

Graph technology is defined by its data management architecture, not by visual shape or API structure. A graph system represents information as a network of nodes, representing entities, and edges, representing relationships, grounded in mathematical graph theory. The defining characteristic is that connections between data points are treated as first-class elements throughout storage, querying, and execution.

In a graph system, entities have stable identities that persist independently of how they are accessed or queried. Relationships are explicitly stored rather than inferred at query time. Traversal is a native operation of the system, not an emergent behaviour assembled by application code. Queries express navigation intent directly, often across variable-length paths, and execution engines are designed with awareness of topology, degree, locality, and neighbourhood structure.

This architectural approach applies across graph paradigms, including property graphs, RDF triplestores, and graph analytics engines, even though their data models and query languages differ. In all cases, connectedness is intrinsic to the storage and execution model. Relationships are not reconstructed through joins, resolver chains, or procedural lookups. They are part of the underlying data representation.

GraphQL does not operate at this level. It has no concept of adjacency as a storage primitive, no awareness of graph topology, and no native support for traversal as a computational operation. Any appearance of connected navigation in GraphQL is produced by application logic coordinating independent resolver calls against one or more backends. The graph, in this case, exists only as an interface illusion, not as a data structure or execution model.

4. Resolvers Versus Adjacency: Why Simulation Fails