Semantic Views: From Preserving Human Meaning to Materialized Context for AI Analysts

Most data problems don’t start with bad data. They start when meaning fails to travel across teams, tools, and time.

In small teams, meaning travels socially. Analysts, operators, and leaders share context implicitly — through hallway conversations, shared documents, tribal knowledge, and intuition. If someone asks, “Does this include refunds?” someone else answers. But as organizations scale, that social layer collapses. Definitions drift, assumptions go undocumented, and context lives in people’s heads — not in systems.

At that point, data doesn’t fail because it’s wrong, it fails because its meaning is unstable.

Semantic views were created to solve exactly that problem: guaranteeing consistent meaning as data is used for insights.

Why humans cope and systems don’t

Humans bring invisible context to data interpretation:

Shared vocabulary
Institutional memory
Intuition for “what looks off”
The ability to ask questions

When something seems ambiguous, humans stop and clarify. Systems don’t. They answer exactly what was asked, even when the question itself is unclear.

This gap between implicit human context and literal machine interpretation is at the heart of why semantic views exist.

What semantic views actually solved

In the BI world, semantic views addressed some key data issues:

Preserving meaning as data moves

Semantic views aren’t a BI gimmick. They are a business semantics abstraction that translates raw data into business concepts. In essence, they sit between data storage and analytics tools, converting table structures into familiar business terms such as product, customer, or revenue — and defining consistent ways to calculate those metrics across the organization.

This abstraction means that analysts and non-technical users no longer need deep schema knowledge or repetitive SQL logic to get the same answer to the same question. Semantic views centralize metric definitions so that every report and dashboard maps back to a shared understanding — eliminating inconsistent KPI definitions and redundant work.

Get our guide to semantic layers here → [Link]

Forcing organizational alignment

Because semantic views require explicit definitions, they surface questions that teams often avoid until it’s too late:

What exactly is “revenue”?
Is this definition universal or specific to a team?
Which rules apply to this metric and which do not?

This inefficiency and confusion across data and business teams often delays analysis and subsequent decision-making.

This isn’t just technical modeling, it’s capturing organizational negotiation in structure. Teams that skip this step may find dashboards built on shaky foundations, because business intent was never truly codified.

Enabling bounded exploration

Semantic views make self-serve analytics possible by establishing a bounded analytical universe where questions can be explored without redefining meaning each time. The semantics provide the rules of the road — the vocabulary and boundaries where analytic inquiry is valid.

One common approach to establishing a bounded context is by defining it around domains and subdomains. For instance, a bounded context for the Finance domain would encapsulate the semantic definitions of metrics like EBITDA and ARR.

This idea of bounded context is what gives meaning to explore-through-BI tools and supports consistent interpretation across all teams.

A brief history (through the lens of the problem)

The problems that semantic views solved for the BI world aren’t necessarily viable in the AI world. But to understand why, we need to take a look back in time at their evolution.

1. Protecting humans from database complexity

Early BI tools like SAP BusinessObjects, IBM Cognos, and MicroStrategy implemented semantic layers to shield users from technical schema complexity — helping analysts and business users work in business terms rather than table structures and join logic.

This pattern was fundamental: abstract away complexity, provide a business-friendly model, and standardize interaction.

2. Ontology as code — Looker’s LookML

Looker changed the semantics conversation by putting semantic models into version-controlled code via LookML. LookML defined dimensions, measures, joins, and business logic in a first-class modeling language, enabling governance and repeatability.

However, this era exposed a structural gap: data teams defined the ontology; business teams primarily consumed it. Since the two groups speak different languages – the data teams operating in technical terms and the business teams using business terms – the semantic view was technically correct, but often socially incomplete.

3. Centralized metric contracts — The dbt Semantic Layer

Modern semantic innovations like the dbt Semantic Layer explicitly position semantics as a shared contract across all BI tools and analytical destinations. By defining metrics in a central location, they ensure the same definitions travel downstream, regardless of the tool in use.

This reduces duplication, governance headaches, and inconsistency, but still assumes humans will ultimately reconcile ambiguity — an assumption that breaks in an AI-driven world.

Why AI analysts change the equation

AI analysts don’t lack intelligence — they lack ambient organizational context. Unlike humans, AI cannot:

Pause to clarify assumptions
Detect that something “looks off” without explicit signals
Negotiate meaning socially

AI models operate entirely on the provided context, and that context is finite. If they’re not trained on it, they won’t know it – and they don’t know how to say “I don’t know.”

This fundamental limitation forces a key shift: semantic views must not only preserve meaning — they must materialize it for AI.

Semantic views as materialized, bounded context

Semantic views are no longer helpful abstractions — they are materialized analytical contexts.

Semantic views have become bounded analytical contexts — explicitly defined scopes of meaning that an AI agent can reliably interpret.

This resembles the concept of bounded context in domain-driven design: a disciplined scoping of meaning to avoid ambiguity and conflict. In the same way, semantic views must define what can be interpreted and what cannot — both inside and outside that boundary.

