/

Semantic Layer

Semantic Layers in 2026: The No-BS Playbook for Data Leaders

Intergalactic Data Labs

โ€”

โ€”

13 min read

Table of contents

Summarize

Updated October 2026

A semantic layer strategy comes down to four leadership decisions. You decide where business definitions live, who owns them, which domain goes first, and how you will prove the numbers are right. Tools matter less than these choices. In 2026 the stakes are higher because AI agents now query the same definitions your dashboards do.

Decision

Default answer

When to deviate

Where definitions live

Your main data platform

Several BI tools or agents need them

Who owns definitions

Domain teams

Very small data team

Who runs the engine

Central platform team

Fully federated data mesh

First scope

One domain, 10 to 25 metrics

A regulatory deadline forces another

Format

Versioned code in Git

Never skip this

Proof of success

Reconciled numbers and query share

Add agent accuracy tests for AI

What changed for semantic layers between 2025 and 2026?

Three shifts changed the calculation for leaders. Definitions became portable, warehouses absorbed more of the layer, and agents became a first-class consumer. Each one lowers the risk of committing now.

Portability came first. The Open Semantic Interchange entered the Apache Incubator on July 10, 2026 as Apache Ossie, with more than 50 organizations behind it (Apache Ossie). MetricFlow, the engine behind the dbt Semantic Layer, is now under the Apache 2.0 license (dbt Labs).

Platforms also moved closer to the layer. Snowflake made Semantic View Autopilot generally available in February 2026 to build and maintain semantic views (Snowflake). Databricks metric views now sit at the core of Unity Catalog business semantics (Databricks docs).

Agents became a consumer you have to plan for. The dbt Semantic Layer serves governed metrics to AI tools through the dbt MCP server (dbt docs). Snowflake runs a managed MCP server over semantic views (Snowflake docs), and Looker offers one in preview (Google Cloud docs).

Vendors consolidated too. Fivetran and dbt Labs completed their merger on June 1, 2026, with George Fraser as CEO and Tristan Handy as president (Fivetran). If you run dbt, check your contract terms and roadmap commitments at renewal.

Why should data leaders fund a semantic layer now?

Fund it because AI projects fail on unclear data, and a semantic layer is the cheapest fix for unclear metrics. The evidence comes from analysts, academic tests, and vendors.

Gartner found 63 percent of organizations lack, or are unsure they have, the right data management practices for AI. It predicts 60 percent of AI projects without AI-ready data will be abandoned through 2026 (Gartner). Gartner also expects over 40 percent of agentic AI projects to be canceled by the end of 2027 (Gartner).

Accuracy tests point the same way. An April 2026 study found explicit business semantics raised text-to-SQL accuracy by 17 to 23 points across current models (arXiv). dbt reported 98 to 100 percent accuracy through its semantic layer against 84 to 90 percent for text-to-SQL, though only on 11 questions in its own test (dbt).

For the full mechanics of how agents use the layer, see what is a semantic layer. For how it compares with retrieval and graphs, see RAG vs knowledge graph vs semantic layer.

Do you actually need a semantic layer yet?

You need one when the same metric gives different answers in different places, or when software rather than people starts asking the questions. If neither is true, a well-run BI model may carry you for now.

Watch for these signals. Finance and sales present different revenue numbers in the same meeting. Two or more BI tools each hold their own copy of key metrics. Analysts spend review cycles reconciling numbers instead of explaining them. Agents, copilots, or internal apps query the warehouse directly.

If you see two or more of these, the layer will pay for itself in avoided rework. If you see none, keep your definitions in version control and revisit in two quarters. Waiting is a valid decision when it is a deliberate one.

Where should your semantic layer live?

Put the layer where most of your queries already run, then make sure its definitions can leave. The center of gravity follows your stack, not the vendor with the best demo.

Your situation

Likely home

Main risk

One BI tool serves most users

BI-native model like LookML or Power BI

Definitions locked in one tool

One warehouse dominates

Snowflake semantic views or Databricks metric views

Tied to that platform

Many BI tools, apps, or agents

Headless layer like dbt or Cube

More engineering to run

Cross-domain reasoning needed

Ontology-backed layer

Longer modeling effort

The detail on each option lives in our semantic layer tools guide, so this playbook stays on the decision. Whatever you pick, require export to an open format such as Apache Ossie or MetricFlow YAML. That single requirement turns a platform bet into a reversible one.

