Context Graph vs Knowledge Graph: Same Shape, Different Scope

If you have spent any time in the data infrastructure or AI agent conversation lately, you’ve probably noticed that “context graph” and “knowledge graph” are starting to get used interchangeably. Sometimes by the same person, in the same sentence.

Most of the time, the people using them that way are right: The two terms describe structurally similar things, and most attempts to draw a sharp line between them end up inventing a distinction that does not actually exist.

The honest reality is that context graphs and knowledge graphs share the same underlying shape. But there is a meaningful difference: Scope and grounding.

• A knowledge graph models entities and semantic relationships in a domain to support general reasoning.
  
• A context graph models a specific organization’s data, decisions, and institutional knowledge to support reasoning grounded in that organization.
  

Once you see the difference, the vocabulary stops being the interesting part of the question.

What is a knowledge graph?

The term comes from the semantic web tradition. Its lineage runs through RDF, OWL, SPARQL, and the linked data movement that grew up around the W3C in the early 2000s. The concept hit mainstream awareness in 2012, when Google introduced its Knowledge Graph as the structure behind the answer panels that started appearing alongside search results. Wikidata, schema.org, and a generation of biomedical and enterprise knowledge graphs came out around the same time.

What unites all of these is the structural pattern. A knowledge graph stores entities (a person, a company, a product, a city) as nodes, and connects them through typed semantic relationships (works at, manufactured by, headquartered in). Most knowledge graphs are grounded in an ontology that defines what kinds of entities and relationships are allowed. The classic job of a knowledge graph is to answer questions about what is generally true: What is a customer, what cities are in Canada, which companies belong to which industries.

That generality is the key. A traditional knowledge graph is usually a world-model. It tries to capture facts about a domain in a way that holds across organizations, applications, and contexts.

What is a context graph?

Structurally, a context graph looks the same as a knowledge graph. Entities and typed relationships, often grounded in a schema. The shape is not what makes it different. What makes it different is what is in it and where it is grounded.

A context graph is built around a specific organization’s data ecosystem and the enterprise context that surrounds it. Its nodes are not generic entities like “company” or “city” in the abstract. They are the actual data assets, pipelines, dashboards, models, glossary terms, owners, and teams that exist inside one company.

And it goes further than structural metadata. A well-maintained context graph extends into knowledge management at scale: the documents that explain those assets, the decisions that produced them, the discussions that shaped how they should be used.

We’ve written a longer piece on what a context graph is and what goes into building one. The short version, for this post, is that a context graph is the graph an organization builds about itself.

Why the ‘context graph’ emerged when it did

The language did not appear out of nowhere. It surfaced because general-purpose knowledge graphs were not enough for the use cases that AI agents are now creating inside specific businesses.

An AI agent answering a question like “which dashboard should I trust for Q3 revenue” does not need a model of what a dashboard is in general. It needs to know which dashboards exist in your warehouse, which ones are certified, which team owns them, when they were last refreshed, and what known issues your data engineers flagged in Slack last week. That is grounded, organization-specific reasoning, and a world-model knowledge graph cannot provide it.

The “context” framing surfaced because that is what was missing. It is also a useful corrective to the assumption that context for an AI agent means stuffing more documents into a retrieval pipeline. As Kurt Cagle argued recently in The Ontologist, a context graph is structured knowledge that needs to be deterministic and governable, not a vibes-based retrieval blob. LLMs can help build it, but the graph itself is infrastructure.

We have written more on this distinction in retrieval augmented generation (RAG) vs context management.

The confusion: Why this has become a hotly debated distinction

Both definitions on the table now describe entity-relationship graphs. The graph structure is identical. So why are people arguing about it?

The cleanest explanation is that the two terms come from different communities that ended up in the same room:

• “Knowledge graph” is the AI and semantic web community’s term, with a couple of decades of familiarity behind it.
  
• “Context graph” is newer, and it is surfacing from the LLM and data infrastructure crowd.
  

When an ML team says “knowledge graph” and a data platform team says “context graph,” they often mean structurally similar things. They are just using the vocabulary their team has been using.

Cagle, who has spent years in the semantic web world, puts it about as plainly as anyone has: Context graphs are largely what the AI community has been calling knowledge graphs all along, just with the vocabulary catching up to a new set of use cases. We think that is the right read of the structural question. Where it gets interesting is not whether the structures are the same, but whether the jobs they are doing are the same. They are not.

The real distinction: Scope and grounding

Here is the distinction that actually matters, and that most discussions keep missing.

The difference between a context graph and a knowledge graph is not graph technology, schema choice, query language, or generational hierarchy. It is scope and grounding.

• A traditional knowledge graph is a world-model: It answers questions about what is generally true about a kind of thing. Wikidata can tell you what a city is, which countries border France, and what year a film was released. An enterprise knowledge graph can tell you which suppliers serve which industries in general. These are facts that hold across organizations.
  
• A context graph is an organization-model: It answers questions about what is true about this organization’s data, right now, and why it exists the way it does. It does not try to model the world. It tries to model one company’s data ecosystem and the institutional knowledge wrapped around it.
  

Both kinds of graphs are valid. They serve different jobs. The vocabulary tracks the community that built each tradition more than it tracks any deep architectural difference. If you want to call your context graph a knowledge graph, nobody is going to stop you. The question worth asking is not which word to use. It is whether the graph you have is grounded in the world or in your organization, and whether that grounding matches the job you need it to do.

What a context graph enables that a generic knowledge graph doesn’t

Once the scope question is settled, the practical consequences fall out naturally. Here is what a context graph adds that a world-model knowledge graph, on its own, cannot do.

• Impact analysis grounded in your actual systems: Before you change a column in a source table, you can traverse the graph to see which downstream pipelines, dashboards, models, and reports depend on it. A general-purpose knowledge graph cannot tell you that, because it does not know your pipelines exist.
  
• Root cause investigation across your stack: When a metric looks wrong, you can trace it backward through the specific transformations, joins, and sources that produced it. The graph knows the path because the path is part of the graph.
  
• Reasoning that AI agents can actually rely on: An agent working inside your business needs to know which assets are trusted, which are deprecated, which documents explain a metric definition, and who owns the answer when it does not. That is grounded reasoning over your meaning and your trust signals, not pattern matching against general world knowledge.
  
• Onboarding for humans and AI tools alike: A new hire and a new agent both face the same problem on day one: most of the answers they need used to live in the heads of specific people. A context graph captures that institutional knowledge in a structure both can query.
  
• These are not hypothetical use cases: They are the everyday work of data teams, and they are exactly the work that breaks down when the only thing your graph knows is structural metadata.
  

Where DataHub fits

DataHub is built as a graph for your enterprise data. Every asset, team, pipeline, glossary term, business definition, and lineage edge is a connected node. That graph started its life as a metadata graph, focused on the technical relationships between data assets. It has now extended into a context graph by bridging structured technical metadata with the unstructured institutional knowledge that surrounds it, ingesting external knowledge sources like Confluence pages, Notion docs, and Context Documents and connecting them to the assets they describe.

We go deeper on the technical side of how that graph works in our post on the metadata knowledge graph.

The relevant point here is just that the abstract argument has a working instantiation: A context graph is not a thought experiment. It is the structure underneath every impact analysis query, every lineage traversal, and every grounded answer an agent gives when it is reasoning about your data.

But the question worth spending time on is not which word to use. It is whether your graph is grounded in the world or in your organization, and whether the grounding matches what your business and your AI agents actually need. If you are building something that needs to answer questions about your data, your decisions, and your meaning, you are building a context graph, regardless of what your team calls it.

FAQs