Knowledge graph: why a network beats a filing cabinet

A knowledge graph doesn’t store documents, it stores things and the relationships between them: process X is owned by role Y, uses system Z and falls under standard N. Instead of text to read, you get a network you can query — by connection, not by keyword.

The difference from a filing system

A filing system knows files. It can tell you which document contains a word, but not what that document has to do with another one.

A graph knows nodes and edges instead. Nodes are the things: a process, a role, a system, a rule, a site. Edges are the relationships between them: owns, uses, triggers, applies to. Together they form a structure that answers questions no search can:

• Which workflows depend on this one system?
• Which processes is this role responsible for — and what happens if it disappears?
• Which rules affect the site we’re currently migrating?

What this has to do with processes

Processes are a network by nature, not a list. One step triggers the next, one role appears in eight workflows, one standard applies to thirty. A document can only tell that story in sequence — and what is told in sequence loses the cross-connections.

That’s exactly why a graph is a better fit for process knowledge than a folder full of descriptions. It holds what a process map shows — only machine-readable, and without being confined to a single level.

What a graph makes visible

The real gain isn’t the query. It’s what surfaces when things are laid side by side:

• Contradictions. Two sources describe the same workflow differently. In separate documents that never shows; in a network they sit next to each other.
• Dependencies. You only see which workflows hang off a system once the connections are recorded — and it is usually more than expected.
• Orphaned rules. A policy that no longer points at any process is either redundant, or the process is missing. Either way, that’s a finding.

Rule of thumb: a filing system answers “where is this written down?”. A graph answers “what depends on it?”. The second question is the one asked before every migration.

Why it matters for AI initiatives

A language model can phrase things beautifully and still know nothing about your organisation. For an agent to be useful, it needs a foundation: which workflows exist, who decides, which rules apply. A graph is the form in which that can be handed over — more reliable than a stack of PDFs, because the relationships are stated outright instead of implied.

One thing matters here: what a model produces on that basis is a proposal with a source reference — traceable back to the passage it came from. It becomes insight only once someone in the organisation checks it.

Limits

A graph is only as good as what goes into it. Three things it cannot do:

• It doesn’t replace the gathering. If nobody knows how a workflow really runs, the graph doesn’t either.
• It is never complete. Anyone promising completeness has smoothed over gaps — and the gaps are almost always where an initiative later gets stuck.
• It isn’t an end in itself. A network nobody works with is just a more elaborate filing system.

From document to structure

The detour many take is a graph project of its own: model first, populate later. It drags on, and it often fails because the modelling is finished before anyone has the content.

The shorter route runs through what is already there. When a work instruction is captured as a structured workflow — with roles, steps and systems as explicit fields rather than prose — the structure emerges while you document. That is how ProcessCollector works: you capture workflows the way you know them, and the network behind them grows with it, without anyone maintaining it separately.

In short

A knowledge graph turns descriptions into a queryable structure. Its value isn’t the technology but the fact that connections become visible which stay invisible in documents — contradictions first.