All glossary terms
C Data & reasoning Architecture

Context graph

A knowledge graph tells an agent what is true. A context graph tells it when, where, and according to whom, which is the only version an agent can safely act on. In the formal literature, context means the scope of truth.

Definition

A context graph is a knowledge structure that stores not only what is asserted but the conditions under which each assertion holds: when it became true and for how long, where it applies, which source asserted it, and who may rely on it. In the formal literature, context refers to the scope of truth.

What is a context graph?

A context graph is a way of storing facts. It also records the conditions under which each fact holds. Researchers in this field use the word context in a precise sense. It means the scope of truth, the circumstances where data counts as true. It does not mean general background.

That definition is more useful than it first sounds. Almost every fact in an enterprise is true with respect to something. A city has existed since a founding date. A route opened in a particular year. A record was accurate as of the moment a system was read. Ordinary data models leave all of that implicit, and an agent cannot act safely on an implication.

Academic work has formalised several versions. Contextual knowledge graphs add explicit context sets and context relations to the usual entities and relations. Domain-contextualised approaches promote the domain to a first-class argument in every fact rather than a tag on the side, and support hierarchical domains with enforced separation between them. Context metagraphs treat whole context sets as nodes, which is what opens the door to hypergraph structure.

The concepts here are established rather than new, which matters for how you position them. Contextual graphs, context metagraphs and temporal hypergraphs all have formal definitions and a research literature behind them. What is new is applying them as the reasoning substrate under an agent rather than as a modelling exercise. Treat the underlying structures as prior art to build on and cite, not as a category to claim.

How is it different from a knowledge graph?

A knowledge graph asserts that something is true. A context graph asserts that something is true under stated conditions. The practical difference is that the second can be checked for whether it still applies, and the first can only be believed or disbelieved.

The contrast is easiest to see on a single fact rather than in the abstract.

The same fact modelled two ways. On the left, a knowledge graph edge asserting that a customer has a credit limit of fifty thousand, with nothing else recorded. On the right, the same assertion carrying four context dimensions: valid from a March review date until superseded in June, asserted by the credit system, applicable in one jurisdiction, and visible to a named role. Below, an agent reading the left version acts on an expired figure while the agent reading the right version detects that the fact has been superseded.
A knowledge graph and a context graph compared on what each records and what an agent can do with it
Question Knowledge graph Context graph
What it records Entities and the relations between them The same, plus the conditions under which each relation holds
Is it still true Unanswerable from the graph. The current state is the only state Answerable. Validity intervals are part of the assertion
Who says so Usually absent, or held in a separate lineage system Provenance attached to the fact itself
Where does it apply Not modelled. A fact is globally true or absent Scoped, and hierarchically where domains nest
Who may rely on it Enforced outside the graph, by filtering results A property of the assertion, so it travels with the fact

Two of those rows carry most of the value, and they are the two marked. Being able to ask whether a fact is still true, and who is permitted to rely on it, are the questions an agent has to answer before acting rather than after. A knowledge graph answers neither from its own structure.

Why do agents need the context and not just the fact?

Because an agent acts. A person reading a stale figure usually notices something is off, asks a colleague, or checks the source. An agent reading the same figure executes against it at full confidence, and a fact with no validity condition attached cannot be recognised as expired.

This is the practical case for context graphs and it holds even where the underlying data is perfectly accurate.

  • The expired fact. A credit limit, a price, an entitlement or an address was correct when recorded and is not correct now. Without a validity interval the graph presents it as current, and the agent has no basis to doubt it.
  • The contested fact. Two systems disagree, which is normal in any estate of scale. A context graph records both with their sources, so an agent can prefer the authoritative one or escalate. A knowledge graph forces a resolution at load time and hides that a disagreement existed.
  • The out-of-scope fact. A rule that applies in one jurisdiction, product line or entity, applied everywhere because nothing recorded its boundary. Hierarchical domains with enforced separation exist in the literature precisely to prevent this.
  • The fact the agent should not have seen. If permissions are applied by filtering after retrieval, a change in filter logic exposes everything. Modelling the permission on the assertion means the constraint travels with the fact wherever it is read.

That last point connects directly to the intersection rule described at agent identity: an agent's effective permissions should be the intersection of its own and the requesting user's. A permission modelled inside the graph is enforceable at the point of retrieval. A permission applied afterwards is a filter somebody can misconfigure.

Why hypergraphs rather than ordinary graphs?

Because real enterprise events connect more than two things at once, and an ordinary graph edge connects exactly two. Research on hypergraphs is explicit that converting a hypergraph into an ordinary graph loses the higher-order information, which is the technical case for the structure.

The distinction is formal rather than stylistic. An ordinary graph is a set of vertices joined by edges where each edge links a pair. A hypergraph joins vertices with hyperedges, where a single hyperedge can connect any number of vertices at once, so a relationship between five entities is one hyperedge rather than ten pairwise edges.

