THE PRAGMATIC MESH SERIES PART 7: Why AI needs a map to your metrics, not a second copy of them

Everyone Suddenly Needs a Semantic Layer
Something changed in the last two years. Teams that spent a decade comfortable with “everyone has their own definition of revenue, and we mostly cope” suddenly decided they needed one canonical definition, now, as a priority. The trigger wasn’t a new reporting requirement. It was AI.

When O’Reilly asked early adopters why they prioritized a semantic layer now rather than two years ago, “the answer was consistent: AI.” The reason is sound. Point an AI agent at raw tables and it guesses how they join, what a single row represents and which of four “revenue” columns you meant. Give it the business meaning and its accuracy climbs. In dbt Labs’ April 2026 benchmark, two current models got 84 to 90% of the answers right writing their own SQL, and 98 to 100% through a semantic layer. dbt sells one, so weigh that, but its summary rings true: “With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message.”

Research institutes with nothing to sell agree. MIT’s Center for Information Systems Research (CISR) found that organizations with well-developed data curation were “more than three times as likely to be effective at implementing value-realizing data and AI initiatives”, and only 21% of executives rated their own curation that well. Note exactly what that measures: curation maturity, not centralization. The real question is which way of organizing produces mature curation, and keeps it mature in year three.

The market has noticed. Snowflake has semantic views, Databricks metric views, dbt Labs open-sourced MetricFlow, and the Open Semantic Interchange is now an Apache project, Apache Ossie, backed by Snowflake, dbt Labs, Databricks and Qlik, among others.

So the pressure is real. A reader put the sharpest version of it to me in the comments on Part 3: when business logic lives inside the analytics app, the knowledge stays locked downstream, and that matters even more when the consumer is “an AI agent that depends entirely on what the metadata tells it.” This part is my answer. It starts by challenging the default response, because almost everywhere I look, it quietly rebuilds both of the failures this series opened with.

The Obvious Fix Backfires
Here’s the reflex. You decide you “need a semantic layer,” so you buy or build one. The tools differ, but the pattern is the same: your metrics (revenue, churn, margin) are written out again as fresh definitions in YAML or a modeling language, governed in one place, sitting above and apart from the apps your business already uses, and owned by a central team.

Read that back through Part 1 and you’ll feel the floor give way. The whole point of the central layer is to be the single place where “revenue” is defined, versioned and served, so that, in dbt’s words, “agents return the same answer everywhere.” That isn’t a new idea. It’s the data warehouse’s centralizing move, restated for the age of agents.

And it runs on the mechanism Part 1 called delegation of blame. Once a definition lives as version-controlled configuration, owning it comes to mean controlling its files. Accountability for a number drifts to whoever can edit the config, open a pull request and pass review, and away from the team that lives with the consequences of getting it wrong. Your domain team stops owning its own metrics unless it grows a platform engineer who breathes CI/CD, Git and YAML.

The reflexive semantic layer is both of Part 1’s traps at once, the centralizing warehouse and the mesh that taxes every team with engineering work, now wrapped around the analytics you already have, as a refactoring project.

It’s the data warehouse’s centralizing instinct, rebuilt, rebranded and sold back to you for AI.
A Second Semantic Layer Is a Second Bill, Paid Indefinitely
Here is what it costs you, every quarter after the launch slide.

It re-centralizes meaning. A central team that owns the meaning of churn for the whole company is the furthest thing from the consequences of getting it wrong: the ticket-driven environment that Part 2 showed quietly kills ownership. The people who actually know that churn excludes paused plans sit in Ops, not on the team running the registry.

It brings back the engineering tax. Every time the layer is asked for a number, it reads its definition from configuration, generates the query and runs it. That’s real, useful engineering, but it is precisely the overhead that makes domain teams, their dependencies and their complexity grow for no good reason.

It makes you rebuild, then maintain what already works. Your Qlik load scripts already encode these rules, correctly, and your domain experts already understand them. The separate layer asks you to write all of that out again, in a language only specialists can edit, and then keep two copies in sync forever. Drift between two definitions of the same thing isn’t a risk. It’s the default state of any system with two sources of one truth.

Every metric you recreate is a metric you have to maintain twice.
Slowly updated universal truth loses to the local bypass. Tanmai Gopal of PromptQL put it in one line: “The business iterates weekly; the data platform iterates on quarters.” Every correction is another slow round-trip through the central team, so analysts, and agents, route around it and go back to the raw tables. Now one official truth coexists with a dozen unofficial ones: both of Part 1’s problems at once, reincarnated.

A definition is only true while someone maintains it. Real metric knowledge lives with the people who run the business and whose success depends on the metric. Central, ticket-measured roles rarely have the means to maintain every definition proactively. Even if the central team were as motivated as the business to keep everything up to date, its scope is so broad and complex that its decisions come far too slowly. When maintenance lapses, a canonical layer doesn’t throw an error. It quietly rots into stale-but-still-queried, and then it misinforms every agent that touches it, at machine speed, with total confidence.

