Why business context should come before building semantic layers

When the 2026 State of Data Engineering Survey asked 1,101 practitioners how they model data, just 5.4% stated they use canonical or semantic models. The same group ranked semantics, ontologies, and knowledge graphs third among the topics they want training on.

Why is appetite for semantic layers so high when adoption is thin?

Are semantic layers hard to build? Not particularly. Microsoft renamed Power BI datasets to semantic models in November 2023 and positioned them as the authoritative source of truth behind every report in the largest organizations. The promise attached to them is self-service: an analyst defines a measure once, without waiting on IT, and every report built on the model inherits it.

On the other hand, the self-service promise results in large Power BI deployments holding dozens of semantic layers, each carrying its own DAX measures that vary arbitrarily based on the report author.

A semantic layer gives business decisions a durable place to live. But when definitions are still scattered across teams, dashboards, spreadsheets, and source systems, an AI agent has to infer which version is authoritative. The result may be a semantic model built in minutes that preserves the same disagreements it was supposed to eliminate.

Business context, therefore, has to be made explicit and authoritative before the semantic layer is built.

What purpose does a semantic layer serve?

A semantic layer defines metrics, dimensions, entities, relationships and access rules so that dashboards and agents can query a governed model of the business instead of reasoning directly over raw tables. When an AI agent asks for a metric, the layer constrains how that metric is calculated and how the underlying data can be joined.

The agent still has to interpret the question and select the right metric, dimensions, and filters. What the semantic layer removes is the need for the agent to assume the business logic behind them.

Semantic layers work best on well-modeled data

Semantic layer accuracy numbers are strong and improving. dbt Labs reran its 2023 semantic layer benchmark in April 2026 against the ACME Insurance dataset, measuring how often an LLM could answer 11 natural-language questions with the correct result:

• With Claude Sonnet 4.6, text-to-SQL scored 90% and the dbt Semantic Layer scored 98.2%
• With GPT-5.3 Codex, text-to-SQL scored 84.1% and the dbt Semantic Layer scored 100%
• Within the part of the dataset the dbt Semantic Layer had been modeled to support, it returned the correct result every time
• When a question fell outside the scope of the semantic layer, it failed explicitly rather than producing a plausible wrong answer

The benchmark also shows how much the underlying data model matters. Some questions the semantic layer could not answer in 2023 were still unanswerable in 2026 because the source schema was too normalized for MetricFlow to traverse.

dbt Labs added three intermediate models that denormalized relationships the semantic layer otherwise couldn’t traverse, to expose those relationships, and the semantic layer could then answer every question in the set. The same change helped text-to-SQL. Adding those three models lifted its accuracy from 64.5 percent to around 90 percent.

Both approaches improved once the data underneath had been modeled in a way that made the questions answerable. The semantic layer delivered excellent results, but those results depended in part on the quality and shape of the data model beneath it.

Business logic has to be settled before data modeling

The dbt benchmark shared above shows how much semantic layer performance depends on a well-defined data model. But a real enterprise data project starts with messy business logic scattered across dashboards, policy documents, ERP configuration, spreadsheets, and the knowledge in people's heads.

Before business logic can become a data model, teams have to elicit and reconcile it. While some answers can be found in existing material, others only emerge when gaps and contradictions force a business decision.

Skipping the hard work of elicitation pushes ambiguity downstream into the data model or semantic layer for the coding agent to resolve how it sees fit, AKA making dangerous assumptions.

Business context can’t all be harvested

In May 2026, Gartner advised data and analytics leaders to establish a context layer as core infrastructure for agentic AI, arguing that schema-based data models alone lack the business meaning agents need. Gartner expects organizations that prioritize semantics in AI-ready data to improve agent accuracy and reduce cost.

Some of that context can be harvested from schemas, documentation, lineage, dashboards, and existing systems, but the rest emerges through elicitation: which definition multiple business stakeholders stand behind, which exceptions apply, etc.

Semantic layers, ontologies, and knowledge graphs can preserve those decisions once they exist, but they can’t make the decisions themselves. Left to interpret on its own, a coding agent can decide, based on a semantic layer, to encode a business rule Finance stopped using two quarters ago.

AI agents make unresolved context executable

Coding agents can turn business requirements into working data models remarkably quickly, but speed becomes a liability when business requirements are incomplete. If two sources disagree and nobody has established which one is authoritative, the agent still has to choose a path to keep building.

An unresolved business decision can become transformation logic, tests, and downstream metrics before anyone realizes a decision was made at all.

A spec makes business context explicit before agents start encoding it

Spec-driven development gives business context a form that can be handed to a person or coding agent:

• Definitions with an owner and an authoritative source
• Transformation rules, entity mappings and source precedence, stated precisely enough to implement
• Edge cases with the expected treatment, including returns, backdated changes, currency, and late-arriving records
• Open decisions surfaced for the right owners to resolve before implementation
• Validation criteria tied to figures the business trusts

Generating the spec often surfaces decisions the team never explicitly made. A missing owner, unresolved exception, or absent validation criterion becomes visible before the coding agent has to fill in the gap itself.

The spec then carries those decisions through the rest of the build. It can steer the coding agent, brief a human developer, preserve the reasoning behind the data model, and later supply the definitions the semantic layer needs.

Give the semantic layer resolved business context

A semantic layer still has an important job: it gives dashboards and agents a governed way to query approved metrics, dimensions, relationships, and access rules. It works best when the business logic behind those definitions has already been resolved and encoded in the data model.

When teams wait until the semantic layer to reconcile definitions, exceptions, or source precedence, they are asking it to serve governed meaning and settle what that meaning should be at the same time, work that belongs upstream, before a coding agent starts building.

Maxa Autopilot Spec reads the material where business context lives, including meeting transcripts, dashboard screenshots, documentation, spreadsheets, and source-system material. It surfaces conflicting definitions and missing decisions, captures the resolutions, generates validation criteria, and packages the result into spec files your coding agent can build from.

The result is a data model built from explicit business context, and a semantic layer with something authoritative to govern.

Make the business context explicit with a spec before you build with AI.