On the left, a single hyperedge connecting five entities that participate in one contract event: customer, product, term, signer and jurisdiction. On the right, the same relationship decomposed into ten pairwise edges, with a note that the fact they co-occurred as one event is no longer recoverable. A caption states that research on hypergraphs is explicit that converting to an ordinary graph loses higher-order information.

Why that matters for an enterprise: a contract is signed by a person, for a customer, covering a product, on a term, under a jurisdiction, at a moment. Those six things participate in one event. Flatten that into pairwise edges and each pair survives while the fact that they co-occurred as a single event does not. An agent can then reconstruct that a customer is linked to a product and cannot establish that the link came from this contract rather than another.

Adding time makes it a temporal hypergraph, formally a hypergraph with temporal attributes attached to the vertices, the edges, or the incidences between them. The literature also uses time intervals with a start and an end rather than single timestamps, which is what you need to express that something was true for a period rather than at an instant.

A word on how to talk about this externally. Temporal hypergraph is precise, established, and almost nobody outside research searches for it. Use it where technical accuracy matters, in architecture documents and analyst conversations, and lead with plainer language everywhere else. Higher-order relationships and validity intervals convey the same idea to a buyer who will not recognise the formal term.

Which context dimensions matter in a Context Graph?

Four earn their cost in almost every enterprise case: time, provenance, scope and permission. The literature offers more, and adding dimensions has a real price in modelling complexity and query cost, so the discipline is deciding which ones an agent will actually check.

Ordered by return, with the first two doing most of the work.

  1. 01
    Time, as two clocksWhen the fact became true in the world, and when your system learned it. Both, as intervals rather than instants. What it enables: asking what was true on a given date, which is the question every audit and every dispute begins with.
  2. 02
    ProvenanceWhich system or document asserted this, and when it was read. What it enables: preferring an authoritative source over a convenient one, and retaining disagreements instead of silently resolving them at load time.
  3. 03
    ScopeThe jurisdiction, entity, product line or domain in which the fact applies, hierarchically where domains nest. What it enables: stopping a rule that is correct in one context from being applied in another where it is wrong.
  4. 04
    PermissionWho may rely on this assertion, held on the assertion rather than applied afterwards. What it enables: a constraint that travels with the fact, so retrieval cannot return something the requester was never entitled to see.

Dimensions worth considering and not defaulting to: confidence, where a fact is inferred rather than asserted; and version, where a fact derives from a document that has editions. Both are useful in specific domains and both add query complexity that has to be paid for on every read.

How do you build one?

Mostly you do not build one from scratch, and that is the honest answer. The established pattern is a pipeline of acquisition, abstraction, storage, matching, reasoning and adaptation, and the decision that matters most is which context dimensions you commit to capturing at acquisition time.

The reason to be blunt about this is that a context graph project framed as a modelling exercise tends to produce a beautiful schema and no adoption.

  1. Decide the dimensions before the schema

    Which questions will an agent actually ask? If nobody will ever query as-of a date, the temporal dimension is cost without return. Pick the dimensions from the queries, not from the literature.

  2. Capture context at acquisition, because you cannot add it later

    Provenance and ingestion time are available for free at the moment data arrives and are effectively unrecoverable afterwards. This is the same argument made at data ingestion: what you fail to record at the boundary is gone.

  3. Model the relationship at its true arity

    Where an event genuinely involves several entities, model it as one higher-order relationship rather than a set of pairs. Flattening is easy and irreversible, so the default should be to preserve the arity and simplify at query time if needed.

  4. Keep disagreements

    Resist resolving conflicting assertions at load time. Retain both with their provenance and let the reasoning layer or the agent decide, because the fact that two systems disagreed is itself information an agent may need.

  5. Make it queryable in the agent's loop, not in a batch job

    A context graph that answers in seconds is a data asset. One that answers in milliseconds is part of the reasoning path. Agentic retrieval already carries a latency problem, covered at agentic RAG, and a slow graph compounds it on every iteration.

  6. Start with one domain that has a real dispute problem

    Entitlements, pricing, or anything where "what did we say and when" gets argued about. The value of context modelling is most visible where the absence of it currently costs somebody time, and that gives you an adoption case rather than an architecture diagram.

One honest caveat on where this sits. A context graph is a means rather than an end: it exists so an agent can establish whether a fact still holds and whether it may act on it. If your agents are failing for other reasons, and the reported failure causes are usually cost, unclear value and weak controls, a better graph will not change the outcome. See data intelligence for the broader question of what makes data usable by machines.

Frequently asked questions about context graphs

If your question is not here, our team will answer it directly.


Talk to a Specialist →
What is a context graph?

A graph that records the conditions under which each fact holds rather than only the fact itself. Formal work in this area uses the word narrowly: a fact's context is the set of circumstances that have to obtain for it to count as true. Almost every enterprise fact is true with respect to something, a date, a source, a jurisdiction, and ordinary data models leave all of that implicit. An agent cannot act safely on an implication.