You’re About to Buy What You Already Built in Qlik
Stop asking “which semantic layer should we buy?” and look at what’s already running. A Qlik app is a semantic layer (if built right!). Nobody called it that, but that’s what it is:

The load script defines facts and basic business concepts, such as new or recurring customers: what each field means, how it’s transformed and which row-level security applies to which groups of users. The definition sits where the metric is computed.

The associative model holds the relationships between every relevant entity and attribute, so questions can be answered fast and from any angle.

The master library codifies the exact metric and dimension definitions, including drill-down hierarchies, while variables holding set analysis standardize finer business rules, such as which orders count in lead-time calculations and exactly how they are aggregated.

It’s owned by the domain, built in the app by the full-stack developer (Part 3) without the platform engineering tax or forced dependencies between teams that need constant negotiation, so it changes at the speed the business actually moves.

Qlik’s own AI already treats it that way: Qlik Answers gives master dimensions and measures priority when it indexes an app, and since February 2026, Qlik’s MCP server lets GenAI assistants such as Claude use Qlik apps’ semantics and, with Projects and Skills, extend them. An underappreciated point: GenAI learns a lot of business context just by studying the most-used Qlik apps and sheets, which show it the main KPIs and the dimensions and visualizations that go with them.

So you already have a decentralized, domain-owned semantic layer, spread across your Sales, Finance and Ops apps. It works. What it lacks is the one thing a central layer is genuinely good at: discoverability. Which official measures exist, which dimensions they combine with, when to use which of two slightly different versions, and where to find the exact definition and result?

The Lean Fix: A Map That Routes, Never Redefines
For well-designed data platforms and Qlik apps, the gap is not definitions. We have those, close to where they’re used, which is what keeps them maintained and up to date. So build the smallest possible thing that closes the discoverability gap, and nothing more. Call it skills.md: a plain-markdown catalog that maps each business concept to the app and measure that already define it.

The name is deliberate. Since December 2025, Agent Skills has been an open standard for giving AI agents knowledge, read natively by agents such as Claude Code and Cowork, OpenAI’s Codex and, most recently, Gemini Spark. A skill is a markdown file whose short description tells the agent when to open it: exactly the shape a routing catalog needs.

The whole design lives in one distinction: It routes; it never redefines. It points to where the logic already lives, and never re-implements it.

That rule dissolves the “which definition wins?” fight you get the moment a platform redefines a metric a domain already owns. There’s no second definition to win and nothing new to keep in sync. The definition stays single and domain-owned; only discovery is shared.

Three things make it work:

Readable by both. A person skims it in seconds; an agent reads it, finds the right app and measure, and fetches a governed answer through Qlik MCP or a data product (Part 4). Because the catalog points rather than holds data, the agent fetches through that governed interface and inherits the same row-level security the human user has. A map can’t leak what it never stores.
Business-owned and engineer-free. Each domain owns its entries. Editing one needs no migration, no pull request, no engineer. It’s the platform getting out of the way, applied to meaning itself, and it’s why the small team stays small.

The thing that decides accuracy becomes prose. Be honest about the limit: no semantic layer, central or not, makes the agent’s job mechanical. The agent still has to pick the right concept before it can follow a route, and that, not query syntax, is where the errors happen. Which is good news, because reliability now depends on how clearly the descriptions are written, and a business expert can write that in plain language.

That’s the quiet payoff. We’ve moved the thing that determines AI accuracy out of code that only engineering can maintain and into prose that only the business domain can get right. The quality of the map becomes the accuracy of the AI, and that is a writing problem.

Your AI’s accuracy simply became a training and documentation task, owned by the existing key users.
A caveat: this holds where the meaning has already been worked out inside the apps, the normal state of business intelligence. It does not hold where the core problem is reconciling thousands of raw sources into shared meaning in the first place. MIT CISR’s own example, Healthcare IQ, harmonizes nearly six million healthcare products from more than 25,000 manufacturers; there, ontologies and knowledge graphs are the product, not overhead. Where no app owns the meaning yet, a map has nothing to point at.

One Churn Definition, Readable by Humans and Agents
Here’s one entry from the Ops domain’s file. You could hand it to a non-technical owner and they could keep it up to date.

Example of a measure definition in a semantic layer catalog
Two paths run through it. A person asking “what’s our real churn definition?” finds the owner, the grain, the exclusion rule and the near-miss in about ten seconds, and knows who to message if it looks wrong. An agent asked “what was customer churn last month?” picks the Ops file from its description, follows the route and returns a governed number with its provenance. If the user actually meant revenue-weighted churn, the “Not this” line stops it from confidently handing back the wrong grain.