LLMs have limited context windows and work probabilistically. An unbounded semantic layer invites inconsistency and hallucination; a bounded one constrains interpretation and encodes what not to assume.

New expectations from semantic views in the AI era

Explicit over implicit

Anything a human would have “just known” must become part of the semantic context.

Historically, humans supplied missing assumptions:

“This metric is monthly.”
“We exclude internal accounts.”
“We use net revenue, not gross.”
“The dashboard is in UTC, but we report in PST.”

AI won’t infer that correctly. It will guess – and guessing produces confident wrong answers.

One of the most common examples is time window ambiguity.

Imagine a user asks: “What was revenue last month?” A human analyst would potentially know last month = last calendar month, in local timezone, excluding partial days.

AI, on the other hand, could interpret “last month” as:

Last 30 days (rolling window)
Last complete month in UTC
Last fiscal month

In a semantic view, you would avoid this by defining:

“Last month = previous calendar month in America/Vancouver timezone”
“Revenue = net revenue excluding refunds”
“Recognized revenue definition vs booked revenue”

This way, AI doesn’t guess; it follows a contract.

Multiple, scoped truths

Semantic views should support multiple definitions with explicit scope, rather than forcing a single “truth” that fails in edge cases.

In real organizations, many concepts have multiple valid meanings:

Revenue (finance vs sales)
Churn (logo churn vs revenue churn)
Active user (product vs marketing)

Humans can navigate this through conversation (“which churn do you mean?”). AI needs the definitions to be explicitly scoped.

For example, “Revenue” differs by team.

Finance revenue might mean:

Recognized revenue
Excludes credits and refunds
Follows accounting rules

Growth revenue might mean:

Booked revenue
Includes trials converting
Closer to pipeline performance

In a semantic view, you encode:

revenue_finance → definition + accounting rules + owner “Finance”
revenue_growth → definition + inclusion rules + owner “Growth Ops”
Synonyms: “recognized revenue” → finance revenue, “bookings” → growth revenue

So the AI can:

Ask a follow-up question (“Do you mean finance or growth revenue?”), or
Default safely based on the user’s role/team context if known.

Question-bounded design

Question-bounded design is the practice of shaping a semantic view around the questions it is meant to answer, and explicitly defining:

Supported questions (high confidence)
Unsupported questions (out of scope)
Risky questions (answerable, but with caveats or low confidence)

This shifts semantic views from “a model of data” to a contract for reasoning. Instead of only defining tables, joins, and metrics, you define what the AI analyst can reliably do within this context boundary.

Let’s take an example semantic view designed for “Sales Performance”:

Supported:

“Revenue by segment last quarter”
“Top customers by expansion ARR”
“Conversion rate by region”

Unsupported (out of scope):

“What caused churn last month?” (requires product or support signals)
“Which marketing campaign drove the most signups?” (requires marketing attribution model)

Risky (needs caveats):

“Predict next quarter revenue” (requires forecasting assumptions)
“Which reps’ performance is improving?” (requires handling tenure and territory changes)

In the semantic view, you encode these boundaries so the AI analyst can:

Confidently answer supported questions
Refuse unsupported ones
Answer risky questions with disclaimers (“here’s what I can say with the available context”)

This helps avoid the “confident but wrong” trap, giving users transparency that improves context and accuracy.

Evolution through feedback

Semantic views can’t be “set and forget.” AI interactions will surface the gaps faster than dashboards ever did.

Every wrong AI answer is a signal that something is unclear or missing:

Missing definition
Unclear grain
Conflicting synonym
Absent boundary
Untracked scope change

Closing these gaps is a must for AI adoption and scalability. This can be done by using real question logs to continuously evolve semantic views.

Let’s say you deploy an AI analyst and users ask: “What is our activation rate?”

The AI analyst answers incorrectly because:

There is no explicit activation metric
Multiple teams define activation differently

As part of the the feedback loop, the owner of the AI analyst / semantic view:

Detects repeated queries for “activation”
Adds a scoped metric:
- activation_rate_product (product definition)
- activation_rate_growth (growth definition)
Adds synonyms: “activated”, “activation %”
Updates documentation

This turns semantic modeling into an iterative product loop instead of a governance backlog.

What this means for data teams

Historically, data teams optimized for correctness and consistency. AI introduces a new requirement: completeness of meaning.

To achieve this, data teams need:

Much closer collaboration with domain experts
Tooling that allows business input
Treating semantics as a product, not merely infrastructure

Modern semantic layers explicitly acknowledge this need for governance, clarity, and cross-team reuse.

Closing thought

BI semantic layers tried to preserve meaning so humans could move faster. AI semantic views must materialize meaning so machines don’t get lost.

AI analysts didn’t create the semantic problem — they simply removed the humans who were silently fixing it. Filling that gap requires semantic views that enable materialized, bounded context, so AI outputs are as accurate as they are trustworthy.

Share this article

Atlan is the next-generation platform for data and AI governance. It is a control plane that stitches together a business's disparate data infrastructure, cataloging and enriching data with business context and security.

Book a Demo Start Tour