The same "revenue" number showing three different values in three different tools isn't usually a data quality problem. It's a definition problem. One tool might count a sale the moment a contract is signed. Another might wait until payment clears. A third might back out expected refunds before the number ever reaches a dashboard. That's the exact thing a semantic layer exists to fix.
What a semantic layer actually is
A semantic layer sits between your raw warehouse tables and everything that reads from them. That includes dashboards, ad hoc queries, exports, scheduled reports, and an AI agent answering a plain-English question. Each of those surfaces could write its own aggregation logic. Instead, they all resolve against the same named metric — the same "active customers," the same "net revenue," computed the same way, everywhere it appears.
"Active customers" might mean "logged in this month" to one team and "paid within the last 30 days" to another. Both are reasonable. A semantic layer doesn't rule either one out — it picks one definition and holds every surface to it, so the disagreement gets settled once instead of every time someone builds a new chart.
The alternative: definitions living in five places
Without one, a metric's definition ends up scattered. Some of it lives in a filter buried in a dashboard. Some lives in a CASE WHEN in an analyst's SQL. Some lives in a calculated field in a spreadsheet. Some lives in a footnote in last quarter's slide deck, explaining why that version excludes refunds. Each copy drifts independently. Nobody decides to make them disagree. They just do, one small edit at a time, until two people in the same meeting are confidently citing different numbers for the same thing.
Neither version is wrong on its own terms. A sales dashboard might count the deal the moment it's signed. A finance report might wait until the invoice clears. Each team is answering a different question with the same word — and nobody ever agreed on which question "revenue" was supposed to answer.
How to tell if a tool has a real one
A useful test: change a metric's definition once. Does it update everywhere that metric is used? Or do you have to go and find every dashboard, report and export that happens to reference it? Look at how a chart's underlying query is built. If it's a bespoke expression written for one chart, rather than a reference to a shared, named metric, the tool doesn't have a semantic layer. It just has a lot of dashboards that happen to look consistent today.
- Does the platform let you name and define a metric once, in one place?
- Do dashboards, exports and an AI assistant's answers all resolve against that same definition?
- If you fix a definition, does every surface that used it update automatically?
- Can two people ask the same question in two different tools and get two different answers?
Where this matters most
It matters everywhere. But it matters most anywhere a number leaves the building — a client-facing report, a board pack, a number an AI agent states with total confidence. You can't ship a metric to a client whose definition might quietly differ from the one an analyst used in a different report last quarter. And you often won't find out until someone asks why the two don't match.
By then, the client has already seen both numbers. Explaining the gap after the fact costs more credibility than getting the definition right the first time would have. A semantic layer doesn't make that conversation more polished — it removes the reason to have it.
How Veritly approaches it
Veritly's agent doesn't answer from memory. Every response is produced by a SQL query against your warehouse, resolved through a governed semantic model. The query is shown next to the answer, so it can be checked before anyone acts on it. A metric defined once in that model stays defined. A dashboard reads it. A scheduled report cites it. The AI agent uses the same definition when it's asked the same question in plain English.
Join the private beta waitlist — early access includes a setup session with the team that built it.
Related reading: what it takes to trust a natural-language answer, and what an integrated analysis environment is.
See also: dbt and the reporting layer.