Look at what that entry really is: a machine-readable One-Page Data Handshake (Part 5). A named owner, a cadence, grain and meaning, a Trust Score, plus a route and an explicit note about a near-duplicate instead of a silent merge. The semantic layer for AI turns out to be the governance habit you should have been keeping anyway, with a pointer attached.

It doesn’t have to be one heroic file. Keep one file per domain, owned by that domain, and the Agent Skills format gives you the index for free: the agent reads only the short descriptions up front and opens a domain’s file when a question needs it.

And nothing here is Qlik-specific. The catalog routes to wherever a definition already lives, so in a Qlik-and-Snowflake shop an entry can point at a dbt model just as easily as at a Qlik measure: Net Revenue, owned by Finance, is the dbt model finance.fct_revenue in Snowflake. The agent fetches through that source’s own governed interface, so the number keeps the lineage and access rules it already has. The open standards that move data across domains (Parquet, Apache Iceberg and data products, Part 4) are what let a mixed estate resolve through one map.

Map of your semantic layer

AI Governance: Owned, Audited and Defended by the Business

This slots into the four governance rituals from Part 5 with almost no new machinery. The catalog is the index of Data Handshakes, now also readable by an agent. Quarterly Swamp Draining archives routes that point nowhere, or to an app nobody refreshes. The Release Notes Channel announces a routing change (“churn now excludes paused plans”) before it reaches the entry. And Stop-the-Line Assertions keep the underlying app honest, so the number a route resolves to is one you can trust.

This is a boundary you have to defend, because complexity always grows back. The catalog is legitimate only as long as it routes and never computes. That doesn’t stop an agent from calculating something the catalog doesn’t cover; it means such an answer must be flagged as an unofficial calculation. But the day someone adds a blended cross-domain calculation to the catalog itself (“let’s just define revenue-weighted churn right here”), it stops being a catalog and becomes a central semantic layer, and the whole centralization trap returns.

The defenses are organizational, not technical:

Each domain owns its catalog entries. The moment a team exists whose job is “owning the whole semantic layer,” ownership has re-centralized, creating bottlenecks and outdated definitions.

A contested concept is surfaced, not merged. When two domains both claim revenue, you don’t quietly pick one. You expose the conflict, and that forces the one cross-domain handshake worth having: a human decision about which source is authoritative for which purpose.

A quality check on form, not a gatekeeper. Software has linters: automatic checks that flag sloppy formatting without judging whether the logic is right. Do the same here: does each entry have an owner, a route, a Trust Score? The Agent Skills standard even ships a validator that checks a file’s shape and nothing else. The format is the one thing worth standardizing centrally, because a shared format stops every use case from inventing its own metadata conventions. Centralize the standard, never the meaning.

A steward of the map’s health, never of its meaning. Someone has to be accountable for the catalog as a system. Is it well formed? Does the check run? Are the questions it cannot answer picked up? Is it honest about what it covers? Data steward is a real, named role, and it gives the catalog an accountable owner without weakening the business domains’ ownership of their own definitions.

I won’t oversell it. It needs the discipline of the rituals, and it breaks the moment it drifts into computing metrics. It also captures only the written-down part of what your organization knows; the rest still lives in people, as Part 5 insisted. Routing just makes sure the agent asks the right person’s app.

Add a Map, Not a Migration
Strip the hype away and the argument is short. GenAI has to be grounded in what your numbers actually mean. But one central semantic layer pulls meaning back to the team furthest from the consequences, taxes every definition with engineering work and leaves you a second copy to keep in sync. Put the whole series in one frame instead:

The local 95% is handled by the mesh: Qlik apps that already are a decentralized, domain-owned semantic layer, each domain with its own skill file and Qlik Answers.

The cross-domain 5% of discoverability is handled by a thin, business-owned, AI-readable map that points to where meaning already lives, and never redefines it.

The actual movement of data across domains is handled by open standards and governed interfaces: Parquet, Apache Iceberg, Qlik MCP and data products, and, for the few definitions that must travel between tools, Apache Ossie.

You get the one real benefit of a central semantic layer, a single trustworthy place to find the answer, and none of its costs: no velocity tax, no engineering tax, no second copy, no canonical model rotting in the dark. The semantic layer you need for AI is the one you already built. The only new thing to write is the map to it.

You don’t need a new semantic layer. You need a map to the one you already paid for, and the discipline to keep it thin.

COMING UP IN THIS SERIES
Part 8: The Semantic Gap. What happens when an agent is asked about a metric nobody has defined yet? Why an improvised answer is fine as long as it says so, and how the questions your map cannot answer show you what to build next.

The meaning of your numbers already has owners. Your AI just needs to know where to find them.