A Semantic Layer Is Necessary - But It Is Not Everything You Need

Omni Analytics has written the two best short arguments for the semantic layer you will find anywhere. The first article, Why Text-to-SQL Fails, diagnoses why text-to-SQL fails: silent wrong answers, metric misinterpretation, non-determinism, broken joins, no access control. The second article, Why AI Needs a Semantic Model, prescribes the cure: a governed semantic model that gives AI a shared vocabulary, pre-defined joins, and versioned metric definitions.

The diagnosis is right. We've seen all of those failure modes ourselves. Where we disagree is in the proposed solution. The articles imply that the semantic layer is the answer to the problem. We don't think it is.

A semantic layer matters, but it's only one part of a reliable architecture. If you treat it as the entire solution, you end up recreating many of the same problems at a higher level of abstraction.

That's why NL2SQL Pro takes a broader approach: retrieval-augmented generation to ground queries in real context, human-in-the-loop confirmation for sensitive workflows, graded trust instead of binary automation, and a deterministic curated fast path for high-confidence requests. Together, those pieces create a more dependable approach to natural-language-to-SQL than relying on a semantic layer alone.

What the semantic layer actually fixes, and what it quietly does not

Omni's strongest point comes in the second article: ask ten companies to define "revenue," and you'll probably get ten different answers. That's true. A semantic layer creates a single agreed-upon definition, and that is genuinely valuable. NL2SQL Pro agrees with that completely — it has a terms RAG collection and an ontology-driven agent for exactly this reason.

But there's an important distinction here: a semantic layer doesn't really resolve ambiguity. It pre-decides it.

Take the example from Omni's own first article. A user asks for "orders." Do they mean the number of orders, total order value, or shipped quantity? The article correctly points out that choosing the wrong interpretation is a serious failure. The semantic-layer approach is to decide, months in advance, that "orders" means one canonical thing. But the person building that model has no way of knowing what a specific user means in a specific moment. If the user actually meant total order value, but the semantic layer maps "orders" to order count, the system still returns a confident, believable, wrong answer, so the exact problem the first article warned about.

The mistake hasn't disappeared. It's just been moved upstream, from the LLM to the data modeler, and made less visible because now there's a "governed definition" behind it.

That's the core issue: a semantic layer creates consistency, but consistency is not the same as understanding intent. A system that always interprets "orders" as COUNT(O_ORDER_ID) is perfectly consistent — and still wrong a large percentage of the time.

NL2SQL Pro handles this differently. Before any SQL is generated, a dedicated AI agent runs a propose-and-critique process to detect ambiguous terms. On top of that, a deterministic detector flags high-risk business terms like "orders," "sales," "customers," and "products," even if the LLM misses them.

Instead of assuming meaning ahead of time, the system asks the user what they mean when ambiguity matters. That clarification is then carried directly into SQL generation. In other words, the disambiguation happens with the person who actually knows the intent, at the moment the question is asked — something a static semantic model can never fully do.

The semantic layer moves the hard problem, but it does not remove it

Here is the structural point the second article never confronts. A semantic layer does not let users query in English. It lets users, or an LLM, query the model instead of the schema. Something still has to translate "how much money are we making in the south last quarter" into a model query: the right metric, the right dimensions, the right filters, the right grain.

That translator is still an LLM doing fuzzy natural-language understanding, which is non-deterministic. You have not deleted the text-to-SQL problem, you have renamed it text-to-metric and pushed it up one layer. The schema got cleaner, the language did not. Every failure mode in the first article: wrong field, drifted metric, plausible-but-wrong, is still reachable, now against a curated model that the user trusts more precisely because it is "governed," which makes the silent failures more dangerous, than before.

A semantic layer narrows the space the NL2SQL translator can go wrong and that is genuinely useful, but it does not close it. Anyone who has watched a BI tool confidently pick the wrong pre-modeled measure knows this.

Determinism: consistent definitions are not consistent answers

The first article's point about non-determinism deserves a closer look, because the semantic-layer solution is not as strong as it initially sounds.

A semantic layer can standardize what "revenue" means. That's useful. But it does not guarantee that the same natural-language question will generate the same SQL every time.

An LLM can still interpret "top regions by revenue last year" in multiple ways — maybe one run groups by sales territory, another by country, another applies different filters or levels of aggregation. All of those queries may technically fit the semantic model and still produce different answers.

NL2SQL Pro approaches this problem differently.

