Context Graph vs. Ontology: Why Each Needs the Other

If you’re building context for AI agents, you’ve probably heard both terms pitched as the answer. One camp says agents need a formal ontology before anything else. Another treats the context graph as the foundation and the ontology as a detail. Both can’t be the starting point, so which do you need?

Well, you actually need both, because they do different jobs:

• An ontology defines what things mean and how they relate to each other
• A context graph grounds that web of meaning in your data

The usual question is whether a context graph needs an ontology. But a more useful question runs the other way: Does an ontology need a context graph? It does, because an ontology that isn’t wired into a living context graph slowly turns into a precise description of a business that no longer exists. And that’s precisely why the ontology belongs inside your context platform, where it can grow, change under governance, and reach agents with everything they need to use it.

What is an ontology?

Where a glossary asks what a word means, an ontology asks what the metrics, concepts, and entities in your business are and how they relate. Take net revenue: A glossary entry defines it in a sentence. An ontology goes further. Net revenue is a type of revenue, it’s derived from gross revenue less returns and discounts, and it’s recognized according to specific rules. Those relationships and constraints are written precisely enough that a machine can reason over them, not just read them.

Ontologies sit at the top of a ladder most organizations are already climbing. As Stephen Goldbaum, our resident ontology expert, lays out in building the context layer in financial services, a dictionary standardizes terms, a data dictionary links them to the fields that store them, governed terms attach rules and constraints, and a taxonomy organizes terms into hierarchies. An ontology is the top rung: It specifies relationships with enough logical precision that a machine can derive conclusions nobody explicitly wrote down.

A business glossary is a strong starting point, but on its own it isn’t an ontology. What an ontology can’t tell you is where net revenue lives in your data, which table calculates it today, or whether that table refreshed this morning. That’s the context graph’s job.

Related: For how ontologies differ from metric definitions, see ontology vs. semantic layer.

What is a context graph?

A context graph is grounded in one organization. Its nodes are the actual tables, dashboards, pipelines, glossary terms, metric definitions, owners, and documents inside your company. In a context graph, net revenue is linked to the columns that calculate it, the finance dashboard that reports it, the team that owns it, the freshness of the pipeline that feeds it, and the runbook that explains its edge cases.

The term is still used loosely. Some people use it for that connected network of an organization’s data and knowledge. Others use it for the slice of context assembled for a single agent decision at runtime, or for a record of decisions and the reasoning behind them, an idea popularized by Foundation Capital.

Decision traces and runtime slices are useful, but both need something to attach to. A trace of a pricing exception means little if the agent can’t tell which pricing table is authoritative or who owns it. The grounded graph comes first.

Learn more about what a context graph is and how it relates to a knowledge graph in context graph vs. knowledge graph.

How does a context graph compare to an ontology?

The same concept plays a different role in each. Here’s how they line up:

	Ontology	Context graph
What it answers	What metrics, concepts, and dimensions mean and how they relate	Where those concepts live in your data, where the data came from, who owns it, and whether it can be trusted right now
What it’s made of	Data assets, lineage, ownership, quality signals, glossary terms, and documentation, connected by relationships	Glossary terms and metric definitions, with their relationships, plus data assets, lineage, ownership, quality signals, and documentation
What it’s grounded in	The logic of a domain	One organization’s data ecosystem
How it changes	Deliberately, through review and versioning	Continuously, as pipelines, owners, and data change
Who maintains it	Data architects, governance teams, and domain experts	Data platform and governance teams, supported by automated ingestion
What an agent gets from it	Consistent definitions and rules to reason with	The right asset, its current state, and who’s accountable for it
Risk when it stands alone	A precise model of a business that may no longer exist	Connected assets with no shared meaning across teams
Net revenue example	Net revenue is a type of revenue, derived from gross revenue less returns and discounts	The certified table and columns that calculate net revenue, the dashboard that reports it, its owner, and its freshness

The ontology supplies meaning, and the context graph supplies grounding. In practice, the definitions live in both: The ontology specifies what a concept means, and the context graph stores that definition alongside the assets that implement it. Each depends on the other, but the ontology’s dependence on the graph is the one teams tend to underestimate.

An ontology is only as true as what it’s connected to

The case for giving a context graph an ontology is that without shared definitions, a graph connects assets without agreeing on what they mean.

