Semantic Models Don’t Bring Meaning. People Do.

The word “semantic” is doing too much work, and it hides where the real work lives.

If you have ever gone looking for a clear explanation of how a semantic model brings semantics to your data, you have probably noticed the documentation is thin. There is a reason for that. “Semantic model” does two or three different jobs under one word, and most of the writing about it never says which one it means.

What a semantic model actually adds

Look at what a Power BI / Fabric semantic model puts on top of raw tables. It maps a vocabulary, so FCT_SLS.AMT_NET becomes Net Sales. It encodes relationships, so the engine knows an order belongs to a customer and can traverse that without you writing the join. It encodes hierarchies, so Date to Year to Quarter to Month carries roll-up meaning. And it defines measures.

The measures are where the value sits. Revenue gets defined once, in DAX, with its inclusions and exclusions pinned down, so everyone who asks for revenue gets the same number. That is the real job: fix the meaning of a metric so it is not re-derived inconsistently across fifty reports. A single source of truth for definitions is worth a lot.

But it is a thin kind of meaning

Notice what kind of meaning that is. It is business meaning for consumption and aggregation. It is not formal semantics in the knowledge-representation sense. The model has no inference, no reasoning, no portable definition of what a customer actually is. It is a dimensional model wearing business clothing.

The word itself is inherited. It goes back to the Business Objects universe in the nineties and the old SQL Server BI Semantic Model, where “semantic” meant business-friendly abstraction over a physical schema. It never meant logically specified.

In practice three different things wear the badge:

• The metrics layer (Power BI semantic model, dbt, Cube): meaning as consistent calculations and relationships for querying.
• The catalog layer (Microsoft Purview Unified Catalog, and its peers): meaning as defined terms, classifications, lineage, and stewardship. It describes and classifies. It does not compute.
• The ontology and knowledge-graph layer: meaning as formal concept definitions a machine can reason over.

The documentation is vague partly because vendors conflate these. You open a page about semantics and cannot tell which of the three it is claiming.

All of this is technical. Meaning is not.

Every artifact above is built by data people in a modeling tool. But the meaning does not live in the data or the tool. It lives with the business. Active customer means something because people agreed it does. The model only encodes the agreement.

So the moment you want business users involved, the instinct is to hand them the artifact. Sit them in front of the glossary, teach them a simplified modeling tool, run a workshop, define four hundred terms. That produces the glossary graveyard. Definitions nobody bound to data, nobody maintains, nobody queries. Meaning that is not connected to something and not consumed decays within a quarter.

The reframe that works is to split the two things the word was hiding. Meaning is business-owned. Encoding is technical. Business users do not write the DAX or the mappings. They own the definition and they validate the encoding. The artifact’s only job is to stay traceable back to a definition a named human agreed to.

What that looks like in practice

Start from the numbers people argue about, not from the data model. Do not ask what customer means in the abstract. Ask which reported figures two departments compute differently. Revenue, active customer, churn, qualified lead. Wherever the numbers disagree, there is an undefined term, and that is exactly where business semantics earns its keep. It also gives you a business reason to do the work, which you need to get anyone’s time.

Capture each term in business language first. Definition, owner, synonyms, and the edge cases that are the whole point. Does a trial count as a customer. Does a refunded order count as revenue. In a Purview governance domain that is a glossary term with a named steward, and the steward being a real person with a real job matters more than the tool.

Then bind the term to the physical assets and to the measure that implements it. Then round-trip it. Show the owner what their term currently computes, in their language, and ask if the number matches what they meant. That last step is the one everyone skips, and it is where you catch the drift between intent and encoding.

Federate the whole thing by domain instead of centralizing meaning in one modeling team. That maps cleanly onto governance domains and data products, and it is the only version that scales past a handful of metrics.

The AI shift cuts both ways

There is a new reason to care. When a business user asks an agent how many active customers there were in the Nordics last quarter, the agent has to resolve active customer to the right encoding or it returns confident garbage. The thin semantics that was fine for a human analyst is not fine for a model.

The same models also collapse the old translation gap. A business user describes a definition in plain language. The model drafts the measure or the term-to-asset mapping. The human confirms. Natural language is becoming a real authoring surface for semantics, which is the first thing that has ever lowered the barrier for business users instead of just renaming the tool.

One caution

Resist over-formalizing. Most business semantics needs three things: agreed definitions, clear ownership, and binding to data. Reserve the heavier formal modeling for the few places where concepts genuinely have to be reasoned over, not for the eighty percent that just needs one measure everyone trusts.

The model gives you structure. Meaning is a human agreement. Treat it as one, and the rest of the stack has something solid to point at.