AI Reasoning Data Architecture: Ontology and Semantic Layers

An ontology is a formal, machine-readable model of what things are in your business, how they relate, and the rules that govern them — not just how a metric is calculated. That distinction sounds academic until you try to put an AI agent on top of your data and discover it can answer "what was revenue last quarter?" but not "which customers are at risk, and why?" This post walks through three ideas that are often conflated — semantic layers, ontologies, and context graphs — and explains, in plain business terms, why the distinctions are becoming decisive for your AI reasoning data architecture.

It builds on and draws inspiration from Jessica Talisman's article "Ontologies, Context Graphs, and Semantic Layers: What AI Actually Needs in 2026". We recommend reading the original; this piece distills the core argument and adds a practical lens for leaders deciding where to invest in their knowledge graph for enterprise AI strategies.

The problem semantic layers were built to solve

By the late 2000s, every organization with more than one database faced the same crisis: different teams defined "revenue" differently, analysts spent most of their time cleaning data, and executives couldn't trust dashboards because the numbers changed depending on who built them.

The semantic layer was the answer: define each metric once, govern it centrally, and let business users self-serve without writing SQL. When Looker launched LookML in 2012, co-founder Lloyd Tabb called it "the sequel to SQL." And for what it was designed to do, it worked — consistent metric definitions, standardized calculations, one source of truth for reporting.

But a quiet assumption was baked in: that the core problem was calculation. That if we standardized how metrics were computed, meaning would follow. It doesn't. Knowing that revenue is SUM(order_total) WHERE status = 'completed' tells you nothing about why revenue dropped, which customers are churning, or what to do next. When evaluating semantic layers vs ontologies, it becomes clear that layers model metrics; they do not model your business.

What an ontology actually is

While the BI world perfected metric consistency, other fields were solving a fundamentally different problem. Life sciences needed to integrate thousands of studies that used different vocabularies. Healthcare needed decision support that understood both patient data and medical knowledge. Their answer was the ontology: a formal, explicit specification of a shared way of understanding a domain.

Concretely, an ontology defines:

Classes — the kinds of things that exist (a Customer, an Order, a Product).
Properties and attributes — what those things can have or do.
Relationships — how things connect, with explicit, typed meaning (a Customer places an Order; an Order contains Items).
Rules for inference — logic that lets a system derive new facts from what it already knows.

These are expressed in open, machine-readable standards: RDF for representing facts as relationships, OWL (the Web Ontology Language) for classes, properties, and logical constraints, and SKOS for organizing vocabularies and taxonomies. This structural depth defines a robust AI reasoning data architecture.

Two long-proven examples show why this matters:

The Gene Ontology has been foundational to bioinformatics for over two decades. It doesn't just count genes—it models what genes are, which biological processes they participate in, and how those concepts relate so that researchers can reason across the whole domain.
SNOMED CT in healthcare has 350,000+ concepts and millions of relationships. It lets systems understand that "myocardial infarction" and "heart attack" are the same thing, that it is a kind of ischemic heart disease, and how it links to symptoms and treatments.

The takeaway in the ontology vs semantic layer debate: a semantic layer tells you what your revenue is. An ontology can represent that a customer is a class with attributes, that they placed an order, that the ordered items relate to other products in a defined market — and, crucially, it can infer new knowledge from those explicit relationships. One optimizes for measurement; the other optimizes for meaning.

Knowledge graphs and context graphs: capturing the "why"

A knowledge graph is an ontology brought to life with real data — the classes and relationships populated with your actual entities. It can tell you that a specific customer placed a specific order.

A context graph goes one step further. It captures the reasoning behind decisions. Traditional systems record what happened; a context graph records why it was allowed. A context graph can tell you why an order was approved despite violating standard terms, what precedent existed for similar exceptions, who had authority to approve it, and what conditions justified the deviation. It turns tacit reasoning into a living, queryable record.

This institutional memory is what AI agents need to handle ambiguous, judgment-heavy situations—and it is why Palantir Foundry bet on an ontology-first, context-first AI reasoning data architecture back in 2012. While semantic layers were perfecting metric consistency, Palantir focused on representing the domain's entities and their context. Building context graphs is fundamentally a knowledge management problem: eliciting expert reasoning and encoding it formally via architectures like the Procedural Knowledge Ontology (PKO), rather than leaving it trapped in institutional memory no system can index.

The YAML problem: metrics dressed up as meaning

Here is what much of the modern data stack got wrong: we tried to encode business meaning in YAML files. A typical dbt / MetricFlow semantic model looks like this:

semantic_models:
  - name: orders
    entities:
      - name: order_id
        type: primary
    measures:
      - name: order_total
        agg: sum

That is excellent metric governance. But it is a model of a calculation, not a model of a business. It captures tables, columns, and join paths — database plumbing — with no real relationships, definitions, or context. Within a modern AI reasoning data architecture, this is insufficient for autonomous reasoning.

An ontology represents the same domain in very different ways. It states explicit facts and then infers more:

EXPLICIT FACTS:
:Alice   :placedOrder :Order001 .
:Order001 :hasItem   :Item001 .
:Item001 :itemProduct :Laptop .
:Alice   :customerLifetimeValue "1250.00" .

INFERRED AUTOMATICALLY BY A REASONER:
:Alice   a :HighValueCustomer .
:Alice   :purchased :Laptop .
:Order001 :orderedBy :Alice .
:Laptop  :frequentlyBoughtWith :Mouse .

