Two teams can read the same database and produce different definitions of “active customer,” “revenue” or “conversion.” Neither query must be technically wrong. The failure is organizational: important business concepts live in SQL fragments, slide decks and human memory rather than in a governed place that both people and machines can understand.
A semantic layer is not merely a friendly label for a table. At its best, it records the meaning of entities and metrics, their allowed relationships, calculation rules, time boundaries, security conditions and changes over time. That turns a collection of data sources into a shared business vocabulary. Its most valuable output may be fewer arguments, not faster queries.
AI makes this foundational. A language model can construct syntactically impressive SQL over a schema it misunderstands. If “net revenue” means something different across products, the fluency of the response makes the mistake more dangerous. A useful analyst agent needs approved meanings, evidence, permission boundaries and a way to explain how the result was constructed.
Governance should not become a bottleneck that prevents learning. Start with a handful of high-stakes metrics and make their owners explicit. Version definitions. Preserve disagreements as decisions to resolve, not embarrassing exceptions to hide. When a term changes, explain which reports and automated actions depend on it. Good semantics turn institutional knowledge into infrastructure.
Metric definitions are product interfaces
Consider a measure called active customer. Does a user who opens an app but purchases nothing count? What about a business customer with several accounts, a refunded purchase, or a trial subscription? Without a written definition, a chart can be precise and wrong for the decision at hand. Treat definitions as APIs with owners, test cases, versioning and backwards compatibility.
The bridge between SQL and natural language
A semantic engine should expose dimensions, measures, relationships, permission scopes and provenance. When an analyst asks why revenue fell, the model should know what revenue means in that business and which period and exclusions apply. It should also show the transformations and sources behind its explanation. Generating SQL is only part of the answer.
A real trade-off
Central definitions can become bureaucratic if one team must approve every local experiment. A useful architecture keeps certified metrics and exploratory metrics distinct. Product teams can propose new meanings while critical financial metrics retain review, lineage and explicit release processes.
How to start without a platform programme
Select five high-consequence terms: customer, order, refund, net revenue and active usage. Ask every product team to describe each one. Identify disagreements, choose owners and tests, then introduce the semantic layer as a place to resolve and preserve those decisions. Software follows agreement; it cannot manufacture agreement alone.