What Is a Context Graph?

Context management is the discipline of deciding what an AI system is allowed to treat as true about an organization, and keeping that true as the business changes. It is not the Kubernetes sense of context, switching between cluster configurations; not the CRM sense, the record a system keeps about a customer; and not the ITSM sense, the history attached to a ticket. A context graph is the structure that carries it, and the short answer to the question you came with is this: a knowledge graph models what things are and how they relate, while a context graph adds what is allowed and how work actually gets done.

How is a context graph different from a knowledge graph?

A knowledge graph gives you entities and the connections between them. Acme Corp is a customer. This order belongs to that customer. That product ships from this supplier. Modelled well, it captures how the business thinks rather than how a particular database happened to be normalized, and an agent can traverse it to answer questions that span systems.

What it does not carry is permission or sequence. It can tell a system that a discount exists on an order. It cannot tell the system whether that discount was allowed, who could have approved it, or whether the approval actually completed.

A context graph carries those too. Same entities, same relationships, plus two layers a knowledge graph leaves to the applications sitting on top of it.

What does a context graph add?

Rules. The validation, access and compliance constraints that govern the data, expressed in the graph itself rather than reimplemented in every application that touches it. Policy-as-code and SHACL are how this gets written down. Putting the constraints in the graph is what lets a system explain itself: the rule that blocked an answer can be named, which is the difference between auditable and merely observable.

Processes. A machine-understandable map of how work flows, so a system can reason about sequences, states and decisions rather than only facts. An agent asked whether a discount is approved needs to know what approval means here, which steps have completed, and whose sign-off ends the path.

Why does the distinction matter for AI?

Because the consumer changed. A person reading a dashboard supplies the missing layers from memory: they know the discount needs regional sign-off, and they know last quarter's numbers closed late. An agent supplies nothing. It acts on what the structure tells it and stops at what the structure omits.

The other half is governance at query time. A context graph is not only richer, it carries its own provenance and ownership: who agreed this, when, and what happens when it changes. That is what makes it trustworthy at the moment of the request rather than trustworthy as of whenever it was last reviewed.

There is a reason the structure is a graph rather than a set of documents the model reads. Inference inside a governed graph is constrained by the model it runs on, which makes it predictable, repeatable and deterministic. The higher the stakes of the question, the more the answer needs to rest on that kind of context rather than on a plausible reading of whatever was retrieved.

For the wider discipline this sits inside, start with context management. For why an inferred version of any of this cannot settle a disagreement, see inferred context. If you are choosing retrieval architecture, knowledge graph versus vector database and GraphRAG cover when each one wins.