What is a knowledge graph? A plain-English example from a service business

Start with things and the links between them

In graph terminology, a thing is a node and a relationship is an edge. A client node can link to an agreement node through “has agreement”. That agreement can link to a reporting task through “governs”. A person can link to the task through “reviews”.

Nodes and relationships can carry information such as an identifier, owner or validity period. A source link lets someone check why a relationship is recorded. The Alan Turing Institute’s knowledge graph group provides wider research context for the field.

The business question determines which links matter. There is little value in connecting every available noun if the resulting graph cannot help someone complete a job.

Follow a small client-reporting graph

Client A → has agreement → Agreement v2
Agreement v2 → governs → Monthly report
Account owner A → maintains → Agreement v2
Reporting reviewer → reviews → Monthly report
Agreement v2 → evidenced by → Approved agreement source

The graph answers a connected question: “Who should resolve an uncertain requirement in Client A’s monthly report?” Follow the task to its governing agreement, then to the account owner. A document collection could also answer it, but only if someone finds and joins those details correctly.

Keep origin and dates attached to important links

A relationship can be wrong or out of date. A person may have changed roles, or a client may have approved a new agreement. Record the source origin separately from when the relationship became valid and when you collected it.

Said describes our current build as carrying this provenance into the agent’s work so a person can inspect it. Important contradictions require a decision; a graph should make the conflicting records visible rather than quietly joining whichever one arrived last.

The sample records sources and validity on its agreement links. Its sample:// origins are labels for fictional evidence, so they cannot substantiate a real decision. Replace them with authorised records when testing your own question.

Check whether the relationship work is worth maintaining

A graph is useful when the same connections recur across questions: which client owns this work, which current rule applies, and which person can approve the next step. It can also expose missing connections, such as a task with no known agreement.

There is a maintenance cost. Someone must define relationship meanings, prevent duplicate identities and correct changed links. A graph does not automatically make source information reliable, enforce permissions or explain a causal change in a metric.

Try the question using your existing information structure first. If an organised client page answers it consistently, that may be enough. The knowledge-base comparison works through the same question in both structures.

Design the graph around a question