Agents Need Interpretable Meaning: Semantic Layers, Ontologies and Governed Metrics

Picture the Monday standup. A teammate pastes the agent's reply into Slack: revenue per customer for the previous quarter, formatted neatly, explained briefly, delivered with total assurance. One look from finance and the room stalls. That figure is bookings, whereas recognized revenue is stored in another fact with a different grain and its own list of exclusions. Nothing was wrong with the SQL. Nobody had settled what the question meant.

After enough of these scenes, "the model produced valid SQL" stops counting as success. Large language models made nearly every warehouse artifact machine-readable. Readable is cheap. Interpretable is the scarce part: what customer, revenue, active, churn and last quarter mean in this particular company, for this particular decision.

Before agents, a person did that interpreting before writing any query. Delegate it to an agent at runtime and it will improvise a plausible story unless an engineered one is supplied. The one lasting fix is to manage enterprise meaning like a product: give it identity, version it, test it, map it to physical data, and let humans and software consume it identically.

For most teams the shippable step is a governed semantic or metrics layer. The longer destination is an ontology-led model that compiles the downstream projections, whether LookML, SQL views, API contracts or agent tools, so that no product has to invent a private truth.

Why a confident answer is the risk

Chat-based BI is often described as natural language to SQL, a label that hides the hard part. The hard bit is reading a question in one frame of reference and carrying its meaning into another.

Consider the question "What was revenue by customer last quarter?" Running a precise query is easy for a warehouse. The effort lies in choosing which query represents the question. Revenue could mean bookings, billings or recognized revenue. The customer could be the sold-to party, the bill-to party or whichever account-hierarchy node sales shows in its quarterly reviews. Last quarter could follow calendar months, the fiscal year or the rolling window that operations favors.

On a dashboard, an analyst has already made those calls. A tile labeled Revenue looks authoritative because the semantic decision is built into the artifact. Chat flips the order. The decision now happens at runtime, for arbitrary questions, inside software, which turns semantics from a wiki page into runtime infrastructure.

The uncomfortable consequence is that the better a model gets at plausible SQL, the more dangerous its misses become. Syntactic correctness says nothing about semantic validity. A polished explanation can answer the wrong question so smoothly that nobody notices until a board pack contradicts the chat log. Teams that only ask whether a query ran are training themselves to trust fluent wrongness.

Dimensional models already hold some meaning

None of this makes a warehouse a blank slate. Kimball-style dimensional modelling has spent decades compensating for how little general-purpose relational schemas say. Facts, dimensions, measures, grain, hierarchies and conformed dimensions all write business meaning into structures people can query.

A well-built star schema already works as an informal semantic layer. Today's semantic layers add more, adding metric definitions, calculation rules, terminology, permitted relationships and business rules that column names cannot reveal. A formal ontology goes further still, separating the conceptual model from its relational implementation and mapping between the two on purpose.

It is best seen as a continuum and not a conversion experience:

• operational relational schema
• dimensional model
• semantic layer
• formal ontology

Moving down the list writes more meaning down and asks the model to guess less. Every piece left implicit is a bet that inference will land on the definition the CFO would swear to.

What the research keeps showing

Recent text-to-SQL studies keep landing on one result. Spelling out business meaning raises accuracy, and this holds even for schemas that were already built for analysis.

In a test by Figueiredo and colleagues, GPT-4 Turbo was run over a star schema. The schema alone produced roughly 58% correct queries, and adding contextual semantics lifted that to about 89%. Rumiantsau and Fokeev added a short semantic document to an analytical warehouse modelled on Contoso, and accuracy climbed from roughly 48 to 52 percent into the high sixties. These gains count because the baselines were not messy transactional schemas.

When the physical schema says less about the business, the effect grows. Painter and colleagues worked on an operational database with more than 500 tables and raised validated SQL generation from about 8% to about 78% by supplying terminology, rules, relationships and mappings. Nascimento and colleagues watched execution accuracy on a complex industrial database rise from 41% to 65% simply by exposing business-oriented conceptual names, and to 74% once useful relationship semantics were explicit as well.

