A semantic layer is the shared definition of what your data means. It names the business concepts (Customer, Order, Subscription), says how they relate, defines how each metric is calculated, and binds all of that to the physical tables and columns that store it. When a person, a dashboard or an AI agent asks a question in business terms, the semantic layer turns it into correct SQL, so everyone gets the same answer.

That last part is the whole point. Without a semantic layer, every consumer of the warehouse re-derives the meaning of the data on its own, and they rarely agree.

The problem a semantic layer solves

Ask three analysts for last quarter's revenue and you can easily get three numbers:

One joined fct_order_line to fct_order and then to fct_payment, double-counting orders with split payments.
One used gross amount and forgot refunds.
One filtered on created_at instead of order_date.

None of them made a typo. Each made a reasonable choice that nobody had written down. A semantic layer writes it down once:

Net revenue = sum of amount - discount at order-line grain, excluding refunded lines.
An Order is placed by exactly one Customer.
The order month dimension comes from order_date.

From then on, a question about net revenue by customer segment compiles to the same SQL every time.

The parts of a semantic layer

Most semantic layers, whatever the product, have the same building blocks.

Concepts (entities)

The business things your data describes: Customer, Product, Order, Account. A concept is not a table. One concept can be stored across several tables, or in two different systems, and one table can hold parts of several concepts.

Relations

How concepts connect: an Order is placed by a Customer; an Order contains Products. Relations carry cardinality, and they define the valid join paths. A good semantic layer folds bridge tables into many-to-many relations instead of exposing them as fake concepts.

Metrics

Calculations with a formula, a grain and the dimensions they can be sliced by. Metrics are where most disagreements live, so defining them once is where most of the value comes from. A tool that only does this part is often called a metrics layer.

Bindings

The mapping from each concept, property and metric to real tables and columns. Bindings are what let the semantic layer generate SQL rather than just document meaning.

Access rules

Who may see what: row filters, column masking for personal data, and scopes for API keys. Once agents query the warehouse, this becomes part of the semantic layer rather than something bolted on later.

Semantic modeling: where the definitions come from

Semantic modeling (or semantic modelling in UK spelling) is the work of creating those definitions. Traditionally it means someone typing concepts and metrics into YAML or a BI tool from memory, which is slow and drifts away from the warehouse as tables change.

A better starting point is the data model you already have. If the warehouse was designed as a Kimball star schema, the facts and dimensions already encode most of the concepts and relations. In offdataai, a deterministic pass derives concepts, relations and metrics from the model's structure, strips prefixes like dim_ and fct_, and turns bridge tables into many-to-many relations, with no AI involved. An optional AI pass then proposes clearer names and business definitions, and every suggestion waits in a review queue. Semantic modelling becomes a review task instead of a blank page.

Why AI agents need a semantic layer

Large language models are good at writing SQL that looks right. Given a schema, an agent will happily produce a query that joins the wrong tables, picks the wrong date column, or sums a semi-additive balance across days. It will also present the result with total confidence.

There are three ways to make agents reliable on data questions:

Give them the whole schema and hope. This fails as soon as the warehouse has more than a handful of tables or any ambiguous names.
Give them the schema plus documentation. Better, but the model still writes freehand SQL, and nothing guarantees it follows the documentation.
Give them a semantic layer. The agent chooses metrics, dimensions and filters by name, and a compiler writes the SQL from approved definitions.

The third option changes what the model is responsible for. Choosing "net revenue by customer segment for 2026" from a list of known metrics is something language models do very reliably. Working out the join path through six tables is not.

In offdataai, that is exactly the split. A plain-English question becomes a structured query of metrics, dimensions and filters named by concept. The compiler walks the ontology's relations and bindings to write dialect-correct SQL for each source system. If the question spans two systems, it pushes down what each can run and joins the partial results in memory. The answer comes back as a sentence, the rows and the SQL that ran, so it can be checked.

Semantic layer vs data catalog vs ontology

These terms overlap, so it helps to separate them:

A data catalog says what data exists and where: systems, tables, columns, owners, sensitivity.
An ontology says what the data means: concepts, relations and metrics, in a standard form such as OWL.
A semantic layer uses those definitions to answer questions, compiling them into SQL with access rules applied.
A context layer delivers all of the above to AI agents at the moment they need it, usually over an API or MCP.

We cover the differences in more depth in Data Catalog vs Semantic Layer vs Ontology.

What to look for in a semantic layer

If you are evaluating options, these questions separate a definition store from something agents can rely on:

Does the model write the SQL, or does a compiler? If an LLM writes freehand SQL, the semantic layer is documentation, not a guarantee.
Can one question span multiple systems? Real organizations keep orders in one place and accounts in another.
Are definitions bound to tables, and kept in sync when the model changes? Definitions that drift from the warehouse are worse than none.
Is there human review for AI-suggested definitions? Otherwise the semantic layer is only as good as the last prompt.
Are access rules enforced for agents? Row filters and PII masking need to apply to API and MCP calls, not just dashboards.
Can you see what ran? Every answer should come with its SQL, and every agent request should be logged.
Does it fit your platform? For example, on Databricks you may want definitions published as Unity Catalog metric views so Genie uses them too.

Getting started

You do not need to stop and write a semantic layer by hand. If you already have a data model, whether it is a dbt project, a live warehouse or a design on a whiteboard, offdataai can derive a first version from it:

Build or import the model: through the AI data modeling tool, a template, the Model Builder or the Database Modeler.
Create an ontology from it and review the derived concepts, relations and metrics.
Publish it, ask questions in plain English, and connect agents through the context layer.

The result is one set of definitions that your analysts, your dashboards and your AI agents all share.

What Is a Semantic Layer? (And Why AI Agents Need One)