The Gap Between What You Ask and What SQL Returns

Ask a colleague "how are sales doing this quarter?" and they understand immediately: the current quarter, compared to something meaningful, probably broken down by region or product, and almost certainly excluding returns. You didn't specify any of that. They inferred it from context, intent, and shared institutional knowledge.

Ask a database the same question and you get an error. Or worse — a number that is technically correct and completely wrong.

This is the semantic gap. And closing it is the central unsolved problem of enterprise AI.

"The question is not whether AI can generate SQL. It is whether AI understands what the question actually means."

Why Natural Language Is Fundamentally Ambiguous

Human language evolved for communication between agents with shared context. When you say "active customers," every person in a business meeting nods — because they share an implicit definition. Active might mean purchased in the last 90 days, or has a non-cancelled subscription, or logged in within 30 days. The shared context makes the ambiguity invisible.

A database has no shared context. It has a schema. And a schema is brutally literal. There is no column called active_customers that returns what your business means by active customers. There is a status column and a last_purchase_date column and a subscription_state column, and the definition of "active" lives in a Confluence page that was last updated in 2019 and is probably wrong.

This is why natural-language-to-SQL is not a translation problem. It is a disambiguation and context injection problem. Translation assumes the source and target are semantically equivalent. They are not. Natural language questions are underdetermined relative to the SQL required to answer them.

The Dimensions of Ambiguity

Enterprise questions fail at the database boundary in several distinct ways. Understanding each one is the first step toward closing the gap.

Entity ambiguity

The same business concept exists under different names in different systems. Customer in Oracle is client in Postgres, account in Salesforce, and party in the legacy mainframe. A system that cannot resolve these to the same underlying entity will answer different questions depending on which source it queries first.

Temporal ambiguity

"This quarter," "recently," "year to date," "last year" — all of these require the AI to know the current date, the fiscal calendar, and the timezone context. A question asked on March 31st means something completely different to a March 31st answer than one asked on April 1st. Fiscal year boundaries compound this further.

Scope ambiguity

Does "revenue" include returns? Refunds? Tax? Intercompany transactions? Pending orders? The correct answer is different in every organisation, and often different in the same organisation depending on who is asking and why.

Aggregation ambiguity

"Show me sales by region" — is that a sum? An average? A count? Does it want the top 10 regions, all regions, or regions above a threshold? The natural language question leaves all of this open. The SQL must resolve it to a single answer.

Natural language	What it seems to mean	What SQL requires
"Active customers"	Customers who are active	WHERE last_purchase_date > DATE_SUB(NOW(), INTERVAL 90 DAY) AND status != 'cancelled'
"Revenue this quarter"	Sales in the current quarter	SUM(amount) WHERE QUARTER(order_date) = QUARTER(NOW()) AND YEAR(order_date) = YEAR(NOW()) AND status = 'completed'
"Top products"	The best-selling products	ORDER BY SUM(units_sold) DESC LIMIT 10 — but which metric, which period, which channel?
"Compare last year"	Year-over-year change	Two subqueries, one for each year, joined on the same dimension, with a percentage change calculation

How Semantic Parsing Works

The first generation of text-to-SQL systems worked by training models on question-SQL pairs and hoping the model would generalise. They achieved impressive benchmark scores on controlled datasets and failed spectacularly in production, because production data schemas are nothing like benchmark schemas, and real user questions are nothing like benchmark questions.

Modern semantic parsing for enterprise databases takes a different approach. Rather than mapping question tokens directly to SQL tokens, it operates in two stages:

Stage one: intent extraction. Parse the question into a structured representation of intent — what entities are involved, what filters apply, what aggregation is requested, what time range is implied. This representation is schema-agnostic. It captures what the user wants, not how to get it.

Stage two: schema grounding. Map the intent representation onto the actual schema of the target database. This is where business logic lives — where the definition of "active" is looked up, where column aliases are resolved, where temporal expressions are converted to date ranges.

-- User asks: "Which regions had the highest revenue growth this quarter vs last?"

-- Stage 1: Intent extraction
-- intent: comparison
-- metric: revenue
-- dimension: region
-- period_a: current_quarter
-- period_b: prior_quarter
-- sort: metric_delta DESC

-- Stage 2: Schema-grounded SQL
WITH cq AS (
  SELECT region_id, SUM(net_revenue) AS rev
  FROM transactions
  WHERE QUARTER(txn_date) = QUARTER(NOW())
    AND YEAR(txn_date) = YEAR(NOW())
    AND status = 'completed'  -- resolved from glossary: "revenue" excludes pending
  GROUP BY region_id
),
pq AS ( /* same for prior quarter */ )
SELECT r.name, cq.rev - pq.rev AS growth
FROM cq JOIN pq ON cq.region_id = pq.region_id
JOIN regions r ON r.id = cq.region_id
ORDER BY growth DESC;

The Glossary Problem

The most underestimated component of semantic parsing for enterprise databases is the glossary — the mapping between business vocabulary and database reality. Without it, even a perfect LLM will generate technically valid SQL that answers the wrong question.

Building glossaries manually does not scale. An enterprise with 40 data sources has thousands of business terms, each with subtly different definitions depending on the department, the system, and the fiscal period in question.

Vertiscope AI builds glossaries automatically from three sources: schema metadata (column descriptions, documentation strings), historical query patterns (what SQL has previously been accepted as correct for a given question), and explicit user corrections (when a user flags a wrong result, the correction trains the glossary). Over time, the system learns the specific semantic conventions of each organisation — not the generic conventions of a training dataset.

Closing the Gap Is Not a One-Time Problem

The semantic gap is not a static engineering challenge. It is a moving target. Business definitions change. Schemas evolve. New data sources introduce new naming conventions. Regulatory requirements redefine what "revenue" means. Acquisitions merge two companies' data models into one incoherent mess.

A system that closes the gap today will re-open it tomorrow unless it has a mechanism for continuous alignment — learning from corrections, adapting to schema changes, and updating glossary mappings as business logic evolves.

This is why the learning loop is not a feature of enterprise semantic AI. It is the only mechanism that makes enterprise semantic AI viable in production over time. The gap does not stay closed on its own.

Part of the Vertiscope AI research series on semantic systems and enterprise query intelligence.