A semantic layer that runs the query.

Every enterprise is a data museum

Wing after wing of systems from different eras, each built by people who are mostly gone, each correct in its own period. The mainframe extract nobody dares retire, the warehouse from the last re-platforming, the SaaS app finance bought in 2019, the lake somebody filled and left. You are not going to demolish it. Consolidation programs are attempts to demolish the museum, and they run for years, cost a fortune, and end with one more wing.

The job is navigation. Which room holds what, which corridors actually connect, which doors you're allowed through, and a guide who walks you rather than handing you a floor plan and wishing you luck. Get that right and the age of the collection stops mattering — a 1994 system reachable by a legal, governed path is more useful than a modern one nobody can find.

"Business terms" is not a layer

The usual defense of a semantic layer is that it expresses data in business terms. If that's the whole value, what you actually have is badly named tables. There is no law of physics preventing a column from being called customer_lifetime_value and carrying an accurate description of what it means, how it's calculated, and when it's wrong. Comments and column descriptions have existed in every database for decades. A layer whose job is renaming cust_dim_x and writing the sentence that should have been there already is a rename script with a license fee.

The things that genuinely can't live in a name or a description are the ones worth building a layer for: which joins are legal and which are nonsense, whose row this is and whether you may see it, which physical copy answers this question fastest, and what happened when someone asked. A description tells you what a column means. It cannot refuse a query.

So this isn't a proposal to rename the collection. Nobody is going to rename forty years of tables, and the systems that hold them would not survive the attempt. We build the card catalog — every holding registered where it stands, under a name a person recognizes, with the paths between them written down and the doors marked. The artifacts stay in their wings. What changes is that you can find them, walk between them legally, and ask a question without first knowing which era answered it.

"That sounds like an impossible amount of work"

It would be, done by hand — and by hand is the only way it has ever been offered. Nobody has ever argued against knowing what data you have, what it means, and who may see it. That part was never controversial. What made it a joke was the method: a two-year cataloging program staffed by people typing descriptions into a tool that couldn't act on them, obsolete before it was finished. The philosophy was fine. The tooling asked humans to do the machine's half of the job.

So most of this catalog isn't written by people.

• Structure is read, not typed. Register a source and its tables and columns are discovered from the source itself. For files, you register a location — a folder, a bucket, a SharePoint site — and the crawl registers what it finds.
• Foreign keys become corridors automatically. Existing FK constraints register as relationships in both directions, named for the concept rather than the constraint.
• Where the FKs were never declared, they're proposed. Claude reads the schema and suggests the missing relationships with cardinality, a confidence score, and its reasoning.
• People approve, they don't author. Those suggestions land as candidates, not live edges. A steward accepts or rejects. Reviewing a proposed join is a minute's work; discovering it from scratch is an afternoon's.

The other half of the answer is that you never catalog the museum. You catalog the wing that has a question waiting on it. Domains register independently, so one team can put its corner under a governed API this month without a program to boil the estate first — and the corridors between wings get registered when someone actually needs to walk one.

The argument infrastructure already had

Servers used to be provisioned by scripts, and everyone accepted it, because the script was how the thing got built. Then Terraform and Kubernetes moved the artifact: you declare what should exist, the system works out how to get there, and "what is actually deployed" becomes a question you answer by reading state rather than by re-running a program and watching. Nobody defends the shell script now. The argument that won it wasn't that scripts were bad — plenty of them were fine. It was that a declaration can be diffed, reviewed, and queried, and a procedure can only be executed.

Data never had that moment. A pipeline is still a deploy script, and the estate is still described by whatever ran last night. The semantic layer is where the same move applies: declare the sources, the relationships, the meaning, and the policy, and let those be state you can query rather than a program you re-run to find out.

The comparison is also candid about the escape hatch. Terraform has local-exec. Everyone knows what it means when they see one, it shows up in state like everything else, and it did not sink the model — because a labeled exception inside a declared graph is a thing you can find. That is exactly the arrangement here.

Infrastructure never gets budgeted

