Semantic Layer for AI: Why Your AI Needs Business Definitions, Not Just Database Tables

A semantic layer is a governed translation layer between business language and physical data. It defines metrics (what is measured, such as net revenue), dimensions (how results can be sliced, such as region or product line), the joins and filters behind them, and who may see them. Applications ask for a metric by name; the layer generates the query.

For AI, the semantic layer replaces guesswork. Instead of asking a model to write SQL against hundreds of tables and hope it applies your exclusions correctly, the model selects from a short list of approved metrics and dimensions, and the layer computes the number the same way finance does.

Databases store facts in a shape that suits the applications that write them. Answering a business question usually requires knowledge that is not in the schema: which status codes count as a completed order, which table holds the reporting currency, whether refunds reduce revenue in the month of sale or the month of refund, and which of three customer tables is authoritative.

A language model given the schema will produce plausible SQL. Plausible is the problem: a query can run, return a number and still use the wrong definition. Benchmarks such as BIRD were designed around this gap between understanding a question and querying a real, messy database; on that benchmark, human experts still score clearly higher than the best automated systems (BIRD benchmark). The fix is not only a better model; it is giving the model better-defined things to ask for. See text-to-SQL for business data for the query side.

Most semantic layers share the same building blocks, even if each product names them differently.

The value of a semantic layer is not the YAML. It is that a definition is agreed once, owned by someone and reused everywhere. Write a plain-language description for every metric and dimension, list synonyms people actually use, and document exclusions. Those descriptions are exactly what an AI model reads to choose the right metric, so they double as AI instructions.

This is one part of a wider business context layer, which also holds rules, entities, organizational structure, time and permissions that are not metrics.

A typical flow: the user asks a question; the assistant identifies candidate metrics and dimensions from their names, descriptions and synonyms; it fills a structured request (metric, dimensions, filters, time range); the semantic layer validates it, applies the user's access policy and generates SQL; the warehouse returns results; the assistant explains them and states which definitions it used. The model never writes free-form SQL against raw tables, which removes a whole class of errors and makes answers auditable.

The database stores and computes; the semantic layer decides what should be computed and how. You still need a well-modelled warehouse. The semantic layer sits on top and turns that model into business vocabulary.

These three are often confused because all of them 'give AI context'. They work at different layers and answer different kinds of questions. A semantic layer works at the metrics layer over structured data. RAG works at the document layer, retrieving text passages. A knowledge graph works at the relationship layer, storing entities and the links between them (see knowledge graph vs vector database).

Semantic layers come in three broad forms. Standalone or transformation-linked layers such as the dbt Semantic Layer (built on MetricFlow) and Cube define metrics once and serve many tools. Warehouse-native semantics such as Snowflake semantic views and Databricks Unity Catalog metric views store definitions as governed objects inside the platform, and both vendors position them as the basis for their natural-language analytics features. BI-native models such as LookML and Power BI semantic models live inside a BI tool.

Portability is improving. The Open Semantic Interchange (OSI) initiative, announced by Snowflake with Salesforce, dbt Labs, BlackRock, RelationalAI and others, is working on a vendor-neutral specification so semantic definitions can move between tools (dbt Labs on the OSI specification). It is young; check current tool support before depending on it.

Semantic layers are not only for chat-with-your-data. Agents use them as a safe, read-only analytics tool. Examples: a finance agent preparing a monthly variance commentary queries governed metrics and explains movements; a sales agent checks an account's revenue trend before drafting a renewal note; an operations agent monitors a fulfilment-rate metric and opens a ticket when it drops below threshold; an ecommerce merchandising assistant compares category margin across channels. In each case the agent calls a tool such as query_metric(metric, dimensions, filters, time_range), which is far easier to secure and evaluate than free-form SQL. See AI agent tool design.

Teams often expose every column as a dimension, which recreates the raw-schema problem with nicer names. Keep the vocabulary small and curated. Another mistake is skipping descriptions; for AI, the description is the interface. Some teams build a semantic layer for dashboards but let the AI assistant query raw tables anyway, which guarantees two sets of numbers. Finally, a semantic layer cannot answer questions it has no metric for; the assistant should say so rather than improvise a query.

A semantic layer gives AI the one thing a schema cannot: agreed business meaning. It turns 'write some SQL' into 'choose from these governed metrics', which makes answers consistent with the rest of the business and easy to check. Use it for numeric questions, pair it with retrieval for documents and a graph for relationships, and treat its definitions as the shared language between people, BI tools and AI.