Your Semantic Layer Is Not Your Business Context
Metrics and relationships give AI governed definitions. A real context layer also carries examples, priorities, permissions, operating history, downstream use, and accountable ownership.
Semantic layers are amazing. They give AI a governed way to understand Metrics, Dimensions, and relationships instead of rediscovering the business through raw tables every time.
But a semantic layer is not the complete business context. It tells the AI how a number is defined and calculated. It usually does not tell the AI what the business is trying to do right now, which exceptions matter, who is allowed to act, what changed last week, where the number is used, or who is accountable when the definition becomes ambiguous.
That distinction matters because an agent is not only retrieving a definition. It is answering a person, investigating a problem, changing work, and affecting other systems. For those jobs, the semantic layer belongs inside the context layer. It cannot be the whole thing.
Snowflake is right about the foundation
Snowflake recently described how its teams built an internal context layer for AI agents around semantic views. Those views map business language to physical schemas through facts, Dimensions, Metrics, and relationships. Snowflake also makes an important operational point: the layer should be treated like production software, with version control, peer review, testing, evaluations, monitoring, and relentless curation.
This is real progress. A maintained semantic layer is much better than letting an agent search across contradictory tables, stale dashboard calculations, and undocumented SQL. It gives the model a smaller, governed surface and gives the company a place to resolve definition conflicts.
My disagreement is narrower. Snowflake calls this curated semantic layer a context layer. I think it is the foundation of one, not the complete boundary. The difference appears as soon as a user asks what a Metric truly means—or asks the AI to do something because that Metric changed.
First, the Metric has to be explainable
Consider a simple question: What were total sales this month?
A semantic layer might provide a description, an aggregation, a time Dimension, and the SQL used to calculate the result. But “total sales” is still unresolved until a person can answer the business event underneath it.
A definition entry
Total sales is the sum of booked revenue in the selected period.
The sentence sounds clear. The SQL can compile. Neither tells a business user which real-world moment made the sale count.
An explainable definition
- Does the sale happen when the contract is signed?
- When the subscription starts?
- When the first payment succeeds?
- How are renewals, refunds, trials, and backdated changes handled?
Those are not implementation details. They are the definition. Each choice creates a different population, date, and number. The right answer depends on why the company uses the Metric.
A one-line description can summarize the decision after it has been made. SQL can implement it precisely. Neither is a reliable interface for teaching the decision to most people. The context layer needs a human-readable path from the Metric to the population, the qualifying behavior, the boundary rules, and finally the implementation.
I wrote about that explanation hierarchy in Anthropic's 95% Analytics Accuracy Is Not the Finish Line: Metric → Dataset → Activities → SQL. SQL remains essential. It just should not be the first place a person has to go to understand the business.
Second, the definition has to be decomposable
Even a careful paragraph can hide ambiguity. The fastest way to understand a definition is often to inspect people and events on both sides of its boundary.
If total sales counts the first successful payment, the AI should be able to show a customer who signed a contract but has not paid, a customer whose first payment succeeded in the period, and a customer whose payment was later refunded. It should explain why each person did or did not contribute to the number.
The commercial agreement exists, but no successful payment has happened yet.
The approved Metric uses first successful payment as the sale event.
The customer's qualifying Activity falls inside the selected month.
The Dataset row exposes the event, timestamp, amount, and reason.
A later Activity changes how finance wants to treat the original sale.
The owner can explain whether the Metric reverses, nets, or retains the sale.
A person can challenge the definition by looking at real journeys, not by trusting that a query looks plausible.
This is what decomposable means: the AI can move from the aggregate to the customers, Activities, relationships, and boundary cases that produced it. It can show both qualifying and non-qualifying examples without inventing a new definition for the question.
The examples also become evaluation cases. When the definition changes, the team can retest the journeys it knows are easy to misclassify. The semantic layer supplies the governed object. The broader context layer supplies the explanation and the cases that keep it honest.
Third, the Metric has to live inside the operating business
Definitions do not sit still. A billing migration changes event timing. A bug duplicates an Activity. Finance adopts a new refund treatment. A leader asks the team to prioritize net revenue over bookings. A dashboard is retired, but an executive email still depends on its old calculation.
An AI that only knows the semantic object may calculate the approved definition perfectly and still give the wrong operational answer. It also needs to know:
- Priorities and decisions: what the company is optimizing now and why a definition was chosen;
- live work: open Tasks, reported bugs, meeting notes, planned migrations, and pending approvals;
- permissions: who can see the underlying records, who can change the definition, and who must approve consequential action;
- operating history: what changed, when it changed, and which past results used an earlier rule;
- downstream use: every Report, dashboard, email, Workflow, and decision that depends on the Metric; and
- accountable ownership: the person who resolves ambiguity instead of letting the model quietly choose.
This is why the useful shape is a connected business-context graph, not a folder full of definitions. A Task can point to the affected Metric. A meeting decision can explain a changed rule. A Workflow can expose the consequence of that change. An owner can approve it. The links are part of the meaning.
“The number in this email is wrong” is a context problem
Imagine an executive forwards a weekly email and says, “The number in this email is wrong.” A semantic-layer lookup can confirm which Metric the email should use. That is valuable, but it does not complete the investigation.
Identify the exact number, recipient, send, and linked Report.
Confirm the approved event, population, date boundary, and refund rule.
Inspect the customers and events that created this period's result.
Check active work, meeting notes, changes, and known exceptions.
Find other Reports, emails, and Workflows that may share the issue.
Correct, rerun, validate, and communicate the affected result.
Finding the formula is one step. Resolving the business problem requires the connected operating record around it.
The agent must trace backward from the email to the Report, Metric, Dataset, Activities, and implementation. Then it must trace sideways into known bugs and decisions, and forward into every other affected output. It has to respect permissions throughout and route the change to the right owner.
Without those links, the AI can explain a formula while missing the incident.
Use a semantic layer. Do not stop there.
I do not believe a semantic layer defined directly over warehouse SQL can, by itself, deliver the consistency an enterprise expects. Not because SQL is bad, and not because governed Metrics are unimportant. SQL describes computation. A semantic layer governs analytical meaning. Business context also includes the changing circumstances in which that meaning is used.
The practical test is simple. Pick one consequential Metric and ask whether the AI can answer all of these questions:
- What real-world event makes this count?
- Which population and time boundary does it use?
- Can you show me customers who qualified and customers who did not?
- What exceptions and recent changes affect it?
- Where is it used downstream?
- Who may inspect, change, and approve it?
- Who owns the final ambiguity?
If the system can answer only the first two, you have a useful semantic layer. If it can answer all seven with inspectable evidence, you are beginning to build a business context layer.
Snowflake is right to make the semantic foundation versioned, tested, evaluated, and continually curated. The next step is to connect that foundation to how the business actually operates. That is the context an AI needs before it can do more than return a consistent number.