The reverse case gets less attention: An ontology on its own is a model. If the definition of net revenue lives in a modeling tool or a wiki, an agent reading it still can’t tell which column implements it, whether that column is current, or whether the pipeline behind it broke last week. The definition can be perfectly precise and still point at nothing. And because businesses change, a disconnected ontology drifts. An ontology built on stale metadata models yesterday’s business.

Connected to a context graph, the same ontology gains three things:

1. Grounding: Terms link to the columns and assets that implement them, so a definition points at real data.
2. Currency: Lineage, usage, ownership, and quality signals change as the data changes, so the ontology reflects the business as it is now.
3. Retrieval: When an agent looks up a term, it gets the definition along with its dependencies and the assets behind it.

That’s how DataHub treats business meaning. Glossary terms sit in the same graph as tables, dashboards, lineage, owners, and documentation, and the relationships between terms are part of the graph too. Custom relationships between terms turn a static glossary into a living ontology.

Grounding shows up in agent accuracy. When Miro put DataHub between its analytics agent and Snowflake, text-to-SQL accuracy on 900 real business questions rose from under 40% to over 90% for queries scoped to governed data products. Wrong-table routing fell from over 60% of cases to under 10%. Glossary terms anchored Miro’s most critical data products. They were one signal among several, alongside lineage, schema position, usage, and curated documentation, but they show what happens when meaning is attached to the assets that implement it.

What happens when a definition changes?

Businesses change what their words mean all the time.

Say finance decides net revenue should now exclude a new type of promotional credit. In a standalone ontology, that’s an edit to a definition. In a context graph, it has downstream consequences, just like a column change. Here’s what redefining net revenue reaches across the graph:

• Related terms: Any term that inherits from net revenue, or that net revenue contains, may need to change with it.
• Columns and tables: Every asset tagged with the term now has to match the new definition or be flagged.
• Dashboards and reports: Lineage shows which reports draw on those assets downstream.
• Data products: Products anchored by the term carry the definition to everyone who consumes them.
• Agents: Any agent that retrieves net revenue as context starts answering with the new meaning, whether or not the data underneath has been updated.

Govern a definition change the way you’d govern a schema change: Check the impact first, then route the change through review. When concepts and assets live in the same graph, you can see the impact of a definition change before you make it, rather than after a report contradicts the number finance presented.

DataHub Cloud’s Ontology Explorer makes this navigable. Teams can explore relationships between glossary terms visually from any term page, the same way they explore lineage, and trace how concepts connect before changing a definition. Teams can also define their own relationship types beyond the built-in ones, and agents that retrieve a definition get its dependencies alongside it. New glossary terms can be proposed through an accept/reject workflow, so additions are reviewed before they land.

Do you need a finished ontology before you start?

When definition changes can be seen and governed like data changes, the ontology doesn’t have to be finished before you start using it. It can grow.

Debate about ontologies for AI tends to split into two camps:

• One says to model everything formally before agents touch the data
• The other says to let machines learn the ontology from usage

A middle path is emerging. Databricks, for example, advises teams to model the head and let its Genie Ontology infer the tail. Teams deliberately define the concepts that must be right and let inference cover the rest.

Starting in the middle looks like this:

1. Pick one high-friction domain: Finance, where net revenue lives and where teams already reconcile numbers by hand, is a natural first choice.
2. Start with what you have: Your business glossary, semantic models, lineage, and ownership are the raw materials. In DataHub, term relationships such as Inherits (is-a) and Contains (has-a), along with nested Term Groups, give a flat glossary the structure to grow toward an ontology. These are available in both DataHub Core and DataHub Cloud.
3. Let AI propose and humans review: Automated derivation speeds up the first draft, but definitions that agents will rely on need a domain expert’s sign-off. The DataHub Context Platform routes AI-generated context to the domain experts who own it before agents see it. Learn more about human-validated semantic context.
4. Expand based on what agents actually ask: Each new domain grows the same graph rather than starting a separate model.

FIS learned why the review step matters. FIS was building a natural language query feature for its bank clients on mainframe data, where column names carried no business meaning. Databricks Genie’s automatic ontology derivation closed only part of the gap.

“That got us honestly about halfway there. In any large enterprise, the real knowledge is gonna be tied up in people’s heads, and I don’t know anybody that’s writing an adapter yet that can go into someone’s brain and pull that out.”

Frank ShowalterVice President of Data Engineering and Governance, FIS