Formal models trend the same direction. In one study by Sequeda, Allemang and Jacob, asking questions directly of an enterprise relational database yielded about 17% accuracy, while routing through a knowledge graph backed by an ontology reached roughly 54%. A follow-up by Nascimento retained SQL over the relational store for execution, but first used a knowledge graph to connect business concepts to physical schema. Measured by schema-linking F1, an LLM alone scored about 0.85. The graph approach reached 0.90, graph plus LLM 0.93, and the complete semantic-linking pipeline with perfect recall 0.996.

The reasonable reading is architectural, not promotional: make the mapping from concepts to relational structures explicit, take semantic improvisation away from the model, and leave execution in the relational engine where it already works.

What the relational model did and did not do

Codd's relational model delivered data independence: applications should not depend on how data is physically stored. That achievement still matters.

Conversational BI demands something more specific and more difficult. A relational analytical schema does not by itself spell out every business meaning needed to answer a question. Names, keys, constraints and comments help, and dimensional models help more. Yet metric definitions, the roles terms play, temporal conventions, provenance and rules mapping concepts to physical objects still tend to live in people's heads or in slide decks.

That is why glossaries, metric stores, semantic layers and catalogues have grown up around warehouses. They gradually make explicit what an analyst, or an LLM, would otherwise improvise. A modern semantic layer is a practical answer at the point where BI is consumed. It remains narrower than a general conceptual model of the enterprise, and treating the two as identical is how teams end up surprised later.

Adding an ontology while keeping the warehouse

In informatics practice, an ontology describes what exists in the domain of interest, meaning entities, relationships and constraints, written so that software can use it. It shares an ancestry with the relational model in predicate logic: statements about things and the relations among them.

Databases have long worked on this. W3C Direct Mapping and R2RML define how relational data becomes RDF vocabularies. Ontology-Based Data Access takes the idea further: a user queries the conceptual model and the system translates that into SQL against the sources already in place. Ontop, a mature open-source virtual knowledge graph, does precisely that with R2RML mappings and lightweight OWL 2 QL ontologies.

The choice of OWL 2 QL has an unglamorous but useful rationale. It belongs to the DL-Lite family, whose limits are intentional so that queries mediated by the ontology remain tractable against large relational databases. Expressive power was given up in exchange for rewritability into SQL. Work on ontologies for warehouses and multidimensional models predates this as well, representing dimensions, measures and hierarchies and deriving analytical structures from conceptual models.

What still has little visible adoption is an ontology language aimed squarely at modern BI, one that holds business entities, relationships, measures, grain, aggregation, time, provenance and warehouse mappings in a single governed model.

Adopting this does not mean moving the warehouse into a graph database. Meaning can be described in the ontology while the facts remain in relational tables and the calculations remain in SQL. Materializing a graph is optional, useful for workloads that gain from it, and is no litmus test.

Stored facts and what they mean

Rows and RDF triples are more closely related than the tool wars suggest. A row states that a tuple belongs to a named relation, and a triple splits a proposition into subject, predicate and object. Strong normalization already steers relational designs toward smaller facts. The two are not formally equivalent, yet the resemblance is helpful.

For agents, the distinction that matters is not table versus graph. It is extensional data versus intensional meaning: the facts that are stored versus the rules about what those facts mean. An ontology can state that one class subsumes another, that two predicates are inverses, that a relationship is transitive, or that a particular combination is impossible. OWL provides formal semantics for such statements, SHACL validates graph shapes, and richer logic frameworks exist for when they are needed.

Not every ontology rewrites neatly into SQL, because some languages are more expressive than the efficient rewrite fragments can handle. OBDA research confronts this openly, with options to limit expressiveness, approximate, materialize or reason in a separate step. The constraint is useful, since it forces an explicit account of which semantics hold on the execution path, which are compiled ahead of time, and which fall outside the chosen profile. Few enterprises record any of this loss today, so it seeps out as quarrels in chat channels.

A vendor's context is not your ontology

Vendors are already moving. Google Cloud is a handy case, because several of its 2026 releases target enterprise context that machines can use. Dataplex Universal Catalog was recast as Knowledge Catalog and behaves more like a live context graph than a static registry. It offers semantic search, enriched descriptions, relationship graphs, verified (golden) SQL patterns, context APIs and access paths for agents. Meanwhile Looker's Open SQL Interface allows JDBC clients to query LookML models as though they were schemas, reusing the dimensions, aggregates, calculations and relationships already defined there.

