Skip to content

Semantic layer

The tempting fix

KPI definitions live in the formulas of individual reports. Different reports disagree. A semantic-layer product promises one place for business definitions that every tool can use, so the obvious move is to buy one and put it in the middle.

N definitions become N + 1

Put in before anyone has settled who decides what a metric means, the layer becomes one more independently managed representation of meaning.

  • The reports keep their own logic, because nothing forces them to converge.
  • The underlying modelling problems (grain, process facts, ownership) are untouched.
  • The layer cannot reconstruct meaning that was never captured where the data was created.

A mechanism, not an authority

A semantic layer exposes governed concepts, measures, dimensions and relationships to several consumption tools. It is a mechanism for projecting meaning, not a source of semantic authority. Settle the authority first; the layer then has something to project.

The picture

A semantic layer before and after semantic authority Left: three reports each hold their own definition of revenue; adding a semantic layer with its own definition makes four definitions, N plus one, with nothing forcing them to converge. Right: a governed semantic authority holds one definition; the semantic layer projects it to a BI tool, an API and an AI assistant: one definition, many projections. Layer first · N + 1 definitions Report Arevenue₁ Report Brevenue₂ Report Crevenue₃ New semantic layer revenue₄ Nothing forces the reports to converge. The authority problem is still unsolved. Authority first · one definition Semantic authority revenue · governed, versioned, owned Semantic layer projects, caches, serves BI tool API Assistant The layer has something authoritative to project.
The same product, introduced before and after semantic authority.

Pausing an evaluation

Illustrative example

An organisation whose KPIs live mostly in BI-tool formulas is evaluating a semantic-layer product. The argument here is to pause, not to reject it. First strengthen the source-aligned data products, and govern the important metrics outside individual reports. Then decide where a semantic consumption layer fits.

That is a judgement about fit and sequence in one context, not a verdict on the product category.

In detail

What a good semantic layer does

It makes a metric's grain, filters, time rules, valid dimensions and lineage inspectable, and serves the same definitions to reports, APIs and AI assistants. Reporting tools can then concentrate on display and local exploration.

What it depends on

A semantic layer at the end of the pipeline can improve consumption. It cannot recover knowledge lost upstream. It depends on product contracts, accountable definition owners and meaning captured at the source, which is where the next chapter begins.

Not this

  • Not an argument against semantic layers.
  • Not a claim that the layer must hold the authoritative definitions; it may project them from elsewhere.

Unresolved

  • Where do authoritative metric definitions live, and how does a semantic layer receive them?
  • How should work divide between the semantic layer and the governed query layer beneath it?

Join the argument

Agree, challenge or add evidence

Architecture improves when its assumptions are challenged. Say which kind of contribution you're making:

  • Challenge I disagree because…
  • Evidence We've seen this too…
  • Question How would this work when…?
  • Alternative Another way to approach this…
  • Extension This also implies…

Please keep clients, employers and colleagues unidentifiable. Strong contributions may be quoted and credited on this site. Read the contribution guidelines and the privacy notice.

Comments are provided by giscus and stored on GitHub. Posting requires a GitHub account.

Chapter 2 begins · Meaning starts at the source Meaning and accountability belong at the source Two fields share a name, so everyone assumes they mean the same thing, and nobody is accountable when they don't. Process ledger fact