A semantic model is a written-down layer of meaning on top of your raw data: it says what “revenue” means, how tables connect, and what each column actually holds. Without it, every team defines the numbers slightly differently and AI answers are a guess. This post explains what a semantic model is, in plain terms, and why business teams need one now.
Ask three people in your company what “active customer” means. You will get three answers.
Finance counts anyone with a paid invoice this quarter. Sales counts anyone with an open opportunity. The product team counts anyone who logged in this month. All three are reasonable. All three are different. And when the board asks “how many active customers do we have,” the number depends on who ran the report.
This has always been a low-grade problem – meetings that start with “wait, which number is this?” But it stayed manageable because a human always sat between the data and the decision, quietly applying the right definition.
AI removed that human. When someone asks an AI agent “how many active customers do we have,” the agent picks a definition on its own – and you have no idea which one. A semantic model is how you take that choice back.
What a semantic model is
A semantic model is a written-down layer of meaning that sits on top of your raw tables. It records three kinds of things:
- Definitions: what “revenue”, “active customer” or “churn” actually means, as a formula on specific columns – not a description in someone’s head.
- Relationships: how tables connect. That the customer ID in your orders table matches the ID in your accounts table, so the two can be joined correctly.
- Descriptions: what each table and column really holds. That “status = 3” means “cancelled”, or that the amount column is in euros, not dollars.
Put simply: your database schema says what data exists. This layer says what it means. Those are different things, and computers only get the first one for free.
Why the raw schema is not enough
A raw database is full of names that made sense only to whoever built it: a table called fct_txn_ln, a column called flag_2, a status field where 1, 2 and 3 mean things nobody ever wrote down.
A human analyst learns this over months, by asking colleagues and making mistakes. That knowledge then lives in their head, which is fine until they are on holiday, or leave, or the question goes to an AI agent that never had those conversations.
The semantic model is that knowledge, written down once so everything and everyone can use it – the analyst, the new hire, the dashboard, and the AI.
Why business teams need one now
Two shifts made this urgent.
The first is self-service. Business users query data directly through dashboards and, increasingly, by asking questions in plain language. Every one of those users hits the same definitions problem the analyst used to absorb quietly. Without a shared model, marketing’s revenue number and finance’s revenue number drift apart, and both are defensible, which is worse than one being wrong.
The second is AI. An AI agent doing text-to-SQL – turning “how much did we sell in Q2?” into a database query – is only as good as the meaning it can see. Give it a raw schema and it guesses which table is sales and which date column to filter. Give it a semantic model and it uses your definition of sales, your fiscal quarter, your rules.
This is the same point as our context layer post, narrowed to the piece business teams own: the definitions.
It is also check 5 in the agent-ready data checklist – governed definitions are what turn a raw schema into something an agent can trust.
What goes in a business semantic model
You do not need to model everything. Start with what people actually ask about.
- Your core metrics, defined once. Revenue, active customer, churn, average order value – each with the exact formula and the source table. This single list resolves most of the “which number is this?” arguments.
- The main entities and how they join. Customer, order, product, invoice – and the columns that connect them, written down so nobody has to rediscover the join. When the same entity has several IDs, that is entity resolution.
- The gotchas. The status codes, the test accounts everyone excludes, the currency column, the date field that means “created” versus the one that means “closed”.
A one-page version in a shared document is already worth more than nothing in a fancy tool. The value is in writing it down and agreeing on it, not in the format.
Who owns it
This is the honest hard part, and it is not technical. Someone has to decide that “active customer” means one specific thing, and get finance, sales and product to accept it.
That decision is a business decision, not a data-team decision. The data team can build the model and enforce it everywhere, but they cannot choose your definition of churn for you – and if they do, you get a technically clean model that the business quietly ignores. Agree on the definitions first, with the people who use them. The tooling comes after.
How this works in Peliqan
Peliqan builds this on top of the data warehouse where your data already lands, using features that stack together.
It automatically detects primary keys in every table, and you can correct them or set relationships between tables by hand – there is even a template app that detects relationships for you. You add descriptions to tables and columns to record what they mean, and you shape raw data into business-ready tables by writing SQL views. If you already keep definitions in YAML files, those can be imported so the descriptions carry over.
All of that metadata can then be published to AI agents that need to do text-to-SQL, through a template that generates and exposes your data model with its meaning attached.
So the same definitions serve your dashboards and your MCP agents from one place, across data landed by the platform’s connectors.
This works across data from 300+ connectors, all landing in one place. What Peliqan cannot do is decide what your metrics mean. That stays a conversation among the people who use them – the platform gives those decisions a home and makes sure everything reads from it.
Start with one definition
You do not need a modeling project to begin. Take the metric your teams argue about most – usually revenue or active customers – and get the relevant people to agree on one written definition, with the formula and the source.
Write it down where your tools and your AI can read it. That one definition, shared, is a working semantic model in miniature – and it will settle more meetings than you expect.
If you want to see your definitions drive both dashboards and AI answers from one place, book a demo: bring the metric your teams disagree on, and we will model it once and ask an agent to calculate it.
