What is a context graph?

A context graph connects what a business knows with what it decided: its records, their links, who may see them, and the decisions about them. Its nearest neighbor is the knowledge graph, which models entities and their relationships. A context graph adds time and judgment: which exception was granted, by whom, under which rule, and what it cited.

The term is young and used in two ways. Foundation Capital, and graph database vendors after it, use it for a record of decisions. Curiosity uses it for a typed, permission-aware graph of records from separate systems, served to people and models. This article explains both and where they meet.

The term spread after a December 2025 essay by Jaya Gupta and Ashu Garg of Foundation Capital. They describe decision traces as the exceptions, overrides, precedents and context across systems that live in chat threads, escalation calls and people’s heads. A context graph, in their words, is “a living record of decision traces stitched across entities and time so precedent becomes searchable.”

Their argument is about agents. A rule says what should happen. A trace says how the rule was applied last time, where an exception was granted and who approved it. An agent that can search those traces can follow precedent instead of guessing.

Neo4j’s comparison of the three terms draws the same line from the graph side: “A context graph expands the knowledge graph with conversation history and decision traces”. In that reading, a knowledge graph is the base and the decisions are the layer on top.

Curiosity describes its product as a context graph for industrial AI. There the weight is on the records: tickets, part records, maintenance logs and supplier notices from separate systems, connected into one typed graph. Each record keeps the access rights of its source, and the graph is what people and the model a customer chooses are given as context.

The two meanings guard against different failures. Without decision traces, an agent repeats a judgment call nobody wrote down. Without the records and their permissions, a trace points at things the agent cannot read, or shows them to someone who should not see them.

Dominik Tomicevic, who runs the graph database company Memgraph, makes the case for joining them in InfoWorld. He agrees that decision traces matter, and writes that “we need to broaden the definition to include entities, relationships, provenance, time, permissions, policies”, with traces among them.

A knowledge graph answers what exists and how it connects. Part P-220 is fitted on line 3, a notice changed its seal, the notice came from supplier S-12. It describes a state.

A context graph begins where a question needs more than that state. Three additions mark the line:

• Decisions, as records of their own: who decided, when, under which rule, about which record, and what they cited.
• Time: what was true when the decision was made, not only what is true now.
• Permissions: who may read each record and each decision, checked when the question is asked.

A knowledge graph can say which seal rev C uses. A context graph can also say why line 3 still runs it, and whether you are allowed to know. The word is not new to the field. Hogan and coauthors’ survey uses context for the setting in which a statement holds true, such as a time or a source.

Agents now act, not only answer. An agent that drafts a supplier claim or extends a deviation needs the facts and the precedent. Which notices affect the part, and what did the quality team allow last time?

Audits ask the same questions after the fact. Who approved this exception, on what evidence, and could they see that evidence? A graph that keeps the decision beside the records it was about can answer without a week of reading old email.

• Traces nobody recorded. A decision made on a call leaves no trace. The graph cannot hold what was never written down. The work is in capturing decisions where they are made: the approval step, the ticket, the agent run.
• Traces that point nowhere. A log of decisions about ids that no longer resolve tells you that something happened, not what it was about.
• Traces without permissions. A decision often names what it was based on: an audit finding, a price, a person. A trace everyone can read leaks what the records themselves restrict.
• Reasoning stored as fact. Foundation Capital is explicit that a context graph is not the model’s chain of thought. A model’s account of itself is a claim; the record of who approved what is evidence.

Five questions, asked of a real decision rather than a demo:

1. Pick a decision your team made last month. Can the graph show who made it, when, under which rule, and about which records?
2. Do the records it cites still resolve, and can you see the state they were in at the time?
3. Is each trace held to the same permissions as the records it mentions?
4. Where are traces written: at the moment of decision, by the system that carried it out, or rebuilt later from logs?
5. Do a person and an agent asking the same question get the same records, each within their own access?

Curiosity Studio starts from the records. Connectors bring tickets, part records, documents and messages from more than 70 systems into one typed graph, with their access rights. Access is checked per record at query time, so a person, an assistant or an agent sees only what the source would show them. What is a knowledge graph? covers that layer.

Decisions written down in a connected system arrive the same way, as records: a Jira issue, a Confluence page, a Teams thread. Where a decision exists only as a change of state, the documentation suggests modeling it as an event node linked to its record.

Studio also records the decisions made inside it. Each agent run is stored as a node with its status, result, timestamps and full transcript, as running an agent describes. A change Sudo stages is applied only after an administrator approves it, and the approval is recorded under that administrator’s name. The audit log can record searches, views and assistant replies, for the event types an administrator turns on.

Studio does not invent traces. A decision made on a call, and never written anywhere a connector reads, is not in the graph. An AI admin you can approve covers the approval step in detail.