How is a context graph different from a knowledge graph?

The first states a fact. The second states a fact together with the conditions it depends on, which is what makes it possible to check later whether those conditions still hold. Two differences carry most of the value: whether the graph can tell you if a fact is still valid, and whether it records who may rely on it. A knowledge graph answers neither from its own structure, so both get handled in systems alongside it or not at all.

Why do AI agents need context rather than just facts?

Because an agent acts on what it reads. A person seeing a stale figure often notices something is wrong, asks a colleague, or checks the source. An agent executes against it at full confidence, and a fact carrying no validity condition cannot be recognised as expired. The same applies to contested facts where two systems disagree, out-of-scope facts where a rule from one jurisdiction gets applied in another, and facts the requester was never entitled to see.

What is a temporal hypergraph?

A hypergraph with time attached. A hypergraph joins vertices with hyperedges, where one hyperedge can connect any number of vertices at once rather than exactly two, so a relationship among five entities is a single edge. Making it temporal means attaching time attributes to the vertices, the edges, or the incidences between them. The literature commonly uses intervals with a start and an end rather than single timestamps, which is what expresses that something was true for a period.

Why use a hypergraph instead of an ordinary graph?

Because real events connect more than two things at once and an ordinary edge connects exactly two. Research on hypergraphs is explicit that converting one into an ordinary graph loses the higher-order information. A contract signed by a person, for a customer, covering a product, on a term, under a jurisdiction is one event. Flatten it into pairwise edges and each pair survives while the fact that they co-occurred as a single event does not.

Which context dimensions should you capture?

Four earn their cost in almost every case, and the first two do most of the work. Time, as two separate clocks. Provenance, meaning which system asserted this and when it was read. Scope, meaning the jurisdiction or domain in which the fact applies. And permission, meaning who may rely on the assertion. Confidence and version are worth considering in specific domains and both add query complexity paid for on every read.

What are the two clocks in a context graph?

When a fact became true in the world, and when your system learned it. A price effective from the first of the month and ingested on the eighth has two different timestamps, and an agent asked what the price was on the fourth needs the first one. Most enterprise stores record only the second. Capturing both is the single highest-value context dimension available and usually among the cheapest, because both are known at the moment data arrives.

Should you resolve conflicting facts when loading a context graph?

No, and this is the instinct worth resisting. Two systems disagreeing is normal in any estate of scale. Retain both assertions with their provenance and let the reasoning layer or the agent decide, because the existence of a disagreement is itself information an agent may need, particularly where one source is authoritative and the other is merely convenient. Resolving at load time produces a tidy graph that has destroyed the evidence of the conflict.

Can you add context to an existing knowledge graph?

Partly, and the limits are worth knowing before you plan the work. Scope and permission can often be layered on afterwards because they follow from rules you already hold. Provenance and the point at which a fact became true generally cannot, because they were available at acquisition and are unrecoverable once discarded. Relationship arity is the hardest: once a higher-order event has been flattened into pairs, the original co-occurrence cannot be reconstructed from the pairs.

How does a context graph relate to GraphRAG?

One is the structure, the other is a retrieval approach over it. GraphRAG retrieves by traversing relationships rather than by matching text similarity alone, which suits multi-hop questions where the answer depends on a chain of connections. A context graph is what makes that traversal safe to act on, because it lets the retrieval establish not only that a relationship exists but whether it still holds and who may rely on it.

Do you need a context graph to run AI agents?

No, and it is worth being clear about that. Plenty of useful agents run against ordinary databases and document stores. A context graph earns its cost where agents act on facts that change, where sources disagree, where rules are scoped to jurisdictions or entities, or where you have to establish afterwards what was true at the time. If none of those describes your workload, the modelling effort will not pay back.

Where should you start with a context graph?

One domain where "what did we say and when" already gets argued about: entitlements, pricing, contract terms. The value of context modelling is most visible where its absence currently costs somebody time, which gives you an adoption case rather than an architecture diagram. Decide the dimensions from the queries an agent will actually run rather than from the literature, and capture provenance and timing at acquisition because neither can be added later.

Keep reading

Terms that come up in the same conversation

Browse the full glossary
D

Data intelligence

The broader question this sits inside: what makes enterprise data usable by machines rather than only readable by analysts.
D

Data ingestion

Why provenance and timing have to be captured at the boundary. What you do not record there is gone.
A

Agentic RAG

The retrieval loop that queries this, and why a slow graph compounds on every iteration.

Is that fact still true?
An agent cannot check a condition you never recorded

SERAA Axon builds relationships across sources as data arrives, over 100+ connectors and without moving everything into a lake first, then composes SQL, vector search and graph traversal in a single reasoning chain with each step logged.

Book a demo Explore SERAA Axon