Write once. Compile anywhere

How a semantic compiler eliminates metric inconsistency at the source

Every data team has a version of this story.

Someone flags a number. Revenue looks wrong in the board deck. The analyst checks Power BI. Different number. Someone pulls the Snowflake query. Third number. By the time you've traced the discrepancy through 4 dashboards and a spreadsheet, you've lost several hours, and nobody knows which figure to trust.

Each of those dashboards probably had a perfectly reasonable metric definition baked in. The trouble is that "baked in" is the architecture. Each BI tool, each report, each AI agent defines revenue in its own local context. And local context drifts.

The drift problem

Most organizations don't discover they have fragmented metric logic. They accumulate it.

A new BI tool gets onboarded. The analyst team copies the DAX definition from Power BI, translates it into Looker, and ships it. Six months later, someone tweaks the Looker version to handle a new product line. The Power BI version doesn't get the update. A year later, a new team builds on Snowflake semantic views, starting from the warehouse schema rather than from what BI defined.

Now you have 3 revenue versions. All of them are defensible. None of them agrees.

The standard fix is governance theater: a data dictionary that documents the "correct" definition, a Confluence page nobody reads after the first quarter, a stewardship process that works until the next reorganization. Documentation is downstream of the problem. It doesn't touch the code.

The compile paradigm

Programming languages solved the same problem 40 years ago.

You write code once. A compiler translates it into the native artifacts your target platforms need. You don't maintain separate versions of the same logic for Windows and Linux. You write once, compile anywhere.

MetaKarta Semantic Hub applies that same principle to business logic.

Define a metric once in a semantic model. Semantic Hub compiles it and pushes it to where it belongs. Compute logic (metrics, dimensions) goes to the database. Databricks gets Databricks metrics views, Snowflake gets Snowflake semantic views, and Oracle gets Oracle analytics views. Navigation logic (hierarchies, UX structure) goes to the BI tool in its native format: Power BI gets a semantic model, Tableau gets a logical data model, Looker gets LookML.

Every downstream consumer — dashboard, spreadsheet, or AI agent — reads from the same compiled definition. The metric can't drift because it's not stored locally in each tool.

Starting from where you are

The obvious question: what about the years of metric definitions already living inside your BI tools?

Semantic Hub includes a reverse-engineering engine that scans existing assets (Power BI semantic models, Tableau data models, database schemas), extracts the logic, and merges it into a unified model. You get a single place to clean it up rather than starting over.

The messiest part of any migration is expression translation. DAX to SQL, for instance, is tedious and error-prone when done by hand. Semantic Hub handles that automatically. You can also describe logic in plain language and let Semantic Hub generate the correct syntax for your database backend and BI frontend. You ship a governed standard.

The Semantic Model IDE, AI copilot, and playground strip out the archaeology work. You spend time on architecture, not on hunting down where the old calculation lived.

Native compilation, no middleware

Semantic Hub compiles directly to the native SQL of your underlying platform: Databricks, Snowflake, Oracle, SAP HANA. There's no query engine sitting between your users and their data, no proprietary language to learn, no black box to debug when something breaks at 2 am.

For performance, Semantic Hub instructs the database to create and manage its own cached aggregates using native capabilities like Materialized Views. Sub-second response times on billion-row datasets come from the database's own engine, not from shuttling data into a middle tier that needs constant refreshing. You orchestrate the caching strategy within Semantic Hub; enforcement occurs upstream at the database level.

Security compiled into the source

Compilation applies the same way to access control.

Define Row-Level Security, Column Masking, and Role-Based Access Control once in Semantic Hub's central policy engine. Semantic Hub compiles those policies directly into the database's native security engine. When a user queries the data via Excel, an AI agent, or a custom application, the database enforces the rules at the source.

There's no middleware layer to route around, so there's no route around the security.

Grounding AI on governed definitions

Text-to-SQL is only as good as its context. Databases like Databricks and Snowflake offer strong natural language query capabilities, but they need to know what things mean. Your team has to manually create the business context: descriptions, synonyms, valid column values, and all the metadata an AI needs to avoid hallucinating. That work is slow.

Semantic Hub automates it. When you compile a metric, you're also compiling its context: descriptions, synonyms, security policies, and calculation logic. The database's AI features inherit that context automatically. AI agents querying your data receive the governed definition without a prompt-engineering layer bolted on.

Lineage as a structural output

Compilation generates a dependency graph.

Semantic Hub visualizes that graph as a full lineage map, from the metric in a dashboard back through its semantic definition and the transformation layer to the raw source column in the warehouse. Rename a database column, and you'll immediately see which semantic definitions reference it and which dashboards will break. 

When a metric shows unexpected values, you trace back through the dependency chain to find where the calculation went wrong. You don't need a separate lineage tool. The compiler writes it as it runs.

Open standard underneath

Semantic Hub runs on Semantic Hub Language (SHL), an open-source YAML specification built for semantic automation. Organizations that want to extend the model, wire it into CI/CD pipelines, or automate lifecycle management can work directly with SHL. The underlying format isn't proprietary.

Sign up for the public preview

Metric inconsistency doesn't come from bad analysts or bad tools. It comes from an architecture that stores business logic locally within each consumer and then asks governance teams to keep all those local copies synchronized by hand. Compilation routes around that entirely. Define the logic once. Let the compiler handle the rest.

With Semantic Hub, you can ensure consistent business logic across systems and tools, reducing metric drift and shortening reconciliation cycles. No middleware, no runtime dependency, no lock-in. Sign up below for the Semantic Hub public preview today.

Public Preview Sign Up