Guidelines For How to Measure A Digital Transformation ROI
Guidelines For How to Measure A Digital Transformation ROI
August 5, 2026
Inside a 90,000-Customer Fintech’s AI Infrastructure Playbook
Inside a 90,000-Customer Fintech’s AI Infrastructure Playbook
August 17, 2026
Guidelines For How to Measure A Digital Transformation ROI
Guidelines For How to Measure A Digital Transformation ROI
August 5, 2026
Inside a 90,000-Customer Fintech’s AI Infrastructure Playbook
Inside a 90,000-Customer Fintech’s AI Infrastructure Playbook
August 17, 2026

The Semantic Layer Why 30 Years of Tech Haven't Stopped Boardroom Arguments

You’ve read this a hundred times: Sales says revenue is one number, Finance says another. And Customer Success offers yet a third. Nobody in the room can agree which one is accurate.

Sure, it’s an overused marketing pain point, but it’s a  , too, and AI is exposing it like never before. What we call “the semantic layer” has evolved over 30 years, but closing the gap is a governance problem we keep running away from.

The Fix That Already Existed

Thirty-five years ago, BusinessObjects built the “Universe”: one place where “revenue” got a name, a definition, and a formula, so every department pulling a report got the same number. 

Oracle built the same fix into OBIEE and called it the RPD, a repository file with its own physical, logical, and presentation layers. Different vendor, same fix: shared definitions, categories, and hierarchies sitting between the data and everyone pulling a report from it. That’s what people mean when they say “semantic layer.”

That solved it for relational databases, but OLAP cubes solved the same problem by locking metric logic into a preaggregated data structure. Microsoft SSAS, Cognos, and Essbase carried that approach through the 90s and 2000s. If someone wanted “Revenue by Region,” the cube used its built-in definition, calculated the number, and served it up.

It worked. But with a catch.

It only worked inside those specific, proprietary tools. They were heavy, expensive, and locked your definitions inside each vendor’s walled garden. When business intelligence moved past monolithic stacks, the definitions fractured with it.

Then data lakes took over. “Schema on read” became the norm, and meaning stopped being anyone’s job.

Shortly after, cloud data warehouses arrived, compute became dirt cheap, and the industry shifted from ETL to ELT. Suddenly, dumping raw data into a warehouse and writing SQL on the fly became the fastest way to get an answer. But when every analyst writes custom SQL queries against raw tables, every analyst invents their own custom definition of “revenue.”

That’s the gap LookML, dbt’s semantic layer, and now Snowflake and Databricks building it straight into the warehouse have all been trying to close.

How a Semantic Layer Resolves This

Strip away the vendor names and a semantic layer does three specific things.

First, it names each version of a definition uniquely, instead of leaving three departments to share one ambiguous word: Sales’s booked number, Finance’s recognized number, Customer Success’s active number.

Second, it defines each one, so whoever’s reading a number knows exactly what it involves, instead of having to guess.

Third, it sits between the data and everyone asking a question of it. A person building a board deck, or an AI agent answering “what’s our revenue,” pulls one of those three named definitions on purpose, instead of whichever one happened to be on the screen.

A semantic layer turns three unlabeled guesses into three named, defensible numbers. That’s real progress.

But it’s not the whole job.

Rebuilt Four Times, Fixed Once

Each rebuild solved it for its own tool. LookML’s definition didn’t talk to dbt’s. dbt’s didn’t talk to Snowflake’s. The business ended up with one number per tool, which was the department problem all over again, just one layer up.

To break down those silos, the industry has pushed two solutions: headless semantic layers like Cube and AtScale that serve metrics via API, and open standards like the Open Semantic Interchange (OSI, now Apache Ossie) backed by Snowflake, dbt Labs, Databricks, and Salesforce.

The goal of these open specifications is to let metric definitions speak a universal language so a definition written in dbt or Cube can be read directly by Snowflake, Tableau, or an AI agent without being rewritten.

That is real, necessary technical progress. But it still doesn’t solve the boardroom argument.

Nobody's Department Is Wrong

To be fair, it’s not the definitions that are wrong. 

Sales counts the deal the day the contract is signed, because that’s the number their quota is measured against.

Finance counts it once the work is actually delivered, sometimes spread across the length of the contract, because that’s what GAAP requires before it can call the money earned.

Customer Success only counts what’s still active today, because renewals are what their number gets measured against. No one in the room has to defend themselves.

They are each correct according totheir own point of view. The problem is someone needs one definitive number and has three to choose from. Somebody still has to decide which “right” answer governs the board deck, the comp plan, or the forecast. If nobody’s in charge of that call, it gets made by default: whoever built the dashboard, whoever spoke last, or for AI, whichever it feels like.

What Actually Closes the Gap For AI

An open standard like Apache Ossie can translate a metric specification across 50 different tools, but it can’t choose which spec is right. It makes metric logic interoperable; it doesn’t make it authoritative.

A headless semantic layer works the same way. It can enforce a metric definition once someone sets it, but it can’t decide what that definition should be either. That call still needs a named human, one with the authority to make it and defend it.

With a semantic layer and an open standard, an AI agent simply requests a named metric, like “Finance GAAP Revenue,” and gets a fully vetted, standardized answer. Without that infrastructure, it writes SQL against raw tables and guesses the business logic on the fly. It doesn’t know whether “active revenue” means filtering for active account statuses, excluding refunded line items, or accounting for trial periods. So, it invents its own logic to calculate it.

A person can pause and say, “Wait, let me verify which definition we’re using first.” An AI agent doesn’t pause. It simply goes with whatever logic it determines best, delivers the answer with absolute confidence, and moves on.

That’s what needs to happen before anyone plugs an agent into this data: somebody decides, in writing, which definition it’s allowed to use, and has the power to back that decision up. Universe needed exactly that. So does the agent.

The Takeaway

Tech won’t save you from a lack of data governance.

A semantic layer settles the argument over what the numbers mean, but what still needs deciding is which answer governs the board deck, sets the comp plan, or guides the AI agent the next time someone asks how the quarter went.

The semantic layer has been repeatedly reinvented over the last three decades, but technology was never the missing ingredient. That has always been having someone with the authority to say which definition wins, and the power to enforce it.

Comments are closed.