The Second Semantic Layer Is the Real Objection

The objection nobody says out loud

When an AI analytics tool gets evaluated in a retail business, the loudest objections come from security and finance. Those are answerable with documents. The objection that actually kills the deal usually comes from the person who owns the warehouse, and it is rarely stated in a meeting.

It is this: we spent two years getting everyone to agree what "fill rate" means, and this tool is going to publish a different number.

They are right to worry. A second semantic layer is not a theoretical risk. It is the single most common way analytics tooling makes an organisation worse, and it happens gradually enough that nobody notices until two decks disagree in front of the board.

How a second layer gets built by accident

Nobody sets out to build one. It arrives in three steps.

First, the new tool needs a metric that does not exist in the warehouse yet, or exists in a form it cannot read. Someone defines it inside the tool, reasonably, to unblock a demo.

Second, that definition diverges. The LookML or DAX version gets a fix for a store-closure edge case; the tool's version does not, because nobody remembers it exists. The two numbers are now different by a small amount that looks like noise.

Third, someone builds on the tool's version. A target, a bonus calculation, a supplier conversation. Now the divergence has a constituency, and reconciling it is a political problem rather than a technical one.

By the time this is visible it has usually been true for two quarters.

The fix is structural, not procedural

The common response is governance: a process, a review, an owner for metric definitions. That helps, and it fails eventually, because it relies on people remembering to do something at exactly the moment they are under pressure to ship.

The structural fix is to make the second definition impossible rather than discouraged. That means the tool queries the underlying tables and treats your existing definition as the one that counts, rather than importing, forking, or shadowing your model.

Concretely, three properties are worth insisting on:

• It reads tables, not your Explores or datasets. Querying through your semantic layer sounds respectful and creates a coupling that breaks every time you refactor.
• It publishes no competing measures. If it needs a metric you have not defined, that should surface as a gap for your team to fill, not as a definition the vendor invents.
• Where a metric is defined in LookML or DAX, that definition wins. Stated as a property of the product, not a configuration option somebody has to remember to set.

The uncomfortable corollary

If a tool genuinely defers to your definitions, then when your definitions are wrong, the tool is confidently wrong with them.

This is worth saying plainly during evaluation, because the alternative sounds better and is worse. A tool that quietly "corrects" your fill-rate definition is a tool that will disagree with your own reporting in front of a supplier, and you will not know which one to defend.

In practice the deference tends to surface data-quality problems faster rather than hiding them, for one reason: a wrong number that arrives with the SQL attached is debuggable in minutes. A wrong number on a dashboard is debuggable in a meeting.

Four questions that settle it

You can establish where a vendor sits on this in about ten minutes.

"Show me the SQL behind that number." Not a description. The query, the source tables, the parameters. If it takes a support ticket, the answer to everything else is academic.

"Which of these metrics did you define, and which did you read from us?" A vendor who cannot separate the two on request has not thought about the problem.

"What happens when we change a definition in LookML?" The right answer is nothing, because they read the tables underneath it. Any answer involving a sync is a coupling you will maintain forever.

"What load does this put on the warehouse, and how do I see it?" If queries run as a service account you issued, you can answer this yourself from your own monitoring on day one, and throttle or revoke without asking anyone.

What the data team should be left with

The version of this that works leaves the warehouse as the system of record, your roles and masking policies governing access, your definitions authoritative, and your team still owning modelling, quality and architecture.

What comes off the team's plate is the ad-hoc queue: the questions that never needed a human, arriving better formed when they do escalate, and the recurring ones turning into procedures that stop being requests. That is a real change to how a data team spends its week, and it does not require anybody to give up the semantic layer to get it.

Any vendor asking you to trade one for the other is offering a worse deal than they think.