Keep the catalog in its lane. It should index, certify, and assign owners, while the semantic layer computes the numbers. Our catalog vs metadata layer vs semantic layer guide covers that split in depth.

Should you buy, build, or bring in a partner?

Most teams should combine all three. Buy or adopt the engine, build the definitions yourself, and bring in help only to compress the first rollout. The definitions are the asset, so they should never belong to a vendor.

There is an ownership argument here that leaders often miss. Your metric definitions, entity rules, and business vocabulary are institutional knowledge. That knowledge should live in open formats, in your repository, on infrastructure you control. A layer you cannot export is a layer you rent.

Path

Good fit

Watch out for

Adopt a platform-native layer

Single-platform shops

Lock-in to one vendor

Run an open-source engine

Teams with platform engineers

On-call and upgrade work

Buy a managed headless layer

Many consumers, small team

License cost and contract terms

Build on your stack with a partner

Tight timeline, thin modeling bench

Make sure you keep the code

If you choose the partner path, Galaxy is one option. It is an applied lab that builds semantic layers, ontologies, and entity resolution on the stack you already run. It builds in the open with Filament by Galaxy and plans to open source more of its internal tooling.

Who should own the semantic layer?

Split ownership between the people who know the business and the people who run the platform. Programs fail when either side owns everything.

Role

Owns

Approves

Data platform team

Engine, CI pipeline, access rules, standards

Model structure and performance

Domain owners

Metric definitions for their area

Changes to their metrics

Semantic council

Shared terms like customer and revenue

Cross-domain conflicts

Data governance

Certification and audit evidence

What counts as canonical

Executive sponsor

Budget and priority

Tie-breaks the council cannot settle

Keep the council small and time-boxed. Its job is to settle disputed terms quickly, not to review every metric. If a shared definition takes more than two meetings, the sponsor should decide and the team should move on.

Make ownership visible. Every certified metric needs a named person, not a team alias. When that person leaves, reassigning their metrics should be part of the offboarding checklist.

What should the first 90 days look like?

Pick one domain, prove the numbers match, then let a second consumer use them. The goal of the first quarter is trust, not coverage.

Days 1 to 30, scope and agree

Choose a domain where disagreement is visible and costly, such as revenue or pipeline. Inventory its most-used metrics and pick 10 to 25 to certify. Name an owner for each and write the definition in plain language before anyone writes code.

Days 31 to 60, model and reconcile

Model the metrics in your chosen layer, in Git, with pull requests and automated tests. Reconcile every metric against the report people trust today. Publish the differences and explain each one, since those explanations build more trust than the layer itself.

Days 61 to 90, serve and measure

Connect at least two consumers, such as the main BI tool and one agent or notebook. Route access rules through the layer so every consumer sees the same rows. Start tracking query share and reconciliation gaps, then pick the second domain.

The implementation checklist breaks the technical steps into phases. This plan is the leadership view of the same work.

How should you budget for a semantic layer?

Budget mostly for people and for ongoing ownership, not for software. The license line is easy to see, but modeling time and definition disputes take longer than most teams expect.

Plan for four cost lines. The first is modeling and testing time from data engineers. The second is time from domain experts who must agree on definitions. The third is the license or managed service, which is zero for self-hosted open-source engines. The fourth is warehouse compute, which caching and pre-aggregation can reduce.

Leave room for change. Every reorg, pricing change, or new product line changes some definitions. Treat the layer as a product with a standing team, not a project that ends at launch.

How do you measure whether it is working?

Measure adoption, agreement, and speed of change. A layer nobody routes through is a cost with no return, however clean the models look.

Metric

What it tells you

Direction

Share of queries through the layer

Adoption

Up

Certified metrics with a named owner

Coverage and accountability

Up

Report versus layer mismatches

Trust

Down

Days to ship a definition change

Agility

Down

Agent accuracy on a fixed question set

AI readiness

Up

Report these to your sponsor every month. The agent test matters most if AI is part of the plan. Keep a fixed set of real business questions with known answers, and run it each release.

How do you spot semantic washing?

Ask vendors to show the work. Many products now call a glossary, a saved query, or a tag a semantic layer, and only a demo of real artifacts tells them apart.

