A semantic layer’s potential is in the people who use it, and in how much they use it. If it can absorb their knowledge directly and safely, then context compounds, and everyone benefits.
Now that every tool is adding features to capture metrics, semantics, and context, it’s time to consider: what makes a semantic layer actually good?
To think about this, let’s look at a simple example:
A warehouse has a table with a column called amount. That’s not revenue.
Revenue is amount where the order completed, minus refunds, excluding internal test accounts, converted to USD at the booking-date rate.
Defining it also means someone had to decide which date matters and whether “revenue” means booked revenue or GAAP revenue in this context.
This gap between raw data and business meaning still has to be closed by someone, somewhere, every time anyone asks a question. This is where the semantic layer comes in. And at a minimum, it must produce correct answers. Which begs the question:
Where should the translation from data to meaning happen? And who should do it?
To answer this, you first need to remember that a semantic layer can only deliver on its promise if it’s used. If it doesn’t get used, it doesn’t matter. And for it to get used, it has to be the easiest path to analysis, because when using the layer creates friction, the exports begin… and so does the chaos.
I've spent years using and building data tools. The hardest problems aren't about features; they're about people and how they want to work. A semantic layer can be correct and still fail the people using it.
Once you account for the people and agents in the workflow, the evaluation needs to change.
Can the semantic layer learn from how they use it?
A good semantic layer should function as an engine that improves through use. When analysis exposes a gap, the person with the context should be able to easily capture the fix, and promote it to the shared model through a branch and git-based review process that still runs through the data team. New logic needs to be vetted, governed, and shared with every human and AI consumer without a weeks-long review process.
This is how you build context that compounds.
Change is inevitable, so you need to plan for it.
New edge cases and policy changes will continue testing definitions long after they’re written. Without a loop for capturing those changes, the model will fall behind. When that happens, you can’t expect people to file a ticket and wait for another team to update the shared definition every time. Instead, many will write SQL or pull the data into a spreadsheet, and maybe their question will be answered correctly. Those workarounds might solve the immediate problem, but any new knowledge stays in that analysis, leaving the shared system unchanged.
AI makes this worse. A specialist seeing a metric that looks off might pause and ask for clarification, or make a deliberate judgment call. But an agent won’t hesitate. It will assume something, then serve that assumption up to anyone who asks. What was once a local judgment call becomes an automated answer at scale. This makes AI a direct stress test of the semantic layer underneath.
So for AI analytics to be reliable, it requires a semantic model that can absorb new context, govern each change, and share approved logic with every consumer. It’s that workflow that makes a semantic layer good.
A good semantic layer improves through use #
The feedback loop has to be shorter than the workaround. People need to feel confident to explore, validate, and promote useful logic without changing everyone’s truth too soon.
And it's not just humans using or building anymore that needs to be considered. AI agents, increasingly the primary mode of self-serve analytics, need to be able to contribute by learning from usage and suggesting model improvements. For that to work, data teams need tools that keep them in command of the loop (otherwise garbage in = garbage out).
The ideal loop looks like this:
Usage exposes a gap.
The person or agent with the context captures the improvement where the work is happening.
The change is tested, reviewed, and promoted.
Approved logic becomes available to every human and agent.
The semantic layer improves, making it easier for everyone to use.
Analysis shouldn't merely consume the semantic layer. It should improve it. That's how knowledge compounds instead of splitting off into local artifacts. That’s the context engine.
So the question becomes: What keeps people using the semantic layer instead of routing around it?
The architecture has to support distribution and learning #
For people to use a semantic layer, it should accomplish two distinct jobs.
Headless distribution: Make governed definitions accessible to every legitimate consumer in the interface they’re most comfortable with.
In-flow authoring: Let the work of analysis expose and safely improve those definitions.
Headless distribution and in-flow authoring solve different problems, but a good semantic layer does both. Distribution without authorship produces a consistent but increasingly stale system. The architecture has to send shared definitions to every consumer and carry analysts' fixes back through review.
So how do you evaluate for a good semantic layer that accomplishes both jobs?
Five qualities of a good semantic layer #
You need to consider why people and agents work around the semantic layer, and proactively address each possible exit point.
People route around a semantic layer when it’s too rigid and slow to change (flexible), when it doesn’t integrate with their other tools (interoperable), when adapting it means multiple copies (extensible), when it can’t answer their question (comprehensive), or when they don’t trust it (governable).
What this looks like in Omni #
Omni closes the loop between analysis and the shared data model. We built our semantic layer with humans and agents in mind to ensure it’s flexible, interoperable, extensible, comprehensive, and governable, and to keep users on the shared path. While we think our semantic layer is good, we think the thing that matters is the workflow it enables.
Flexible #
An analyst can create a calculation in a workbook using Excel-style functions and table calculations, by defining SQL, or by simply asking Omni’s AI. They can test it against live warehouse data in a sandbox environment, and iterate on it further without filing a ticket.
If the calculation proves useful, they can promote it to the shared model safely using software development lifecycle best practices. The logic becomes a shared and governed definition without requiring a new warehouse pipeline. And the context people discover during analysis has a path back into the system rather than being stranded in a local artifact. That's how the semantic layer’s context compounds.
AI needs that same balance of control and flexibility, because if you lock agents to a strict whitelist, they’ll hit a wall, and if you let them write SQL directly, governance disappears. The only durable workflow grounds every query in the semantic layer while still letting it build new fields and joins on top.
Interoperable #
Definitions remain portable and version-controlled. The same governed model can serve BI, agents, embedded products, and data platforms. Omni brings your existing stack's context into a single place. dbt syncs both ways. Omni inherits Snowflake Semantic Views and Databricks Metric Views, and pushes definitions back using open-source agent skills.
This is why open-source initiatives like Apache Ossie (formerly OSI) matter, and why we helped launch it. Standardizing semantic definitions across vendors helps make long-term portability real.
Extensible #
The semantic model can handle the disparate needs of departments, regions, or embedded customers without duplicating logic or creating drift. Extends let teams inherit and reuse definitions from the shared model, including colors, default filters, and formatting; so a team or tenant can carry its own version without having to maintain a second model.
Git followers sync the model across deployments. You designate one Omni model as a leader and another as a follower, so that all development happens in the leader against its own git base branch, promotion happens only via a pull request, and Omni auto-applies changes to the follower.
Comprehensive #
The semantic model captures the structure of complex queries and the business context needed to interpret them. Teams can add model rules, domain-level guidance, and field details, and Omni includes AI context parameters that teach AI agents your institutional knowledge and the language of the business.
An analyst can build a calculation that combines measures from different views, and specify the grain and valid aggregations; and they can define a sample query so AI agents have a specific example to refer to the next time someone asks a similar question.
Governable #
Permissions and definitions are enforced by the model and AI harness, meaning they can’t be bypassed. We use curated datasets called Topics to tell the agents which tables to join and what questions can be answered by a dataset. So when Sales and Finance have different ways of defining revenue, the Topic decides which definition applies.
We saw the effect on our own internal AI.
On 100 real analytics questions from our production instance, accuracy increased from 75% to 95% after the team added missing metric definitions, business context, fiscal-calendar fixes, and examples of valid queries. Each failed question exposed a gap that could be fixed with the same tools and best practices available to our customers. A leading coding agent’s accuracy rose 7 percentage points on the same questions after reading the tuned semantic model. This shows it’s not enough to have the right definitions, what matters is that they're enforced.
The coding agent said, 'I have all the definitions I need,' after reading the model's warning about the exact query it was running. Then it hand-wrote its own join, caused a fan-out, and put the top campaign at $55.5 billion in pipeline.
Omni’s accuracy rose 20 percentage points because its AI harness routed each question, scoped the fields and filters, compiled the SQL, and validated the result.
The practical test #
…is what happens when the business changes.
When an analyst discovers missing context, or an agent exposes a gap in a definition everyone assumed was settled, or a policy changes the meaning of a metric, the fix needs to land in the semantic layer before the next query.
At each point, ask:
Is the answer correct?
Who can change the definition?
How long do they wait?
How is the change tested and governed?
What breaks afterward?
Does the improvement reach every consumer, human and AI?
Those answers reveal whether the semantic layer can absorb change. If not, it’s just a static catalog.
A good semantic layer proves itself under stress. Definitions, sources, and the org chart will all change. Either the layer changes with them, or people will work around it.
