Semantic Layer vs. Context Layer

Semantic Layer vs. Context Layer: this distinction decides whether an AI analysis is reliable or only sounds plausible.

Feed AI a company’s data and it will always give you an answer. Whether that answer is correct depends on what the model knows about the data. In our previous article, we showed how Claude runs DAX queries directly against semantic models in Power BI Service via MCP. That setup works technically straight away. But it only becomes reliable through a second knowledge layer: the context layer.

In this article, we draw the line between the two layers, show with concrete examples which mistakes a context layer prevents, and explain how to build one pragmatically.

What the semantic layer delivers

The semantic layer is the agreed, technical description of the data. In Power BI, that is the semantic model: metric definitions as measures, descriptions of tables, columns and dimensions, plus relationships and structure.

[Revenue], for example, is defined once, including discount logic, time intelligence and filter behaviour. Every report and every AI query calculates it identically. This is complemented by descriptions of what a field means, the granularity of a table, and how objects relate to one another, and finally the data model itself with its relationships.

The semantic layer therefore answers two questions: what exists, and how is it calculated? For AI analytics, it is the necessary foundation. Without it, the language model invents its own calculations, and the number in the chat drifts from the one in the dashboard.

Where the semantic layer stops

What the semantic layer does not answer is the third question: why do the numbers look the way they do?

A model does not know that a marketing campaign ran in February. It also does not know that an API token expired, causing five weeks of missing orders from one country. That knowledge exists, but in the heads of analysts, in Slack threads and in meeting notes.

A human analyst brings that knowledge implicitly. A language model does not. And because a language model answers regardless when in doubt, the most dangerous kind of result emerges without that knowledge: a plausible-sounding, neatly formatted, incorrect analysis.

The context layer: business knowledge as an explicit layer

The context layer is the fourth layer of the Hopmann AI Foundation. There, we place it strategically within the interplay of all five layers; in this article, we show how to build it in practice with Power BI and Claude.

The context layer makes exactly this implicit knowledge explicit. In our setup, that is a YAML file per semantic model, which Claude reads before every analysis. Four building blocks have proven particularly valuable.

First, the event timeline: business and technical events that leave a mark on the data.

event_timeline:
  - 2024-10-30: Service token for the Order API in Germany expired,
      re-authentication not until 2024-12-03.
  - February 2025: Revenue spike for Côte de Blaye in Germany
      due to marketing campaign.
  - March 2025: Beverage range largely sold out due to supply chain
      issues, order decline.

Second, verified questions: checked question-query pairs that serve as templates.

suggested_questions:
  - question: "Which products are our top 5 by revenue?"
    dax: |
      EVALUATE
      TOPN(5,
        ADDCOLUMNS(VALUES(dim_products[productName]), "Revenue", [Revenue]),
        [Revenue], DESC)
      ORDER BY [Revenue] DESC

Third, known caveats: pitfalls that lead to misinterpretation.

known_caveats:
  - "Revenue is quantity x unit price without discount and freight,
     do not describe as net revenue or gross profit."
  - "discount is an unapplied percentage per line item,
     not a monetary amount, never sum it."
  - "country is the customer's country, not the shipper's
     or the product's origin."

And fourth, a domain description: what the dataset is about and what a row represents.

Semantic Layer vs. Context Layer compared

A useful rule of thumb: whatever should hold true for every tool accessing the data belongs in the semantic layer. Whatever an experienced analyst would tell a new colleague during onboarding belongs in the context layer.

What the context layer specifically prevents

Three examples from our demo setup with the Northwind model.

The data gap that looks like a business problem: ask about revenue trends in Germany at the end of 2024, and the data shows a sharp drop. Without context, the AI delivers a convincing analysis about weakening demand. With the event timeline, it recognises that the drop stems from an expired API token. The data is incomplete, not the business weak. That is the difference between an analysis that improves decisions and one that steers them in the wrong direction.

The metric that is named differently from how it is calculated: [Revenue] in the model is quantity times unit price, without discount. If the AI presents that as “net revenue”, every statement built on it is wrong, even though the query itself was correct. The caveat does not prevent a calculation error, there isn’t one, but an interpretation error.

The query that gets it almost right: verified questions give the AI checked templates for which measures are canonical, how time periods are filtered, and how top-N breakdowns should look in the model. Instead of improvising anew for every question, the AI varies proven templates. That noticeably reduces the spread of results.

Getting started pragmatically

A context layer does not need to be complete to show impact. Our recommendation for getting started:

1. Start with the caveats. Ask the team: “Which three misunderstandings do you regularly correct when someone works with this data?” The answer gives you your first known_caveats.
2. Log events as they happen. A campaign launch, a data outage, a system migration: two lines in the timeline at the time of the event are cheaper than any later reconstruction.
3. Distil verified questions from real requests. Take the questions that keep recurring in daily work, answer them cleanly in DAX once, and store them as templates.

Ownership matters here: the context layer is not an IT artefact but documented business knowledge. It belongs where that knowledge originates, with analysts and the business. As a YAML file, it is readable, versionable and maintainable without any tooling overhead. Changes take effect immediately, with no deployment or model refresh.

Conclusion

Semantic Layer vs. Context Layer, compared directly: the semantic layer ensures the AI calculates correctly. The context layer ensures it interprets correctly. Anyone serious about using AI-powered analytics on company data needs both. The good news: the semantic layer already exists in most Power BI environments. The context layer starts with a text file and three honest sentences about your own data.

If you are still weighing up where your own semantic layer should architecturally live, our article Choosing the Right Semantic Layer Architecture offers guidance.

At Hopmann Marketing Analytics, we help BI teams and marketing organisations build a structured context layer that makes AI-powered analytics reliable in daily use. Would you like to know what that could look like for your semantic models?

Tobias Lanzl is Manager Data Analytics at Hopmann Marketing Analytics, a certified Power BI expert specialising in AI-powered analytics architectures at the intersection of semantic models, context layers and large language models. As a former research associate and university lecturer, he brings the ability to make complex topics accessible in ways that work in practice.