Use these questions in every evaluation. Can you see the model file in YAML, LookML, SQL, or another text format? Is every definition versioned, reviewed, and tested in CI? Do two different tools return the same number for the same metric? Are access rules enforced for every consumer, including agents? Can you trace a metric back to its source columns? Can you export the definitions to an open format?

A vendor that fails most of these is selling metadata, not semantics. That may still be useful, but it should not be priced or planned as your semantic layer.

What pitfalls sink semantic layer programs?

Most failures are organizational. The technology works, and the program stalls because nobody agreed, nobody owned, or nobody routed through the layer.

Starting too broad is the most common mistake. Modeling every metric before certifying any means nobody sees value for months. Letting consumers bypass the layer is the second, because one shadow dashboard restores the old disagreement.

Two more show up often. Teams treat the layer as a one-time project and let definitions drift after launch. Teams also mix ontology work into the first release, which slows everything down. Get metrics right first, then extend into concepts and rules as described in how ontology powers AI analytics.

Frequently asked questions

What should a data leader decide first about a semantic layer?

Decide where the definitions will live and who owns them before you pick a tool. The home follows your stack, so a single warehouse points to its native layer and several BI tools or agents point to a headless layer. Ownership follows the business, so each domain owns its metrics while a platform team runs the engine.

Do we need a semantic layer if we only use one BI tool?

Often not yet. If one BI tool serves nearly everyone and no agents or apps query the warehouse, its built-in model may be enough. Plan for the day that changes. Keep definitions in version control, name an owner for each metric, and prefer tools that export to an open format so you can move later without a rewrite.

Who should own the semantic layer?

Split the job. A central data platform team owns the engine, the deployment pipeline, access rules, and the standards every model follows. Domain teams such as finance, sales, and product own the definitions of their own metrics and approve changes to them. A small council settles shared terms like customer and revenue when domains disagree.

How long does a semantic layer rollout take?

A first domain can go live within a quarter if the scope is tight. That means one domain, about 10 to 25 certified metrics, named owners, and tests that reconcile against current reports. The enterprise rollout takes far longer because the slow part is getting teams to agree on definitions. Plan it domain by domain, not as one big launch.

What does a semantic layer cost?

People cost more than software in most programs. You pay for engineers who model and test definitions, for domain experts who agree on them, and for any license or managed service. Compute can drop if the layer caches or pre-aggregates common queries. Budget for ongoing ownership, since definitions change every time the business does.

What is semantic washing?

Semantic washing is when a vendor calls any metadata, glossary, or saved query a semantic layer. A real layer stores definitions as versioned code, compiles requests into SQL, enforces the same access rules for every consumer, and serves many tools at once. Ask the vendor to show a model file, a test run, and two different tools reading the same metric.

How do we measure whether a semantic layer is working?

Track how many queries go through the layer instead of around it. Track how many metrics are certified with an owner, how often reports and the layer disagree, and how long a definition change takes to ship. For AI use cases, run a fixed set of business questions against your agents and score answers against known results each release.

Should semantic definitions live in our data catalog?

No. The catalog should index and certify definitions, but the definitions themselves belong in a semantic layer that compiles them into queries. The catalog tells people which metric is canonical and who owns it. The semantic layer computes the number the same way for every dashboard, notebook, and agent that asks for it.

How does a semantic layer relate to an ontology?

A semantic layer defines metrics, dimensions, and joins for analytics. An ontology defines business concepts, their relationships, and rules across systems, often as a graph. Many organizations start with the semantic layer for numbers and add an ontology when agents need to reason across domains. Open formats keep the two connected instead of duplicated.

What changed for semantic layers between 2025 and 2026?

Portability and agents. The Open Semantic Interchange became Apache Ossie in July 2026, giving metrics a vendor-neutral format. Snowflake made Semantic View Autopilot generally available in February 2026. Fivetran and dbt Labs completed their merger in June 2026. Most major layers now expose governed metrics to AI agents through an MCP server.

More articles

Stay up to date with what weโ€™re building

Stay up to date with what weโ€™re building

Stay up to date with what weโ€™re building

Questions

Answered

FAQ

What does Galaxy do?

What is Filament?

What is enterprise context management?

What does working with Galaxy look like?

How do you handle security and compliance?

Why does Galaxy build in the open?

Own your knowledge stack

Own your knowledge stack

Copyright ยฉ 2026 Galaxy. All rights reserved.