Semantic Layer Consultant: What We Do and When You Need One

The Problem With Most Semantic Layer Advice

Almost every guide on semantic layers is written by someone selling one.

Cube writes about why you need a headless semantic layer. Looker publishes LookML tutorials that assume you are already on Google Cloud. dbt Labs explains MetricFlow in a way that makes dbt the obvious answer. Snowflake's documentation explains Semantic Views as though every company already runs on Snowflake.

None of that advice is dishonest. But it is not independent. When the person advising you has a product to sell, the recommendation will always bend toward that product.

A semantic layer consultant with no product to sell gives you different advice. Sometimes the answer is dbt's Semantic Layer. Sometimes it is Cube. Sometimes it is LookML, or Snowflake Semantic Views, or AtScale, or something built directly on top of your warehouse with minimal tooling. The right choice depends on your stack, your team, your existing investments, and what you are actually trying to accomplish. Not on which vendor has the best sales process.

That is what independent consulting looks like. And it is rarer than it should be in this space.

What a Semantic Layer Consultant Actually Does

The title sounds narrow. The work is not.

A semantic layer is where business logic lives in your data architecture: the definitions of your metrics, the relationships between your entities, the governance rules that determine who can see what. Getting it right requires understanding how your business thinks, how your data stack is built, and how your analysts and AI systems will consume data downstream.

In practice, the work falls into three areas.

Architecture review and design. Before building anything, you need to know where your semantic layer should sit, what tooling fits your stack, and what trade-offs each option carries. This is the most valuable work a consultant can do, and it is the work most commonly skipped. Teams buy a tool, then figure out the architecture. The right sequence is the opposite.

Implementation and build. Writing the actual metric definitions, dimension tables, access policies, and governance logic. This is technical work. It requires understanding dimensional modeling, your warehouse's SQL dialect, and how downstream consumers (BI tools, AI agents, APIs) will query the layer. Done well, it produces a semantic layer that is maintainable, testable, and extensible. Done poorly, it produces another source of conflicting definitions that no one trusts.

Team enablement. A semantic layer only works if your team can maintain and extend it. Part of the engagement is making sure your analytics engineers and data team understand the model they are inheriting, can add new metrics without breaking existing ones, and have the governance processes to keep definitions consistent over time.

When You Need a Semantic Layer Consultant

Not every organization does. There are situations where hiring a consultant is the right move and situations where it is not.

You probably need one if:

Your BI tools disagree with each other. Finance runs a revenue number. Marketing runs a different revenue number. The executive team has stopped trusting the dashboards and is making decisions from spreadsheets. This is a semantic layer problem, and it will not resolve itself through more dashboard work.

You are deploying AI on top of your data stack and the outputs are unreliable. AI agents and LLMs that query data without a semantic layer will produce answers that are fast, confident, and frequently wrong. If your AI initiative is stalling on data quality and consistency issues, the bottleneck is almost certainly the semantic layer, not the model.

You are evaluating semantic layer tooling and do not know which option fits your stack. The vendor landscape has matured but also fragmented. dbt Semantic Layer, Cube, AtScale, Snowflake Semantic Views, LookML, and several newer entrants all solve related problems with different trade-offs. An independent evaluation of these options, grounded in your specific stack and use cases, will save you from a vendor selection you will regret in 18 months.

You have a semantic layer that has become a liability. Many organizations built a semantic layer two or three years ago in LookML or a BI tool and it has not kept pace with the business. Metric definitions are outdated. Governance is informal. The layer that was supposed to be the single source of truth has become another system nobody fully trusts. Rebuilding or migrating this layer requires a clear plan and usually external perspective.

You probably do not need a consultant if your data team is small, your metric definitions are simple, and you have not yet built any semantic layer infrastructure. In that case, start with dbt's Semantic Layer or Snowflake Semantic Views, document your metric definitions carefully, and bring in outside expertise when you hit the limits of what your team can solve internally. Starting simple and iterating is a legitimate strategy.

What Unwind Data Does Differently

Unwind Data is an independent data and AI consultancy based in Amsterdam. We work with scale-ups and enterprises across Europe on data infrastructure, data architecture, and AI readiness.

We do not sell software. We do not have preferred vendor relationships that create commission incentives. Our only interest is in building the right architecture for your stack, your team, and your business objectives.

In practice, that means a few things.

We start with your business logic, not a tool recommendation. The first question is not "which semantic layer tool should we use?" It is "what are the five metrics your business runs on, where do they live today, and why do different systems disagree about them?" The tool choice follows from the diagnosis, not the other way around.

We work across the full semantic layer tooling landscape. We have built production implementations in dbt Semantic Layer with MetricFlow, Cube, AtScale, Snowflake Semantic Views, and LookML. We know the failure modes of each and can give you an honest assessment of where each one struggles in practice, not just in the vendor's documentation.

We connect semantic layer work to the broader data foundation. A semantic layer built on top of a poorly governed transformation layer will fail regardless of how good the tool is. We look at the full stack: ingestion, transformation, semantic, and serving. The semantic layer work we do is designed to fit into a data architecture that can support AI agents, not just BI dashboards.

We transfer knowledge, not dependency. The goal of every engagement is for your team to be able to maintain and extend what we build without us. That means documentation, internal training, and architectural decisions that your analytics engineers can understand and own.

What an Engagement Looks Like

Engagements vary by scope, but most follow a similar structure.

The first step is a discovery and diagnostic session. We map your current data stack, understand your metric definitions and where they live today, identify the conflicts and inconsistencies that are causing trust problems downstream, and assess your tooling options against your specific constraints. This is typically a focused engagement of one to two weeks that produces a clear architectural recommendation and a prioritized implementation plan.

If you move forward with implementation, the work depends on what you need. For organizations building a semantic layer from scratch on an existing warehouse, implementation typically runs four to eight weeks depending on the number of core metrics and the complexity of your data model. For organizations migrating an existing semantic layer (from LookML to dbt, for example, or from a BI-embedded model to a headless layer), the timeline depends heavily on the state of the existing model.

For organizations evaluating AI use cases that depend on governed data, we often run a combined engagement: data foundation assessment, semantic layer implementation, and AI readiness validation. The goal is to get to a state where AI agents querying your data return reliable, auditable answers, not plausible-sounding guesses.

The Honest Version

A semantic layer consultant is most valuable when the problem is already painful enough that someone in your organization is actively blocking AI or BI initiatives because the data cannot be trusted.

If you are at that point, the investment in getting the semantic layer right will pay back faster than almost anything else in your data stack. Every AI project, every BI dashboard, every analyst query benefits from having a single source of truth for your business logic. The semantic layer is infrastructure. Its value compounds.

If you are not at that point yet, the most useful thing you can do is read the architecture before you buy the tool. Understand what a semantic layer is, where it fits in your stack, and what trade-offs each implementation approach carries. The decisions you make now will constrain your options in two years.

Either way, we are happy to talk through where you are. There is no sales process here, just a conversation about your stack and what the right next step looks like for your team.

If that sounds useful, reach out directly at wesley@unwinddata.com.