The ontology recognizes that an order is a type of business transaction, distinct from a quote or invoice, and that a customer is a type of person. That is, a YAML config cannot hold that meaning. The honest conclusion: metric definition and knowledge engineering are different disciplines — you wouldn't ask a financial analyst to build clinical terminology, and modeling a domain's knowledge structure is not the same job as calculating metrics.

Why AI changes the calculus

In October 2023, dbt Labs introduced MetricFlow, stating that "the semantic layer is the critical component to build a bridge between AI and structured data." They are right about the destination; the question is whether a metrics-first architecture can get there on its own.

AI agents don't consume dashboards. They consume semantic representations. As Anthropic's engineering team puts it, context engineering is "the discipline of designing a system that provides the right information and tools, in the right format, to give an LLM everything it needs to accomplish a task." An LLM needs to understand what things are, how they relate, and what actions are possible. A semantic layer acts as a lookup for governed metrics; an ontology enables reasoning by grounding the AI in structured domain knowledge that exceeds metric constraints.

This is why healthcare AI relies on clinical ontologies and why drug discovery platforms are built on biomedical knowledge graphs. Domains that invest in formal knowledge representation are ahead in the AI context game.

The architectural difference at a glance

Dimension	Semantic Layer	Ontology / Knowledge Graph
Primary consumer	Humans, via BI tools	Systems and AI, plus humans
Optimizes for	Measurement & consistency	Meaning & reasoning
Core artifact	Metric definitions, dimensions	Classes, relationships, inference rules
Answers	"What is X?"	"Why / how / what if?"
Standards	YAML configs, SQL	RDF, OWL, SKOS
Skills required	Analytics engineering	Knowledge engineering, domain modeling
Effort to build	Relatively fast	Deeper, iterative investment

Both are valid — they answer different questions. This is the same "refine raw data into meaning" discipline we describe in our medallion architecture and unstructured data guides; ontologies make the refined layer reasonable for machines through a proper AI reasoning data architecture.

Is there a middle ground?

The obvious hope is a "context-aware semantic layer" that keeps metric governance while adding ontological richness. The Open Semantic Interchange initiative — which dbt Labs joined alongside Snowflake and Salesforce — hints at this direction. But the gap is wide: YAML configurations and formal ontologies embody different theories, tooling, and skill sets, and bolting inference rules onto a system designed for SQL generation can amount to building a knowledge graph from scratch anyway.

A fair skeptic will note that the Semantic Web was hyped 20 years ago and that most ontology projects have stalled. That's true — ontology construction needs rare skills and sustained commitment. What's different now is the stakes: AI makes knowledge reasoning business-critical for everyone, not just data specialists.

What this means practically

If you're building an AI analyst, you need knowledge representation, not just metrics. If your representation is only metric definitions, your AI can only answer calculation questions — never reasoning or inference questions.
If you're evaluating a semantic layer, ask a single question first: "Is this for humans or for AI?" Most organizations end up needing both, but the architectures differ.
If you're considering an ontology, prepare for a different kind of investment — domain expertise, knowledge engineering, and iterative refinement — and treat knowledge representation as a core competency, not a side project.
Start small and domain-first. Model one high-value slice of your business (customers and orders, claims and policies, assets and procedures), prove that inference and AI reasoning create value, then expand.

Consistent metrics are now table stakes. Competitive advantage goes to organizations whose data architecture can support AI reasoning about concepts, relationships, and domain knowledge—the ones that solve for meaning, not just calculation.

Frequently Asked Questions

What is the difference between a semantic layer and an ontology?

A semantic layer standardizes how metrics are calculated. As a result, humans get consistent numbers in BI tools—it answers "what is X?" An ontology models the concepts, relationships, and rules of a domain in machine-readable form so systems and AI can reason and infer—it answers "why, how, and what if?" One optimizes for measurement, the other for meaning.

What is an ontology in simple terms?

It's a formal, shared model of what exists in a domain (classes), what it can have or do (properties), how things connect (relationships), and the logical rules that let a system derive new facts (inference). Think of it as a machine-readable map of meaning rather than a spreadsheet of numbers.

What is a context graph?

A context graph is a knowledge graph that also captures the reasoning behind decisions — not just that an order was approved, but why it was approved despite violating standard terms, who had the authority, and what precedent applied. It turns tacit, undocumented reasoning into a queryable record that AI agents can use.

Why do AI agents need ontologies instead of dashboards?

Large language models reason over concepts and relationships, not charts. To act reliably, they need to know what things are, how they relate, and what actions are possible. Ontologies and knowledge graphs provide that structured, inferable context; metric definitions alone only support calculation questions.

Are RDF, OWL, and SKOS required to build an ontology?

They are the mature, interoperable W3C standards most formal ontologies use — RDF for facts as relationships, OWL for classes and logical constraints, and SKOS for taxonomies and vocabularies. You can start pragmatically, but these standards give you portability, tooling, and automated reasoning that ad-hoc formats do not.

Can we extend our existing semantic layer into a knowledge graph?

Sometimes partially, but often not cleanly. Semantic layers are built for SQL generation and metric governance; adding classes, typed relationships, and inference frequently requires such fundamental changes that you effectively build a knowledge graph alongside it. Initiatives like Open Semantic Interchange aim to narrow the gap, but the two remain different disciplines.

Ontologies, Context Graphs, and Semantic Layers: What AI Actually Needs to Reason