When a user question closely matches a curated, human-validated query - at high similarity, the system skips the LLM entirely. Instead, it reuses the approved SQL and only swaps in user-confirmed parameters like dates or geography. The result is byte-for-byte identical SQL every time.

That's determinism by design, not by hoping the semantic model constrains the LLM enough.

And importantly, this only applies to the queries that matter most: the recurring business questions people ask every week. For those high-value queries, the LLM is removed from the critical path entirely.

There's another advantage too: the system improves through use. Every time a business analyst expert validates and saves a query, it becomes a new deterministic fast-path entry. Over time, the platform builds a growing library of trusted questions and answers, so consistency increases naturally as adoption grows.

The flywheel argument actually favors the retrieval approach

The second article's most compelling idea is the "context flywheel": user questions generate insight that feeds back into the model, which gets better over time. We agree completely with the principle. We disagree about which architecture has the better flywheel.

The semantic-layer flywheel has a human bottleneck: someone has to keep extending the model. Every new question the business invents is unanswerable until a modeler adds the metric, the dimension, the synonym. The model is permanently one step behind the questions - the same structural lag that made OLAP cubes and hand-maintained LookML painful. The flywheel only turns as fast as the modeling team.

NL2SQL Pro's flywheel turns on validated answers, not modeled definitions. A question the model never anticipated still gets answered through retrieval-augmented generation; if the answer is good, one click promotes it to a curated fast-path query; the next person asking it gets the deterministic, trusted result. The marginal cost of covering a new question is "validate one answer," not "extend the global model." Lower friction per increment means a faster-turning flywheel — which is exactly the property the second article says you want.

Trust without blind faith

The strongest point in the first article is really about trust and verification. A wrong answer that looks correct is incredibly dangerous, because most business users cannot read SQL well enough to verify it. The whole point of a natural-language system is supposed to be removing that burden in the first place.

The semantic-layer approach responds by saying: "You can trust the result because it's based on governed metrics and approved definitions."

But that still depends on trust. The user has to trust a model they did not build, often cannot inspect, and usually cannot verify in the moment they ask the question. In practice, it replaces "trust the LLM" with "trust the data modeler." The dependency on faith is still there - only the target of that trust has changed.

NL2SQL Pro takes a different approach. Instead of asking users for blind trust, it exposes uncertainty directly.

Every result comes with an explicit trust badge based on two independent signals: how closely the question matched known patterns, and whether the generated answer passed validation checks. The system also shows the actual SQL alongside a plain-language explanation of what the query is doing and what the result means.

So the user is never expected to trust an invisible layer somewhere upstream. On every answer, the system tells them how confident it is, and why.

Most importantly, failures are not silent. If confidence is low, ambiguity is detected, or validation does not pass cleanly, the user sees that immediately. That directly addresses the core problem the first article identified, believable wrong answers that appear authoritative without warning.

Where the semantic layer genuinely wins

This is not a claim that semantic layers are bad. They are the right tool for problems, including some that NL2SQL Pro does not fully solve yet:

• One metric definition across many tools. For example, if a company needs "revenue" to mean exactly the same thing everywhere: in Tableau dashboards, APIs, notebooks, and internal tools, a centralized semantic layer is probably the cleanest way to enforce that consistency. A per-application knowledge base is harder to manage at that scale.
• Enterprise governance and lineage. Semantic layers are also strong at enterprise governance. They provide versioned metric definitions, approval workflows, access controls, lineage tracking, and auditability in a way most AI-first systems do not yet match.
• Result-level sanity, not just SQL-level. NL2SQL Pro's validator today checks SQL structure and result plausibility as well.

Good architecture takes ideas from multiple approaches instead of treating any single component as the whole solution.

NL2SQL Pro already uses many semantic-layer concepts internally: ontology relationships, schema synonyms, business terms, and shared definitions. The difference is in how those components are used. In NL2SQL Pro, the semantic model is one source of context among several inputs the system retrieves and reasons over (see the next article on BI long-memory storage). It is not treated as a single mandatory control point that every query must pass through or every user must trust implicitly.

The architectural difference, stated plainly

The second Omni article says "data is precise, but AI isn't a precision instrument," and concludes you therefore need a semantic model between them. The first half is right. The conclusion is too narrow. The gap between precise data and imprecise language is not closed by one static structure - it is closed by a system: retrieve proven patterns instead of generating from scratch, confirm ambiguous intent with the human who owns it, validate before execution, reuse validated answers deterministically, and tell the user on every result how much to trust it.