Such releases back up a basic point: an agent needs more than row access. It needs curated context, semantic models, relationships, verified examples and governed interfaces.

Even so, they fall short of a single coherent enterprise ontology. LookML semantics, catalogue terms, BigQuery graph definitions and context written by agents are related yet distinct representations. Unless the organization holds the canonical identifiers and explicit mappings across them, the promise to define once degrades into defining once per product.

Whole quarters have been lost to that trap. A vendor's context graph can be very valuable without serving as the formal source of semantic truth. Adopt it freely, while remembering that adopting is not owning.

Six design principles

The rule that sits above all the others is that meaning must be readable by humans and machines at once, and stay consistent across representations.

Give meaning an identity. Every concept, relationship, metric, policy and quality assertion should carry a stable identifier. A name is only a label, while an identifier is what makes the object itself. The term customer shows up in dashboards, APIs, warehouse tables and agent prompts, and all of those should point to one semantic object, or knowingly to separate ones if the business really holds separate concepts. Support and finance may define active customer differently, provided they never share an ID without saying so.

Make definitions executable. Prose serves people and models, but anything that influences computation needs structure: types, relationships, cardinalities, units, formulas, grain, valid time, constraints, mapping rules and policy. A descriptive paragraph in a catalogue is largely a human convention.

On stacks built around Google Cloud, one workable allocation is as follows. Knowledge Catalog carries identity, definitions, units, ownership, valid time, policy, relationships and mappings. LookML carries the executable formula, dimensions, joins and query generation. Conversational Analytics interprets natural language against that context, with verified queries serving as regression anchors. The arrangement only holds if IDs deliberately cross each of those boundaries.

Map semantics to physical data explicitly. Suppose the ontology states that a Customer owns an Account. The implementation must then name the relation or derivation that makes the statement true, and the mapping should be versioned together with both of its ends. No one-click tool projects OWL into every catalogue product. Somebody has to build and maintain the bridge, otherwise the word semantic means little more than branding.

Treat relationships as first-class. A Role gains meaning from its connections to processes, organizations, activities, capabilities and costs, not from a column named role_type. Customer, product, contract, account and metric work the same way. Loose naming and prose already help NL-to-SQL, but formal relationship semantics are what separate relational convenience from ontological clarity. Authoring them costs real effort, and an ontology that ignores that cost dies during its pilot.

Keep metrics inside the same model. Dimensional measures already hold identity, formula, grain and aggregation behavior, and semantic layers make more of this executable. The wider meaning, including ownership, units, exclusions, provenance, policy, effective dates and ties to enterprise concepts, tends to wander off into other systems. Fragmentation is frequently the real architectural problem: a dimensional measure, a LookML measure and a catalogue term each describe an overlapping piece of one business idea, under three separate identities.

Compile once, serve many ways. One canonical model should generate or govern its projections, such as LookML, SQL views, API schemas, catalogue entries, graph shapes, tool contracts for agents, documentation and validation tests. Platforms can keep their own syntax, but meaning should not be theirs to invent.

LinkML demonstrates that a model independent of technology can emit SQL DDL, BigQuery DDL, JSON Schema, OpenAPI, OWL, SHACL, documentation and validators. What it cannot do is choose facts, dimensions, measures, grain or conformed dimensions on anyone's behalf. Research on turning ontologies into star schemas exists, but no mainstream chain runs the whole way from canonical ontology through a governed dimensional warehouse and an executable semantic model to ontology-grounded NL-to-SQL. That missing pipeline is where the engineering challenge sits, and emitting DDL is merely the easy demonstration.

Two routes and the need to converge

Most enterprises cannot pause the warehouse program and rebuild around an ontology first. That is fine. The task is to get the agent resolving meaning reliably with what can be shipped, and to design the tactical path so it can graduate.

Under Plan A, a canonical enterprise ontology holds semantic authority, with stable identifiers and explicit logical semantics. Physical data does not move, and the ontology maps to relational and other representations. Analytics metrics become compiled projections. Agents pull formal concepts, relations, policy and provenance, and changes are versioned and released the way code is. Representations inside products are generated from, or mapped to, semantics the enterprise owns.

