When you need a knowledge graph

A week after the Blouberg Infrastructure Programme, a fictional public infrastructure programme with about forty construction sites, changed its assistant to resolve identifiers before retrieving, a vendor demonstrated a knowledge graph built automatically from six thousand of the programme's documents. Contractors, sites, milestones and inspectors appeared as coloured circles, joined by labelled lines. Sipho Ndaba, the programme's data engineer, was impressed. Lindiwe Mokoena, who runs the programme management office, asked a narrower question: which of our real questions does this answer that we cannot answer today? (The programme's people, systems and figures are illustrative.)

Nobody in the room could name one with confidence. That is not an argument against graphs. It is an argument for deciding where a graph sits in a ladder of cheaper options, and for being honest about what it costs to keep one true.

Knowledge-graph search for relationship-heavy questions explains how graph traversal works, why graphs should be built from structured records first, and how to test whether one is worth building. RAG, fine-tuning and knowledge graphs solve different problems routes questions between those techniques. This article assumes both and adds three things: the intermediate options between a table and a graph, the signals that move a question up the ladder, and the identity work that every option above the first rung depends on.

Graph-shaped questions do not always need a graph database

Most enterprise questions involve relationships. "Which contractor holds the contract for Site 14?" connects a contractor, a contract and a site. That does not make it a graph question in any useful sense. It is a two-table join that any relational database answers well, and that the programme's contract system already answers on screen.

The word "graph" covers several different things that are easy to blur together:

• a way of thinking about information as things and the relationships between them, which is useful almost everywhere;
• a data model, either a property graph (nodes and edges with properties) or RDF, the W3C model in which every statement is a subject, predicate and object, and identifiers are global IRIs (RDF 1.1 Concepts, a W3C Recommendation of February 2014; RDF 1.2 was a Candidate Recommendation when checked on 5 November 2026);
• a database product optimised for traversing that model; and
• a shared knowledge graph that several organisations or systems agree to read and write.

You can get most of the benefit of the first without paying for the third or fourth.

The ladder

Lindiwe's team placed each of their twenty most frequent relationship questions on a five-rung ladder. Each rung adds capability and adds cost, and a question should sit on the lowest rung that answers it reliably.

Rung 1: query the system of record. The relationship already exists inside one system, and the question is a lookup. Which contractor holds a contract is rung 1.

Rung 2: an identifier register. The relationship crosses systems that name the same thing differently. A register (a table linking each real-world entity to its identifiers in every system) is enough to join them. "Has the contractor on Site 14 been paid?" became answerable at rung 2 once contract and finance identifiers were linked.

Rung 3: a relational model or semantic layer. The questions follow known paths of fixed length across several entity types: contractor to contract to milestone to payment certificate. A modelled set of views, or the semantic layer the analytics team already maintains, answers them with ordinary joins.

Rung 4: a property graph. The path length varies, or the question is about the path itself. "If this contractor is suspended, what is affected?" means following joint-venture partners to their other contracts, to subcontracts, to sites, to milestones with pending certificates, and the depth differs for each contractor. Recursive queries can do this in a relational database, but they become hard to write, test and explain. A graph traversal returns the paths directly. There is also a middle path: SQL/PGQ (ISO/IEC 9075-16:2023) adds property graph queries to SQL, so a graph view can be defined over existing relational tables without moving the data, where the database supports it.

Rung 5: an RDF knowledge graph with a shared vocabulary. Meaning must be shared across organisations or across systems that will never share a database. If the provincial department, three municipalities and the programme's consulting engineers all need to exchange site and asset information with agreed definitions, global identifiers and a published vocabulary become valuable in their own right.

Five signals that justify the upper rungs

The ladder only helps if there is a way to tell when a question has outgrown a rung. Five signals came up repeatedly.

1. Variable depth. Words like "everything downstream of", "all affected", "any connection between" usually mean the number of hops is not fixed.
2. The path is the answer. The user needs to see how two things are connected, not only that they are.
3. Many entity types, sparse links. Dozens of entity types, each linked to a few others, produce a relational schema with more join tables than data tables.
4. The schema changes faster than releases. New relationship types arrive monthly, and each relational change needs a migration.
5. Meaning crosses an organisational boundary. Others must read your identifiers and definitions without access to your systems.

Signals 1 to 4 point towards rung 4. Signal 5 points towards rung 5. If none is present, stay lower.

Identity is the real cost

Every rung from 2 upwards rests on the same foundation: knowing that two records refer to the same real-world thing. The vendor's demonstration graph had three nodes for the Site 14 contractor, because it extracted names from documents and the joint venture appeared under three spellings. It also had one node for two different sites that shared a farm name. A traversal across that graph would have produced a clean, traceable and wrong answer.

At Blouberg, the identifier register built in Part 1 turned out to be the most valuable asset in the whole design, because every higher rung depends on it. Three practices kept it trustworthy:

• Merges and splits are decisions, with an owner. Declaring that two supplier records are one contractor affects payments. The contracts manager approves merges; the register records who decided and when.
• Identifiers never change meaning. When a site was split into two work packages, the old identifier was retired and two new ones issued, with a recorded link to the original. Reusing the old code would have silently rewritten history.
• Automated matching proposes; people confirm. Fuzzy matching on names and registration numbers produced candidate links. Only confirmed links were used in answers, the same discipline the Data That Can Be Trusted series applied to extracted graph edges.

If an organisation cannot maintain an identifier register for its main entities, it is not ready for a graph. The graph will inherit every unresolved duplicate and add traversal on top.

Where Blouberg's questions landed

The team's twenty frequent relationship questions sorted like this, as an illustrative distribution for a fictional programme:

The decision followed the table. The team built rungs 2 and 3 for the programme as a whole. For the three rung-4 questions, all of which concerned contractor exposure, they built a small property graph view that is loaded nightly from the register and the contract and finance systems, with the source system and load date on every edge. It holds the eight entity types and seven relationship types shown above. It is read-only, and it is available to the contracts and risk teams, not to the general assistant, because it concentrates information about companies and people that the source systems restrict.

Rung 5 stayed on the roadmap. The provincial department had started discussing a shared asset register with municipalities, and if that goes ahead, a published vocabulary with global identifiers will matter. Building it before any partner is ready to use it would have been speculative work.

Property graph or RDF

When a question does justify rung 4 or 5, the choice of model follows from who needs to read the result. The comparison below is about models, not products.

Either can be the wrong answer if the identity layer underneath is weak. Part 4 of this series covers how to write the vocabulary that rung 5 depends on without an academic project.

What a graph costs to keep true

Teams usually estimate the cost of building a graph. The cost of keeping it true is larger and recurs. Before approving rung 4 or 5, make sure each line has an owner:

• Modelling. Someone decides which entity and relationship types exist and what they mean.
• Loading. Pipelines from each source, with the source and date recorded on every edge.
• Identity. The register, its matching rules and the people who confirm merges.
• Refresh and drift. Changes in sources must reach the graph, and divergence must be detected, which is the operational discipline in Data quality and observability are operational disciplines.
• Access. The graph's access rules must be at least as strict as the strictest source it draws from.
• Evaluation. A fixed set of relationship questions with expected answers, rerun after every model or loading change.

A decision checklist

• List your twenty most frequent relationship questions from real users.
• Place each on the lowest rung that answers it reliably.
• Build the identifier register for your main entity types before anything higher.
• Look for the five signals before choosing rung 4 or 5.
• Scope any graph to the questions that need it, and keep it read-only at first.
• Name owners for modelling, loading, identity, refresh, access and evaluation.

Key points

• Relationship questions are common; graph databases are justified far less often. Use the lowest rung that answers the question.
• An identifier register and a modelled relational layer answer most cross-system questions.
• Variable depth, path-as-answer, sparse many-type schemas and fast-changing relationships point to a property graph. Meaning shared across organisations points to RDF.
• Identity is the real cost. A graph built on unresolved duplicates gives clean, traceable, wrong answers.
• Budget for keeping the graph true, not only for building it.

Next: Part 3, Multimodal RAG is an information-architecture problem. All parts are on the series page.

How CloudNala can help

CloudNala helps teams decide whether a knowledge graph is justified before anyone buys one. We collect and classify your relationship questions against the ladder in this article, assess the state of your identity data for the main entity types, design the identifier register and its governance, and, where a graph is warranted, scope it to the questions that need it, with loading, refresh, access and evaluation owned from the start.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Knowledge Architecture Review or write to us at consult@cloudnala.co.za