What Is a Context Graph?
Key takeaways
- Ask what your graph carries besides entities and connections. If the answer is nothing, it cannot answer a permission question.
- Rules are what is allowed. Processes are how work gets done. Most models carry neither, because neither was ever treated as a data problem.
- A system can know an approval exists without knowing whether this one completed. That gap is where confident wrong answers come from.
- A knowledge graph tells a system what exists. A context graph tells it what it is allowed to do with that.
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. Other senses of the word are in circulation. Kubernetes uses it for switching between cluster configurations, CRM for the record a system keeps about a customer, ITSM for the history attached to a ticket. A context graph is the structure that carries it. The short answer to the question you came with is this. A knowledge graph models what things are and how they relate. 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, and an agent can traverse it to answer questions that span systems. Traversal of that kind is the mechanism behind GraphRAG.
What it does not carry is permission or sequence.
| Question about a discount on an order | Knowledge graph | Context graph |
|---|---|---|
| Does this discount exist, and on whose order? | Answers it | Answers it |
| Was this discount allowed? | Cannot answer. Constraints live in the applications above the graph. | Answers it. The rule is in the graph and can be named. |
| Who could have approved it, and did the approval complete? | Cannot answer. Sequence and state are not modelled. | Answers it. The process, its steps and the sign-off that ends it are modelled. |
| Who agreed this, and when does it expire? | Not carried. | Carried with the context, so the answer is defensible at the moment it is given. |
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 once in the graph, where every application can read them. 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 as well as 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. Maintaining that record is the work context management exists to do. It makes the graph trustworthy at the moment of the request, which is the only moment that counts.
There is a reason the structure is a graph. 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. A plausible reading of whatever was retrieved is all runtime context can ever be.
If your question is retrieval architecture instead of modelling, knowledge graph versus vector database is the comparison that matters first.
TopQuadrant builds context graphs on open standards: RDF, OWL and SHACL. The structure, the rules and the record of who agreed to them outlive the platform they were built on.