It gets deferred, every year, by people who agree it matters. What gets funded is a project with a name and a number attached — the customer portal, the regulatory filing, the churn model. Any approach that requires a standalone platform budget before it returns anything is going to lose that argument, and should. So the catalog has to arrive as a side effect of work someone already agreed to pay for: register the four sources this quarter's project needs, ship the project, and keep the registrations.

Which makes evolution the actual requirement. Not a migration path — an amendment path. The U.S. Constitution is the useful model here: a small set of rules deep enough that the argument stays inside them, plus a defined way to change those rules so that revision is a procedure rather than a coup. Registering a new source, a new relationship, a new masking rule is an addition to a declarative config, not a re-modeling of everything already in it. A steward's explicit definition overrides a discovered one, so correcting the machine is an edit, not an escalation. Nothing about a wing you catalog in year three requires you to have anticipated it in year one.

Do that ten times and the museum has a card catalog — assembled by ten funded projects, none of which had to be a cataloging program.

Passive and active

What "active" has to mean

The word only earns its place if the layer does four things from one description, at the moment a query runs.

• It serves. The GraphQL schema, the SQL catalog, and the graph model are generated from the registration, not maintained beside it.
• It plans. Joins and traversals compile against registered relationships, so an illegal path isn't rejected later — it never compiles.
• It enforces. Six governance layers apply inside the plan: introspection filtering, public and domain access, row-level security, column masking, and a pre-execution predicate guard.
• It records. Every query is traced and compacted into queryable tables, so the audit trail is data you can join to the business data it describes.

Take any one of those away and you are back to a description plus a promise. The usual failure isn't a bad model; it's a good model that four systems interpret four different ways, and a governance rule that holds in the BI tool and not in the notebook.

Why it matters on the protocol level

A semantic layer reachable only through its own API governs only the traffic that chooses to use it. Provisa is reachable over pgwire, Bolt, Arrow Flight, gRPC, JDBC, REST, WebSocket, Airport, and MCP — and every one of those lands in the same compiler and the same six layers. An analyst on psql, a dashboard on JDBC, and an agent on MCP get the same answer under the same policy, because there is one path underneath all of them.

That is also the part that makes AI access tractable. An agent's OAuth token maps to a role, and the role is governed exactly as a person's would be. There is no second policy engine for agents to keep in sync, and no service account quietly holding wider rights than the human it answers for.

What it is not

An active semantic layer is not a metrics definition language. It is not data federation. It is not attribute-based access control. Those are three good categories with good products in them, and several of them deserve to exist on their own — we're not arguing anyone should stop building them.

They are also, each on their own, inert. A metric definition that the engine doesn't enforce is a document. Federation that doesn't know what the data means is a join. Access control that applies at one door is not access control. The expected value of all three only appears when they agree at one instant, and the instant is query execution.

The usual way to make them agree is an integration project — wire the metrics tool to the query engine, the query engine to the policy service, and maintain the seams forever. That is the part that never works, because each product releases on its own schedule and the seams are where the drift lives.

So the coordination here isn't integration, it's derivation. The published API, the legal join paths, and the policy all come out of one registration. There is no syncing because there are not three artifacts to sync. And the coordination point has to be the execution point: anything sitting beside the engine can only advise, and advisory governance is precisely the kind that gets routed around. Three vendors' products cannot compile into one query plan.

The other half of it is leverage. Today the coordination usually happens inside somebody's product — your metric definitions in their model, your join paths in their catalog, your policies in their engine — and whoever holds the coordination holds you, because leaving means re-deriving all three. When the coordinating artifact is a declarative config you own, none of the underlying products is the center of gravity. Each one goes back to being a component you can put out to bid. More on that here.

The claim, stated plainly

Plenty of products model your data. Plenty of engines execute queries. The category we're describing is the one where those are the same artifact — where the thing that describes your data is the thing that runs, governs, and audits every query against it, across three languages and nine protocols.

If you find another one, we'd like to know. That's not rhetoric: the comparison would sharpen the category, and the category is more useful to us than being alone in it.