Plan B begins nearer the ground already occupied: a governed metrics layer paired with a catalogue and context model, to which stable canonical IDs are added on purpose. The warehouse stays authoritative, and the mapping from semantic objects to tables, columns, joins and filters gets written down. Agents pick certified fields and metrics instead of raw tables, drawing context from context services, verified queries and retrieval that respects permissions. Metrics, mappings, golden questions and semantic regression tests join the CI/CD pipeline. IDs local to a product never turn into enterprise identity, and crosswalks keep migration possible.

A concrete Plan B on Google Cloud pairs Knowledge Catalog for context and discovery with Looker where a governed semantic model suits, restricts conversational analytics to certified semantic objects, keeps verified queries as regression anchors, and holds enterprise identifiers outside any one product. Knowledge Catalog is ontology-like only in a narrow sense, offering typed context and relationships for agents without being a complete formal ontology system. Treat it as fabric and not as scripture.

The risk is a tactical semantic layer whose identifiers and logic can never be lifted into a more formal model. A Plan B that cannot converge is a dead end decorated with dashboards.

Resolve first, then touch tables

A sound conversational BI path should not begin with table selection. It should begin with semantic resolution.

Take the question "Has churn increased among high-value retail customers this quarter?" Churn, high-value retail customer and this quarter should resolve to governed objects before anything else. Those objects hold the metric definition, classification, time convention, allowed dimensions, source mappings and policy. Only after that should an execution layer write the physical query.

The loop teams should be able to recite runs in eight steps:

1. Question and user context
2. Semantic resolution to governed concepts and metrics
3. Context retrieval filtered by policy and permissions
4. Mapping from semantic objects to physical data
5. Query or tool-plan generation
6. Execution and reconciliation
7. An answer backed by evidence and provenance
8. Semantic regression or evaluation, plus governed action where it applies

The mindset is far from pasting the analytical schema into the prompt and hoping. The LLM can still clarify intent and assemble a plan, but it works over governed semantic objects and tool contracts, not by decoding the CFO's vocabulary from a table named fct_rev_v3.

Verified queries are valuable as tests and examples, but they are not the semantics. They only prove that one question resolved to an accepted implementation at one moment. The meaning underneath still needs its own identity and definition.

What does not count as a semantic architecture

A catalogue full of prose descriptions supports discovery. It is not an executable semantic system.

Pointing agents at raw warehouse schemas by default and calling that self-service BI only shifts semantic risk onto a probabilistic model.

Duplicating every warehouse fact into a knowledge graph "for AI", without a clear execution payoff, produces a second enterprise truth that lags behind through sync delay.

Splitting metrics from the ontology so completely that a single business concept ends up with clashing identities in BI and in knowledge models sets up fights for later.

Confusing a representation with semantics, for example by assuming a graph is inherently more semantic than a dimensional model, is cargo cult thinking. Dimensional models, semantic layers, knowledge graphs and ontologies each encode meaning to varying degrees, and picking a graph does not add meaning on its own.

Treating metadata or relationships produced by AI as fact, with no provenance or review status attached, is how plausible fiction hardens into policy.

The goal in one line

People would like to ask for last month's numbers as casually as they ask about the weather. That is no longer fantasy. Software is being given the semantic work that analysts and engineers once did unnoticed, and getting consistent answers means making that work explicit.

Neither an LLM bolted onto a warehouse nor a catalogue combined with vector search is the endpoint. It is a governed semantic system in which concepts, relationships, metrics, constraints, policy, quality and provenance all keep one meaning to people and to machines, tied by formal mappings to the data beneath.

Much of the underlying data is still best executed in relational and SQL analytical engines, and semantic or ontology technology is not there to displace them. Its job is to finish the model at a level that a relational schema was never built to hold by itself, even once dimensional modelling and careful naming have taken it as far as they can.

When writing and maintaining a full analytics ontology is not yet realistic, ship a governed semantic layer, but keep the heading fixed. Semantics should migrate upstream, out of dashboards and prompts and into a first-class enterprise model, with each product's own layer treated as a compiled view.

The goal is not a single database, tool or syntax. It is a single meaning that a person, a dashboard, an application and an AI agent all read the same way. If the four disagree, the issue is not the LLM. It is an identity problem that was deferred.