The semantic model: one definition the whole company can use

A semantic model is the place where "active customer" and "monthly revenue" are defined once, in a form the reporting tools read directly. It exists so the definition lives in one place instead of being re-implemented in every report that needs it.

Below: what it is in practical terms, what problem it removes, what it costs to keep, when it is premature, and how to build one without a two-year project.

Every organisation past a certain size has the same argument on a recurring basis: two reports show different numbers for the same thing, and resolving it means someone opening both to see how each was calculated.

The semantic model is the structural answer to that, and it is worth understanding what it does and does not solve before adopting one.

What it is, in practical terms

A layer between the stored data and the tools that read it, holding three kinds of thing: the entities the business talks about, the measures computed over them, and the rules that connect the two.

Concretely, it is where the statement "revenue excludes intercompany transactions and is recognised on delivery" stops being a paragraph in a document and becomes the definition every dashboard actually uses.

The tools then ask for "revenue by region last quarter" rather than assembling it from tables. Two people asking that question get the same number, not because they coordinated but because there is only one implementation.

The problem it removes

Not data quality — the semantic model assumes the underlying data is correct and does nothing about it if it is not. What it removes is definitional divergence: the same concept implemented differently in eleven places.

That divergence is expensive in a specific way. It is not that the figures are wrong; it is that nobody can be sure which is right without an investigation, so every figure carries a discount in the room.

It also removes a maintenance burden that is easy to miss. When the definition of "active" changes, eleven reports have to change, and the ones nobody remembers keep using the old rule indefinitely.

That last case does the real damage, because it is silent. A report still running on a definition retired eighteen months ago produces figures that look plausible, are no longer comparable to anything else, and carry nothing in the output to indicate it.

What it costs to keep

A semantic model is not a project that finishes. It changes whenever the business changes what a term means, whenever a new source is added, and whenever a measure is added — which is continuously.

That implies an owner, and the owner has to sit close enough to the business to know when a definition has shifted. Placed purely in a technical team, the model drifts from the business within a year and people route around it, which returns the organisation to where it started with an additional component to maintain.

The realistic commitment is a part-time role, not a team. But it has to be somebody's named responsibility, because the work is invisible until it has not been done for six months.

When it is premature

With one reporting tool, one team building reports, and a dozen measures, a written definitions document and a shared set of queries achieve most of the benefit at a fraction of the cost.

The threshold is plurality: more than one tool, more than one team producing figures, or a measure whose definition has already changed and caused confusion. Any of those makes the case; none of them present makes it a solution looking for a problem.

Adopting one early has a specific failure mode too. A model built before the business has argued about its definitions encodes one team's assumptions as though they were settled, and the argument then happens later with a technical artefact standing in the way.

How to build one without a two-year project

Start from the figures that reach the executive committee, which is usually between ten and twenty measures rather than hundreds. Define those, implement them, and point the existing reports at them.

Resist the instinct to model the whole business first. A complete conceptual model is a satisfying artefact and it delays the first useful result by a year, during which the argument it was meant to end continues.

The order that works is measure-first and demand-driven: something gets added to the model when a real report needs it, not because it appeared in a modelling workshop.

A useful stopping rule for the first release: when every figure on the committee pack comes from the model and no report bypasses it for those measures. That is a checkable condition, unlike "the model is complete", which never becomes true.

What it changes for the people using the data

The visible change is that a question can be asked without knowing where the data lives. Someone in finance asks for margin by product line without needing to know which tables that touches or which joins are correct, and gets an answer that matches what the operations team would get.

The less visible change is more valuable: analysts stop spending most of their time assembling figures and start spending it on what the figures mean. In most organisations that ratio is the single biggest source of unused analytical capacity, and it is rarely framed as a tooling problem because the analysts do not complain about it.

There is also a governance benefit that arrives without being asked for. When every report reads from one definition, access control and sensitive-field handling can be applied in one place — which matters where personal data is involved, since Habeas Data in Colombia and the federal data protection law in Mexico both apply to derived reporting, not only to the source system.

Where the definitions actually come from

This is the part that is not technical and takes the most calendar time. A definition has to be agreed by the people who use the figure, and they frequently disagree — not about the data, but about what the business means.

Whether a customer who bought once two years ago is active is not a data question. Somebody with authority has to decide, and the value of the semantic model is partly that it forces that decision to happen instead of being deferred indefinitely into eleven separate implementations.

Recording the date each definition took effect matters as much as the definition. Without it, a report produced last year and one produced today disagree, and nobody can reconstruct which rule each was using.

Where to start

With the list of measures that reach the committee and an honest count of how many of them are currently implemented in more than one place. That count, on its own, usually settles whether the model is worth building this year or next.

A data and analytics maturity assessment scores source, quality, governance, model and consumption separately, which is what shows whether a semantic layer is the binding constraint or whether the analytics problem is somewhere further upstream.

Frequently asked questions

What is a semantic model?

A layer between stored data and reporting tools that holds the business entities, the measures computed over them, and the rules connecting the two — so a metric is defined once rather than in every report.

Does it fix data quality?

No. It assumes the underlying data is correct. What it removes is definitional divergence — the same concept implemented differently in many places.

What does it cost to maintain?

A named part-time owner, sitting close enough to the business to know when a definition has shifted. Placed purely in a technical team it drifts within a year and people route around it.

When is a semantic model premature?

With one tool, one team producing figures and a dozen measures, a written definitions document and shared queries achieve most of the benefit far more cheaply.

How should the first version be scoped?

The ten to twenty measures that reach the executive committee, implemented and wired into the existing reports. Modelling the whole business first delays the first useful result by a year.

Who decides the definitions?

The people who use the figure, with someone empowered to settle disagreements. Whether a customer who bought once two years ago is active is a business decision, not a data question.