DataHub supplied the rest by mining query history for semantic meaning and giving subject matter experts a place to review and approve context before it reached Genie. The result was better Genie accuracy and a new product line. In Showalter’s words, “We have domains, ontologies. It’s all in there. It’s shareable.”

When you still need a formal ontology

Growing an ontology incrementally doesn’t make formal ontologies obsolete. Regulated industries need conclusions that are deterministic and auditable, and LLM inference is probabilistic. In financial services, shared formal models like the EDM Council’s FIBO exist for exactly this kind of precision.

“Formal ontologies encode what things mean in relation to each other with enough precision to support automated inference.”

Stephen GoldbaumField CTO, DataHub

LLMs help here too. They can extract concepts from documentation and propose relationships for experts to confirm, which makes formal ontologies easier to maintain. The practical rule: Formalize the concepts where inference must be guaranteed, and keep every concept, formal or not, connected to the data it describes.

How DataHub connects the ontology to the context graph

The DataHub Context Platform keeps the ontology and the context graph in one place:

• One graph: Glossary terms and their relationships sit alongside tables, dashboards, lineage, ownership, quality signals, and context documents, ingested from 150+ systems.
• Meaning that follows the data: In DataHub Cloud, glossary term propagation (open beta) carries terms to downstream columns and assets through lineage, so derived tables inherit the meaning of their sources.
• Governed growth: Stewards propose glossary terms, domains, and data products through an accept/reject workflow, and AI-generated context routes to domain experts for review.
• Agent access: The DataHub MCP Server and Agent Context Kit expose the context graph, business definitions included, to Claude, Cursor, and custom agents.

Data leaders increasingly treat that infrastructure as a requirement. In DataHub’s State of Context Management Report 2026, 83% of IT and data leaders agreed that agentic AI cannot reach production value without a context platform. For the criteria that separate a production-grade platform from the rest, see 10 Principles of Enterprise Context Platforms.

An ontology tells agents what your business means. A context graph tells them whether that meaning still matches your data. Build them together, one domain at a time, and the ontology gets more accurate as the business changes instead of less.

FAQs

What’s the difference between a context graph and an ontology?

An ontology defines what things in a business mean and how they relate, using classes, properties, relationships, and constraints. A context graph connects those meanings to the actual data assets, lineage, owners, data quality signals, and documentation inside one organization. The ontology supplies meaning. The context graph supplies grounding, so agents can find the right data and judge whether to trust it.

Do you need an ontology to build a context graph?

No, but a context graph becomes more useful as shared meaning grows inside it. Most organizations start with a business glossary connected to their data assets, then add relationships between terms to move toward an ontology. Starting with one domain lets the ontology grow from real usage instead of a long modeling project that delays enterprise AI initiatives.

How do you keep an ontology up to date as the business changes?

Connect it to live metadata and govern changes to concepts the way you govern changes to data. When glossary terms are linked to the assets that implement them, lineage and quality signals show when production data drifts from the definition. Routing proposed definition changes through review, with an impact check first, keeps the ontology current without breaking downstream reports or agents.

Can AI build an ontology automatically?

AI can draft much of one by extracting concepts from documentation, query history, and schemas and proposing relationships between them. It can’t capture enterprise knowledge that was never written down. FIS found that automatic ontology derivation got it about halfway there, and subject matter experts supplied the rest. Treat automated output as a first draft for human review.

How do AI agents use an ontology and a context graph together?

An agent uses the ontology to interpret a question, resolving which concept a term like net revenue refers to and how it relates to other concepts. It uses the context graph to act on that interpretation: finding the certified asset that implements the concept, checking its freshness and ownership, and retrieving related documentation. Through the DataHub MCP Server, agents and other AI systems get business definitions and their dependencies alongside the assets behind them.

Is a context graph a record of decisions?

Some people use the term that way, to describe a graph of decision traces that captures why actions were approved. Decision traces are valuable, but they need a foundation to attach to: the enterprise data, owners, definitions, and trust signals the decisions were about. In DataHub’s definition, a context graph is that grounded network of an organization’s metadata and knowledge, and decision context builds on top of it.

When do you need a formal ontology like OWL?

You need one when conclusions must be deterministic and auditable, such as regulatory scope determination or exposure analysis in financial services. Formal ontologies support guaranteed inference, while LLM reasoning is probabilistic. Most organizations don’t need to formalize everything. Formalize the concepts where precision is mandatory, and keep them connected to the data they describe.