Schema-Aware Localisation (SAL): Live Schema Grounding and Hallucination Validation for Oracle NL2SQL

# Schema-Aware Localisation (SAL): Live Schema Grounding and Hallucination Validation for Oracle NL2SQL
Source: [https://arxiv.org/html/2607.22572](https://arxiv.org/html/2607.22572)
Divya Chukkapalli222Senior Member, IEEE\.[divya\.95j@gmail\.com](https://arxiv.org/html/2607.22572v1/mailto:[email protected])Ganesh R\. Naik333Senior Member, IEEE\.[ganesh\.naik@torrens\.edu\.au](https://arxiv.org/html/2607.22572v1/mailto:[email protected])Independent Researcher, Raleigh, NC 27601, USAIndependent Researcher, Apex, NC 27502, USATorrens University Australia, Adelaide, SA, Australia

###### Abstract

Large language models can generate fluent SQL from natural language, but on real enterprise Oracle databases they frequently fail at execution time: columns and aliases are hallucinated and dialect\-specific syntax is missed, leading toORA\-00904invalid\-identifier errors\. In this setting, failures are primarily due to missing schema grounding: the model cannot know which tables and columns actually exist\.

This paper introducesSchema\-Aware Localisation \(SAL\), a lightweight middleware layer for Oracle NL2SQL that requires no model retraining\. SAL queries Oracle’sUSER\_TAB\_COLUMNScatalog to build a live schema map, selects a relevant table subset for each question \(falling back to the full schema for multi\-table queries\), and injects this ground\-truth context into the LLM prompt\. Generated SQL is then checked by the Hallucination Index \(Hidx\), which validates everyalias\.columnreference against the live catalog, automatically rewrites predictable prefix errors, and otherwise triggers a structured retry with itemised corrections\.

We evaluate SAL on 500 TPC\-H natural language questions executed against a live Oracle Autonomous Database 23c instance using GPT\-4o\-mini\. Without any schema grounding, execution\-grounded truth \(EGT; executes and matches the reference result set\) is 2\.2% \(12/500\)\. A hand\-written static schema hint brings EGT to 62\.0%\. SAL, with no manual schema curation, achieves62\.6% EGT\(96% simple, 95% medium, 40\.7% complex\) while reducing execution failures from 97\.6% to 2\.6%\.

###### keywords:

NL2SQL , Oracle Database , execution\-guided verification , schema grounding , hallucination mitigation , reproducible evaluation , retrieval\-augmented generation

## 1Introduction

Databases do not speak English\. For decades, this has been the quiet tax on enterprise analytics: a business analyst with a sharp question must wait for a database engineer to translate it into SQL, or learn the query language themselves\. Large language models \(LLMs\) appeared to change this\. Systems like GPT\-4o\-mini can produce syntactically fluent SQL from plain English questions in under a second, and on curated benchmarks such as Spider\[[34](https://arxiv.org/html/2607.22572#bib.bib13)\]they achieve accuracy figures above 80%\.

The gap between benchmark performance and production reality, however, is stark\. Spider queries run against clean, well\-documented schemas with standard column names\. Enterprise Oracle databases do not look like Spider\. They carry decades of naming conventions: columns prefixed with table initials \(O\_ORDERDATE,L\_SHIPDATE,C\_CUSTKEY\), constraints enforced at the dialect level \(FETCH FIRSTinstead ofLIMIT, noEXTRACT\(QUARTER\)\), and internal catalog structures that no LLM has seen during training\. When a model is asked to query such a database without being told what columns exist, it guesses, and Oracle does not forgive guesses\. The result is a wall ofORA\-00904: invalid identifiererrors\.

Our own measurements confirm how severe this problem is\. In a controlled experiment over 500 natural language questions on a live Oracle Autonomous Database instance, GPT\-4o\-mini with no schema context achieved just2\.2%execution\-grounded truth \(EGT\), our primary accuracy metric: the fraction of questions for which the generated SQL both executes and returns the correct result on the live database\. Only 12 of 500 queries executed and returned correct results\. The remaining 488 failed at the Oracle execution layer, not because the model reasoned poorly, but because it had no way to know which columns existed\.

This is primarily a grounding problem in this setting, and it has a practical solution that does not require retraining\. Oracle exposes schema metadata through data dictionary views such asUSER\_TAB\_COLUMNS\. If that metadata is fetched at runtime and injected into the LLM prompt, the model gains the ground truth it was missing\. A hand\-crafted static hint built from this metadata raisesEGT to 62\.0%in our experiments, a gain of nearly 60 percentage points from a few lines of prompt engineering\.

The challenge, then, is automating and hardening this grounding so that it works across heterogeneous Oracle deployments \(with evolving naming conventions, privileges, and dialect constraints\) and across the question types encountered in practice, without a human writing and maintaining the hint\. This is the problem SAL addresses\.

SAL differs from generic “schema\-in\-the\-prompt” approaches in three ways\. First, it targets Oracle\-specific production failure modes \(dialect features and identifier conventions\) and grounds against the live data dictionary at runtime rather than a manually curated schema string\. Second, it couples selective schema retrieval with a complexity\-gated fallback to avoid under\-scoping multi\-table questions\. Third, it enforces schema validity with an execution\-facing validator \(Hidx\) that can rewrite predictable identifier prefix errors and otherwise drives structured retries with itemised corrections\.

### Contributions

This paper presentsSchema\-Aware Localisation \(SAL\), a zero\-retraining runtime grounding framework for Oracle NL2SQL, implemented as an open\-source Model Context Protocol \(MCP\)\[[1](https://arxiv.org/html/2607.22572#bib.bib38)\]server\. The specific contributions are:

1. 1\.Live schema injection\.SAL queriesUSER\_TAB\_COLUMNSat server startup and maintains an in\-memory cache mapping every table to its exact ordered column list\. This cache is refreshed per deployment and requires no manual maintenance\.
2. 2\.Complexity\-gated table detection \(SAL Detect v2\)\.Rather than binary keyword matching, SAL v2 scores each table by the number of keyword hits in the question, expands the matched set along known JOIN\-chain edges \(e\.g\., matchingOrdersalso includesCustomerandLineitem\), and falls back to the full schema when the question contains multi\-table complexity signals and fewer than three tables match directly\. This prevents the “narrow hint” failure mode in which JOIN\-partner tables are silently dropped\.
3. 3\.Hallucination Index \(Hidx\) validator\.To reduce Oracle execution failures and enforce schema\-valid SQL under live schemas, Hidx parses each generated statement, builds an alias\-to\-table map fromFROM/JOINclauses, and checks everyalias\.columnreference against the live schema cache\. References that follow a predictable prefix pattern \(e\.g\.,O\.ORDERDATEinstead ofO\.O\_ORDERDATE\) are rewritten automatically\. Others trigger a structured retry in which the LLM receives an itemised list of its invalid references and the correct alternatives\.
4. 4\.Empirical ablation over Oracle ADB\.We evaluate four conditions \(no hint, static hint, SAL v1, and SAL v2\) on 500 TPC\-H questions across three complexity tiers, executed against a live Oracle 23c instance\. SAL v2 achieves62\.6% EGT\(execution\-grounded truth; correct result on the live database\), matching the hand\-crafted static baseline and reducing execution failures from 97\.6% to 2\.6%, with no manual schema work\.

## 2Related Work

The literature relevant to this work spans four areas: natural language interfaces to databases, schema linking, hallucination detection in generative models, and tool\-augmented language model architectures\. We survey each in turn and position SAL with respect to prior art\.

### 2\.1Natural Language Interfaces to Databases

The problem of translating natural language questions into structured database queries has been studied since the 1970s, beginning with rule\-based systems such as LUNAR\[[29](https://arxiv.org/html/2607.22572#bib.bib10)\]and LADDER\[[10](https://arxiv.org/html/2607.22572#bib.bib11)\]\. Modern interest re\-accelerated with the introduction of large\-scale annotated benchmarks\. WikiSQL\[[35](https://arxiv.org/html/2607.22572#bib.bib12)\]provided 80,654 question–SQL pairs over single\-table schemas and enabled systematic comparison of neural approaches\. Spider\[[34](https://arxiv.org/html/2607.22572#bib.bib13)\]extended the evaluation to 200 databases across 138 domains with complex, cross\-table queries requiring joins, subqueries, and aggregations\. BIRD\[[14](https://arxiv.org/html/2607.22572#bib.bib14)\]further raised the bar by introducing realistic database noise and evidence\-grounded questions\. These benchmarks collectively define common evaluation conventions, including execution\-based accuracy and string\-level exact\-match\. In this work we focus on execution\-grounded truth \(EGT\), i\.e\., the fraction of questions for which the generated SQL both executes and returns the correct result on the live database, and we additionally report a semantic\-match count for diagnostic purposes\.

Early deep learning approaches encoded questions and schemas with sequence\-to\-sequence models\[[35](https://arxiv.org/html/2607.22572#bib.bib12),[6](https://arxiv.org/html/2607.22572#bib.bib15),[30](https://arxiv.org/html/2607.22572#bib.bib16)\], decoding SQL tokens autoregressively\. TypeSQL\[[32](https://arxiv.org/html/2607.22572#bib.bib17)\]incorporated type information from schema metadata to improve column recognition\. ShadowGNN\[[4](https://arxiv.org/html/2607.22572#bib.bib18)\]and IGSQL\[[2](https://arxiv.org/html/2607.22572#bib.bib19)\]extended these ideas to multi\-turn conversational settings where schema context must persist across dialogue turns\.

The dominant paradigm shifted to large pre\-trained transformers following the success of BERT\[[5](https://arxiv.org/html/2607.22572#bib.bib20)\]and T5\[[23](https://arxiv.org/html/2607.22572#bib.bib21)\]\. BRIDGE\[[15](https://arxiv.org/html/2607.22572#bib.bib22)\]serialised schema information directly into the input and used BERT representations to align question tokens with database entities\. GRAPPA\[[33](https://arxiv.org/html/2607.22572#bib.bib23)\]pre\-trained a language model specifically on SQL\-grounded corpora to improve schema understanding\. These approaches consistently outperformed their predecessors on Spider but remain dependent on schema representations fixed at training time\.

With the emergence of instruction\-tuned LLMs, few\-shot prompting became the dominant approach\. DAIL\-SQL\[[8](https://arxiv.org/html/2607.22572#bib.bib24)\]selects question\-similar examples from a curated pool via masked question similarity and achieves 86\.6% execution accuracy on Spider using GPT\-4\. DIN\-SQL\[[22](https://arxiv.org/html/2607.22572#bib.bib25)\]decomposes the problem into schema linking, query classification, query generation, and self\-correction sub\-tasks, reaching 85\.3% on Spider with GPT\-4\. C3\-SQL\[[7](https://arxiv.org/html/2607.22572#bib.bib26)\]improves robustness through consistency voting across multiple independently generated candidates\.

A limitation of many of the above systems in enterprise settings is that they assume a clean, well\-documented schema is readily available and stable at inference time\. Far fewer works explicitly study the case where schema metadata must be retrieved live from a proprietary database catalog and where identifier conventions in the target database deviate sharply from the training distribution\.

### 2\.2Schema Linking

Schema linking, the sub\-task of identifying which tables and columns a natural language question refers to before SQL generation, is widely recognised as the primary bottleneck in NL2SQL accuracy\[[26](https://arxiv.org/html/2607.22572#bib.bib27),[12](https://arxiv.org/html/2607.22572#bib.bib28),[3](https://arxiv.org/html/2607.22572#bib.bib29)\]\. Errors in schema linking propagate irreversibly into the generated query\.

IRNet\[[9](https://arxiv.org/html/2607.22572#bib.bib30)\]introduced a concept vocabulary that maps question spans to schema elements via string similarity and word\-overlap heuristics\. RAT\-SQL\[[26](https://arxiv.org/html/2607.22572#bib.bib27)\]replaced heuristic linking with a relation\-aware transformer that jointly encodes question tokens and schema entities in a unified graph, learning link weights from annotated examples\. LGESQL\[[3](https://arxiv.org/html/2607.22572#bib.bib29)\]further refined this with line\-graph\-enhanced schema encoding that captures both local and global schema structure\.

These methods learn schema linking from thousands of annotated question–schema pairs\. They generalise within the distribution of their training schemas but degrade when column names follow enterprise conventions not present in Spider or WikiSQL, such as the TPC\-H prefix pattern \(O\_ORDERDATE,L\_SHIPDATE\) or Oracle\-internal naming of system objects\.

SAL takes an orthogonal approach: rather than learning to link question tokens to a static schema vocabulary, it retrieves the canonical schema at runtime from the database’s own system catalog \(USER\_TAB\_COLUMNS\) and injects it as grounding context into the LLM prompt\. This requires no annotated examples, no fine\-tuning, and no advance knowledge of the target schema, only a live database connection with read access to the relevant data dictionary views\.

### 2\.3Hallucination Detection and Correction in Generative Models

Hallucination, the generation of plausible but factually incorrect content, is a well\-documented failure mode of generative language models\[[18](https://arxiv.org/html/2607.22572#bib.bib31),[11](https://arxiv.org/html/2607.22572#bib.bib32)\]\. In natural language generation, hallucinations are difficult to detect automatically because they require external fact verification\. In code and SQL generation, however, hallucinations are directly and cheaply detectable: the runtime environment \(compiler, interpreter, or database engine\) raises an error\.

Liu et al\.\[[16](https://arxiv.org/html/2607.22572#bib.bib33)\]evaluate LLM\-generated code on 728 programming problems and find that GPT\-4 produces incorrect code in 37% of cases despite generating syntactically valid programs\. For SQL specifically, Ni et al\.\[[19](https://arxiv.org/html/2607.22572#bib.bib34)\]study execution\-guided decoding strategies that use database feedback to constrain SQL generation, reducing execution errors\. Pourreza and Rafiei\[[22](https://arxiv.org/html/2607.22572#bib.bib25)\]incorporate a self\-correction step in DIN\-SQL where the LLM is shown its own Oracle error output and asked to revise; this reduces failures but does not identify the specific erroneous token\.

Our Hallucination Index \(Hidx\) advances beyond execution\-guided and self\-correction approaches in three ways\. First, it operates*pre\-execution*: errors are detected by static analysis of the generated SQL against the live schema cache, avoiding an unnecessary round trip to the database\. Second, it is*token\-precise*: Hidx identifies the exactalias\.columnreference that is invalid and the table it is mapped to, rather than relying on a generic runtime error message\. Third, it distinguishes*auto\-correctable*errors \(those matching a predictable alias\-prefix pattern such asO\.ORDERDATEforO\.O\_ORDERDATE\) from errors that require LLM re\-prompting, saving API calls for the former class\.

### 2\.4Oracle SQL and Enterprise Database Deployment

The overwhelming majority of NL2SQL research targets open\-source SQL dialects \(SQLite, PostgreSQL, and MySQL\) under controlled benchmark conditions\. Oracle SQL introduces a qualitatively different set of challenges\.

Oracle enforces strict identifier scoping: a column referenced asalias\.COLUMNmust match the column identifier as stored inUSER\_TAB\_COLUMNS\(typically uppercased unless quoted\)\. The TPC\-H schema, in its Oracle instantiation, uses table\-prefixed column names \(O\_ORDERKEY,L\_SHIPDATE,C\_CUSTKEY\) that do not appear in any NL2SQL training corpus\. Common LLM outputs such asO\.ORDERDATEorO\.ORDER\_DATEproduceORA\-00904: invalid identifierat runtime regardless of semantic correctness\. Oracle also prohibitsLIMIT\(requiringFETCH FIRST n ROWS ONLY\), lacksEXTRACT\(QUARTER\), and handles analytic window functions under different syntactic constraints than PostgreSQL\[[21](https://arxiv.org/html/2607.22572#bib.bib40)\]\.

We are not aware of a public NL2SQL benchmark or ablation study that makes Oracle dialect correctness and live\-catalog grounding first\-class measurement dimensions on a live Oracle Autonomous Database instance\. The closest related work is on enterprise SQL assistance tools such as Oracle APEX AI\[[20](https://arxiv.org/html/2607.22572#bib.bib39)\]and commercial text\-to\-SQL products, which provide LLM\-powered query generation but generally do not publish rigorous accuracy ablations against live Oracle instances or quantify the contribution of schema grounding to execution correctness\.

### 2\.5Tool\-Augmented Language Models and Model Context Protocol

Tool\-augmented LLMs, systems that invoke external APIs, retrieve documents, or execute programs during inference, have demonstrated that grounding LLM outputs in retrieved evidence substantially reduces hallucination and improves factual accuracy\[[24](https://arxiv.org/html/2607.22572#bib.bib35),[31](https://arxiv.org/html/2607.22572#bib.bib36),[13](https://arxiv.org/html/2607.22572#bib.bib37)\]\. Retrieval\-Augmented Generation \(RAG\)\[[13](https://arxiv.org/html/2607.22572#bib.bib37)\]retrieves relevant passages from a document corpus and prepends them to the LLM input; the retrieved text serves as an authoritative reference that constrains generation\. SAL applies this principle specifically to the database schema domain, where the retrieved evidence \(column metadata fromUSER\_TAB\_COLUMNS\) is uniquely authoritative, machine\-readable, and verifiable, enabling automated post\-hoc validation that document\-based RAG cannot support\.

The Model Context Protocol \(MCP\)\[[1](https://arxiv.org/html/2607.22572#bib.bib38)\]is an emerging open standard that defines a structured HTTP interface for exposing tools and data sources to LLMs\. MCP provides a uniform integration layer analogous to what USB provides for peripheral devices\. SAL is implemented as an MCP server, enabling it to be deployed alongside any MCP\-compatible LLM client, including IDE assistants, chatbots, or business intelligence tools, without application\-level code changes\. This separates the grounding and validation logic from the consumer application and allows a single SAL instance to serve multiple clients concurrently\.

### 2\.6Research Gap and Positioning

Table[1](https://arxiv.org/html/2607.22572#S2.T1)summarises the key dimensions on which SAL differs from prior work\.

Table 1:Comparison of NL2SQL systems on enterprise Oracle deployment dimensions\.The research gap is specific: no existing NL2SQL system combines \(i\) live catalog\-driven schema injection, \(ii\) pre\-execution column\-reference validation, \(iii\) Oracle dialect awareness, and \(iv\) zero\-retraining deployment in a single framework\. Commercial tools address \(iv\) but not \(i\)–\(iii\); academic systems address \(iv\) but not \(i\)–\(iii\); and Oracle\-specific tooling exists but publishes no rigorous accuracy evaluation\. SAL is, to our knowledge, the first system to address all four simultaneously, and this paper provides the first published ablation quantifying the accuracy contribution of each component on a live Oracle Autonomous Database instance\.

## 3Background and Definitions

This section establishes the formal definitions and background concepts referenced throughout the paper\. Readers familiar with NL2SQL evaluation and Oracle database administration may proceed directly to Section[4](https://arxiv.org/html/2607.22572#S4)\.

### 3\.1Oracle SQL Dialect

Oracle Database enforces a number of syntactic and semantic constraints that differ from the ANSI SQL standard and from the PostgreSQL and SQLite dialects dominant in NL2SQL benchmarks\. The following are particularly relevant to this work\.

###### Definition 1\(Oracle Row Limiting\)\.

Oracle does not support theLIMITclause\. Row limiting is expressed using theFETCH FIRSTsyntax introduced in Oracle 12c:

```
SELECT ... FROM ... ORDER BY ...
FETCH FIRST n ROWS ONLY;
```

Alternatively, the legacyROWNUMpseudo\-column may be used in a subquery filter, but this does not compose correctly withORDER BY\.

###### Definition 2\(Oracle Column Identifier Scoping\)\.

In Oracle, a column reference of the formalias\.columnis resolved by an exact, case\-insensitive match against the column names stored inUSER\_TAB\_COLUMNS\.COLUMN\_NAME\. IfCOLUMNdoes not appear in that view for the table bound toalias, Oracle raisesORA\-00904: "alias"\."COLUMN": invalid identifier\. There is no fuzzy matching or partial\-name resolution\.

###### Definition 3\(TPC\-H Column Prefix Convention\)\.

The TPC\-H benchmark schema\[[25](https://arxiv.org/html/2607.22572#bib.bib8)\]names all columns with a two\-letter table prefix followed by an underscore\. For example, theOrderstable usesO\_ORDERKEY,O\_CUSTKEY,O\_ORDERSTATUS,O\_TOTALPRICE,O\_ORDERDATE, and so forth\. A language model that generatesO\.ORDERDATE\(omitting the prefix\) produces a statement that is syntactically valid but execution\-invalid under Oracle’s strict identifier resolution\.

### 3\.2Schema Hallucination in LLM\-Generated SQL

###### Definition 4\(Schema Hallucination\)\.

A generated SQL statementSScontains a*schema hallucination*if it references a table name, column name, or function name that does not exist in the target database schema𝒮\\mathcal\{S\}or is unsupported by the target SQL dialect\. Formally,SSis hallucination\-free if and only if:

∀\(t,c\)∈refs​\(S\):t∈\{ti\}∧c∈Ci\\displaystyle\\forall\\;\(t,c\)\\in\\text\{refs\}\(S\):t\\in\\\{t\_\{i\}\\\}\\;\\wedge\\;c\\in C\_\{i\}\(1\)whererefs​\(S\)\\text\{refs\}\(S\)is the set of all\(table, column\)pairs referenced inSS\(via aliases or directly\)\.

Schema hallucinations are the dominant failure mode in our experiments: without schema grounding, 97\.6% of GPT\-4o\-mini queries fail the condition in \([1](https://arxiv.org/html/2607.22572#S3.E1)\) and raiseORA\-00904at runtime\.

###### Definition 5\(Hallucination Index \(Hidx\)\)\.

The Hallucination Index of a SQL statementSSwith respect to the live schema cache𝒞\\mathcal\{C\}is defined as:

Hidx​\(S,𝒞\)=\|\{\(a,c\)∈arefs​\(S\):c∉Cα​\(S\)​\(a\)\}\|\|arefs​\(S\)\|\\text\{Hidx\}\(S,\\mathcal\{C\}\)=\\frac\{\|\\\{\(a,c\)\\in\\text\{arefs\}\(S\):c\\notin C\_\{\\alpha\(S\)\(a\)\}\\\}\|\}\{\|\\text\{arefs\}\(S\)\|\}\(2\)wherearefs​\(S\)\\text\{arefs\}\(S\)is the set of uniquealias\.columnreferences inSS,α​\(S\)​\(a\)\\alpha\(S\)\(a\)maps aliasaato its table via theFROM/JOINclause inSS, andCα​\(S\)​\(a\)C\_\{\\alpha\(S\)\(a\)\}is the ordered column list of that table from the live schema cache\.Hidx​\(S,𝒞\)=0\\text\{Hidx\}\(S,\\mathcal\{C\}\)=0indicates a hallucination\-free statement\.

### 3\.3Schema Grounding

###### Definition 6\(Schema Grounding\)\.

Schema grounding is the process of augmenting an LLM prompt with database\-specific metadata \(table names, column names, data types, and relational constraints\) prior to SQL generation\. A grounding strategy𝒢:𝒬→ℋ\\mathcal\{G\}:\\mathcal\{Q\}\\to\\mathcal\{H\}maps a natural language question to a schema hinth∈ℋh\\in\\mathcal\{H\}that is prepended to the LLM system prompt\. The null strategy𝒢0​\(q\)=∅\\mathcal\{G\}\_\{0\}\(q\)=\\varnothingcorresponds to the no\-hint baseline \(Condition C1 in this paper\)\.

###### Definition 7\(Static vs\. Dynamic Grounding\)\.

A grounding strategy is*static*if𝒢​\(q\)=h0\\mathcal\{G\}\(q\)=h\_\{0\}for allqq, meaning that the same schema hint is used regardless of the question\. It is*dynamic*if𝒢​\(q\)\\mathcal\{G\}\(q\)varies withqq, selecting a question\-relevant subset of the schema\. SAL implements a dynamic grounding strategy where the hint is both question\-adaptive \(via SAL Detect\) and database\-adaptive \(via the live schema cache\)\.

### 3\.4The TPC\-H Benchmark

The Transaction Processing Performance Council Benchmark H \(TPC\-H\)\[[25](https://arxiv.org/html/2607.22572#bib.bib8)\]is a decision\-support benchmark modelling a supply\-chain analytics workload\. It defines eight tables \(Region,Nation,Customer,Orders,Lineitem,Supplier,Part, andPartsupp\) with referential integrity constraints forming a snowflake schema\. TPC\-H is widely used in database performance research and is an appropriate NL2SQL testbed because its schema complexity \(multi\-level joins, aggregations over large fact tables\) is representative of real enterprise analytical workloads\.

In this paper, TPC\-H data is loaded into an Oracle Autonomous Database 23c instance at scale factor 1 \(approximately 1 GB of raw data, 1\.5 million line items\)\. The region and nation names are anonymised in our deployment \(stored asRegion\#0–Region\#4andNation\#0–Nation\#24\) to avoid geographic bias in question answering; all 500 evaluation questions are written to be answerable without knowledge of the specific names\.

Table[2](https://arxiv.org/html/2607.22572#S3.T2)summarises the TPC\-H schema as deployed\.

Table 2:TPC\-H Schema as Deployed on Oracle ADB 23c

## 4System Design

SAL is implemented as a Node\.js HTTP server exposing a/generate\-sqlREST endpoint\. It sits between any natural language client application and the Oracle database, intercepting NL questions, grounding them with live schema context, generating SQL via a downstream LLM, and validating the result before returning it\. Fig\.[1](https://arxiv.org/html/2607.22572#S4.F1)shows the end\-to\-end architecture\. The four principal components are described in Sections[4\.1](https://arxiv.org/html/2607.22572#S4.SS1)–[4\.4](https://arxiv.org/html/2607.22572#S4.SS4)\.

NL client\(app or CLI\)SAL server/generate\-sqlSalDetecttable selectionBuildHintcolumns from cacheLLM call\(Oracle rules \+ hint\)Hidx validate\+ auto\-correct/retryvalid?Schema cache\(USER\_TAB\_COLUMNS\)Execute onOracle ADBReturn SQLErroryesno

Figure 1:SAL end\-to\-end architecture\. The server selects relevant tables, injects live schema columns into the LLM prompt, validates generated SQL with Hidx, and logs each request for auditing and offline evaluation\.### 4\.1Schema Loader

At server startup, SAL establishes a connection to the Oracle Autonomous Database instance and executes the following catalog query:

```
SELECT TABLE_NAME, COLUMN_NAME
FROM   USER_TAB_COLUMNS
ORDER  BY TABLE_NAME, COLUMN_ID
```

The result is stored in a persistent in\-memory schema cache𝒞\\mathcal\{C\}— a dictionary mapping each table name to its ordered list of column names\. In our deployment this loads 18 tables and 121 columns in under 500 ms\. The cache is populated once per server process and remains valid for the lifetime of the deployment; a server restart re\-queries the catalog, ensuring the cache reflects any DDL changes\.

The use ofUSER\_TAB\_COLUMNSis deliberate\. This Oracle system view exposes*only*the columns of objects owned by the connected user, providing a naturally scoped, privilege\-respecting view of the schema without requiringDBA\_level access\. Column order is preserved viaCOLUMN\_IDso that the dynamic hint presents columns in their physical declaration order, matching the expectation of a developer readingDESCRIBE tablename\.

### 4\.2SAL Detect: Complexity\-Gated Table Selection

Given a natural language questionqq, SAL Detect selects the subset of tables𝒯​\(q\)⊆𝒯\\mathcal\{T\}\(q\)\\subseteq\\mathcal\{T\}whose columns should appear in the LLM prompt\. Providing the full schema for every query is wasteful for simple single\-table questions and inflates the prompt token count; providing too narrow a selection for complex multi\-table queries starves the LLM of JOIN context and produces incorrect queries\. SAL Detect v2 resolves this tension through three sequential steps\.

#### 4\.2\.1Scored Keyword Matching

Each tablet∈𝒯t\\in\\mathcal\{T\}is associated with a domain vocabularyKtK\_\{t\}— a curated set of keywords drawn from column names, common synonyms, and domain terms\. For example:

KLineitem\\displaystyle K\_\{\\textsc\{Lineitem\}\}=\{“lineitem”, “revenue”, “shipdate”,\\displaystyle=\\\{\\text\{\`\`lineitem'', \`\`revenue'', \`\`shipdate'',\}“discount”, “quantity”, “tax”, …\}\\displaystyle\\quad\\text\{\`\`discount'', \`\`quantity'', \`\`tax'', \\ldots\}\\\}KOrders\\displaystyle K\_\{\\textsc\{Orders\}\}=\{“order”, “purchase”, “priority”,\\displaystyle=\\\{\\text\{\`\`order'', \`\`purchase'', \`\`priority'',\}“clerk”, “total price”, …\}\\displaystyle\\quad\\text\{\`\`clerk'', \`\`total price'', \\ldots\}\\\}
We defineMatch\(k,q\)\(k,q\)to be true if the keyword or phrasekkoccurs inqqafter case\-folding and whitespace normalisation \(i\.e\., contiguous substring match on the normalised strings\)\. A table receives a score equal to the number of matched keywords fromKtK\_\{t\}:

score​\(t,q\)=∑k∈Kt𝟏​\[Match​\(k,q\)\]\\text\{score\}\(t,q\)=\\sum\_\{k\\in K\_\{t\}\}\\mathbf\{1\}\[\\textsc\{Match\}\(k,q\)\]\(3\)
Tables withscore​\(t,q\)=0\\text\{score\}\(t,q\)=0are excluded\. This simple counting approach outperforms binary matching \(SAL v1\) by ensuring that tables with many relevant keyword hits are reliably selected even when a single keyword is ambiguous\.

#### 4\.2\.2JOIN\-Chain Expansion

SQL queries rarely touch a single table in isolation\. After scoring, SAL expands the directly matched set𝒯direct\\mathcal\{T\}\_\{\\text\{direct\}\}by including one\-hop JOIN partners drawn from a static adjacency map𝒥\\mathcal\{J\}:

𝒯expanded=𝒯direct∪⋃t∈𝒯direct𝒥​\(t\)\\mathcal\{T\}\_\{\\text\{expanded\}\}=\\mathcal\{T\}\_\{\\text\{direct\}\}\\cup\\bigcup\_\{t\\in\\mathcal\{T\}\_\{\\text\{direct\}\}\}\\mathcal\{J\}\(t\)\(4\)
The adjacency map encodes the natural JOIN relationships in the TPC\-H schema \(e\.g\.,𝒥​\(Lineitem\)=\{Orders,Part,Supplier,Partsupp\}\\mathcal\{J\}\(\\textsc\{Lineitem\}\)=\\\{\\textsc\{Orders\},\\textsc\{Part\},\\textsc\{Supplier\},\\textsc\{Partsupp\}\\\}\)\. In our implementation,𝒥\\mathcal\{J\}is constructed once from the known TPC\-H foreign\-key graph \(and can equivalently be derived from Oracle constraint metadata\) and stored as a static adjacency list\.

If the expanded set\|𝒯expanded\|≥6\|\\mathcal\{T\}\_\{\\text\{expanded\}\}\|\\geq 6out of 8 tables, the full schema is returned directly to avoid presenting a near\-complete but arbitrarily incomplete hint\.

#### 4\.2\.3Complexity Gate

Multi\-join questions often use vocabulary that matches few tables directly — for example, the question*“which customers ordered parts from suppliers in Asia with high revenue?”*scoresCustomerandSupplierbut notLineitem,Orders, orNation\. To detect such cases, SAL computes a*complexity signal count*:

cplx​\(q\)=∑p∈𝒫𝟏​\[Match​\(p,q\)\]\\text\{cplx\}\(q\)=\\sum\_\{p\\in\\mathcal\{P\}\}\\mathbf\{1\}\[\\textsc\{Match\}\(p,q\)\]\(5\)
where𝒫\\mathcal\{P\}is a set of multi\-table indicator phrases \(*“who”*,*“revenue”*,*“for each”*,*“across”*,*“total”*,*“average”*, etc\.\)\. The thresholds used in this gate \(\|𝒯direct\|<3\|\\mathcal\{T\}\_\{\\text\{direct\}\}\|<3andcplx​\(q\)≥2\\text\{cplx\}\(q\)\\geq 2\) were chosen to trade off prompt length against missed JOIN context on our 500\-question benchmark and were kept fixed across all reported experiments\. If the gate triggers, SAL falls back to the full schema regardless of keyword scores\.

𝒯​\(q\)=\{𝒯if​\|𝒯direct\|=0𝒯if​\|𝒯direct\|<3​andcplx​\(q\)≥2𝒯if​\|𝒯expanded\|≥6𝒯expandedotherwise\\mathcal\{T\}\(q\)=\\begin\{cases\}\\mathcal\{T\}&\\text\{if \}\|\\mathcal\{T\}\_\{\\text\{direct\}\}\|=0\\\\ \\mathcal\{T\}&\\text\{if \}\|\\mathcal\{T\}\_\{\\text\{direct\}\}\|<3\\text\{ and \}\\text\{cplx\}\(q\)\\geq 2\\\\ \\mathcal\{T\}&\\text\{if \}\|\\mathcal\{T\}\_\{\\text\{expanded\}\}\|\\geq 6\\\\ \\mathcal\{T\}\_\{\\text\{expanded\}\}&\\text\{otherwise\}\\end\{cases\}\(6\)
The selected tables and their exact column lists from the live cache are serialised into a structured schema hint injected into the LLM system prompt alongside explicit Oracle dialect rules \(FETCH FIRST n ROWS ONLY, column prefix conventions, window function restrictions\)\.

### 4\.3Hallucination Index \(Hidx\) Validator

After the LLM generates a candidate SQL statementSS, Hidx performs pre\-execution static validation against the live schema cache\. The process has three phases\.

#### 4\.3\.1Alias Map Construction

Hidx parsesSSusing a regular expression that matchesFROM/JOINclauses of the formTABLE\_NAME ALIAS:

```
(?:FROM|JOIN)\s+([A-Z_]+)\s+([A-Z_]+)
```

This builds an alias mapα:alias→table\\alpha:\\text\{alias\}\\to\\text\{table\}\. For example,FROM ORDERS O JOIN LINEITEM Lproducesα=\{O↦ORDERS,L↦LINEITEM\}\\alpha=\\\{\\texttt\{O\}\\mapsto\\texttt\{ORDERS\},\\;\\texttt\{L\}\\mapsto\\texttt\{LINEITEM\}\\\}\.

Limitation\.This lightweight parsing is designed for the single\-block SQL style produced by our prompt templates\. It does not fully support arbitrary nested queries, quoted identifiers, or aliases introduced by subqueries/CTEs; such aliases are treated as out of scope and are skipped in subsequent validation\.

#### 4\.3\.2Reference Extraction and Validation

Hidx then extracts allalias\.columnreferences fromSSusing:

```
\b([A-Z_]\w*)\.([A-Z_]\w*)\b
```

For each reference\(alias,col\)\(\\textit\{alias\},\\textit\{col\}\):

1. 1\.Ifα​\(alias\)\\alpha\(\\textit\{alias\}\)is undefined, the reference is skipped \(sub\-query aliases or CTEs are outside the current scope\)\.
2. 2\.Let𝒞t\\mathcal\{C\}\_\{t\}be the column list of tablet=α​\(alias\)t=\\alpha\(\\textit\{alias\}\)from the live cache\.
3. 3\.Ifcol∈𝒞t\\textit\{col\}\\in\\mathcal\{C\}\_\{t\}: valid; no action\.
4. 4\.Ifalias\_col∈𝒞t\\textit\{alias\}\\text\{\\\_\}\\textit\{col\}\\in\\mathcal\{C\}\_\{t\}: auto\-correctable; the missing table\-prefix pattern is detected \(e\.g\.,O\.ORDERDATE→\\toO\.O\_ORDERDATE\)\.
5. 5\.If anyc∈𝒞tc\\in\\mathcal\{C\}\_\{t\}satisfiesc\.endsWith​\(“\_”∥col\)c\.\\texttt\{endsWith\}\(\\text\{\`\`\\\_''\}\\,\\\|\\,\\textit\{col\}\): suffix\-correctable\.
6. 6\.Otherwise: error; the column does not exist on that table\.

#### 4\.3\.3Classification and Output

Hidx classifies the generated SQL into one of three categories:

- •Valid: no errors and no corrections — SQL returned as\-is\.
- •Auto\-correctable: all invalid references fall into case \(4\) or \(5\) above — corrections applied by regex rewrite with no LLM call\.
- •Retry required: at least one reference is in case \(6\) — a structured error report is constructed listing each invalid reference, the table it was mapped to, and the full list of valid columns for that table\.

### 4\.4Retry Loop

When Hidx classifies the SQL as requiring a retry, SAL constructs a structured feedback message appended to the conversation history:

\[Hidx\] Your SQL has invalid Oracle column references:\- "N\.N\_NAME" \-\- column "N\_NAME" does not existon NATION\. Valid columns: N\_NATIONKEY, N\_NAME, N\_REGIONKEY, N\_COMMENTRewrite the SQL using ONLY the exact column names from the schema above\.

This feedback, together with the original LLM response, is submitted as a two\-turn conversation to the LLM for revision\. The loop runs for a maximum of two retry passes\. Empirically, the first retry corrects the majority of non\-auto\-correctable errors; the second pass handles residual issues introduced during the first revision\.

Algorithm[1](https://arxiv.org/html/2607.22572#alg1)summarises the complete SAL pipeline\.

Algorithm 1SAL: Schema\-Aware Localisation Pipeline1:Question

qq, schema cache

𝒞\\mathcal\{C\}, LLM

ℳ\\mathcal\{M\}
2:Oracle SQL statement

SSor error

3:

𝒯​\(q\)←SalDetect​\(q,𝒞\)\\mathcal\{T\}\(q\)\\leftarrow\\textsc\{SalDetect\}\(q,\\mathcal\{C\}\)
4:

h←BuildHint​\(𝒯​\(q\),𝒞\)h\\leftarrow\\textsc\{BuildHint\}\(\\mathcal\{T\}\(q\),\\mathcal\{C\}\)
5:

S←ℳ​\(\[h,q\]\)S\\leftarrow\\mathcal\{M\}\(\[h,q\]\)
6:for

i=1i=1to

22do

7:

\(v,ℰ,ℱ\)←Hidx​\(S,𝒞\)\(v,\\mathcal\{E\},\\mathcal\{F\}\)\\leftarrow\\textsc\{Hidx\}\(S,\\mathcal\{C\}\)
8:if

v=validv=\\textit\{valid\}thenbreak

9:endif

10:if

v=correctablev=\\textit\{correctable\}then

11:

S←AutoCorrect​\(S,ℱ\)S\\leftarrow\\textsc\{AutoCorrect\}\(S,\\mathcal\{F\}\)break

12:endif

13:

f​b←BuildFeedback​\(ℰ,ℱ\)fb\\leftarrow\\textsc\{BuildFeedback\}\(\\mathcal\{E\},\\mathcal\{F\}\)
14:

S←ℳ​\(\[h,q,S,f​b\]\)S\\leftarrow\\mathcal\{M\}\(\[h,q,S,fb\]\)
15:endfor

16:return

SS

### 4\.5Implementation Details

SAL is implemented in Node\.js \(v20 LTS\) with thenode\-oracledbdriver for Oracle connectivity\. The HTTP API follows the Model Context Protocol specification\[[1](https://arxiv.org/html/2607.22572#bib.bib38)\]: POST requests to/generate\-sqlcarry a JSON body with the natural languagequestion, optionalsalflag \(boolean\), and optionalschema\_hintoverride\. The server returns a JSON response containing the generatedsql,source\(one ofsal\_llm,sal\_autocorrect,sal\_retry\), andhidx\_correctionscount where applicable\.

Security\.The server connects to Oracle using a dedicated read\-only role \(SELECT\-only\) and rejects any generated DML/DDL statements via a pre\-execution guard\. User questions are treated as untrusted input and are inserted into the prompt as a delimited block with explicit instructions to ignore embedded directives \(prompt\-injection hardening\)\.

The LLM backend is configurable; all experiments in this paper use GPT\-4o\-mini via the OpenAI API with temperature 0 for reproducibility\. The system prompt encodes Oracle\-specific dialect rules in addition to the dynamic schema hint:FETCH FIRST n ROWS ONLYfor row limiting,CEIL\(EXTRACT\(MONTH FROM d\)/3\)as a substitute for unavailableEXTRACT\(QUARTER\), and the column\-prefix convention \(O\.O\_ORDERDATE, notO\.ORDERDATE\)\.

For double\-blind review, the repository link is omitted and will be provided in the camera\-ready version\.

## 5Online Execution\-Grounded Verification

Static analysis via Hidx \(Section[4\.3](https://arxiv.org/html/2607.22572#S4.SS3)\) detects column\-reference hallucinations before execution, but it cannot detect*semantic*errors — queries that are syntactically valid and reference correct columns yet return the wrong answer\. Online Execution\-Grounded Verification \(OEGV\) closes this gap by submitting the generated SQL to the live Oracle instance, capturing the runtime result and any error signal, and using both to drive a second\-stage correction loop\.

### 5\.1Motivation

Consider the query:*“How many orders were placed in the last quarter of 1997?”*A model with full schema grounding might generate:

SELECT COUNT\(\*\) FROM ORDERSWHERE EXTRACT\(MONTH FROM O\_ORDERDATE\)BETWEEN 10 AND 12AND EXTRACT\(YEAR FROM O\_ORDERDATE\) = 1997;

Hidx validates this as hallucination\-free:O\_ORDERDATEexists onOrders, andEXTRACTis a standard function\. Yet on Oracle, this query may execute but return a result that does not match the reference answer if the reference usesTO\_CHAR\(O\_ORDERDATE, ’Q’\) = ’4’or a different quarter\-boundary convention\. Hidx has no visibility into this semantic discrepancy\.

OEGV provides a runtime signal by executing both the generated SQL and, where available, a reference or a verification probe on the live database, comparing result sets to confirm semantic correctness\.

### 5\.2Verification Architecture

OEGV operates as a post\-Hidx stage in the SAL pipeline and consists of four steps: execution, result capture, semantic comparison, and feedback\-driven correction\. Fig\.[2](https://arxiv.org/html/2607.22572#S5.F2)illustrates the flow\.

SAL SQL \(post\-Hidx\)Execute onOracle ADBResultmatches?Return SQL\(verified\)Build semanticfeedbackLLM retry\(semantic\)Referenceresult probeyesnoexpected

Figure 2:Online execution\-grounded verification \(OEGV\) pipeline\.
### 5\.3Execution and Result Capture

SAL submits the post\-Hidx SQLSSto the Oracle ADB instance via thenode\-oracledbdriver\. Three outcomes are possible:

1. 1\.Execution error\(ORA\-XXXXX\): the statement raises a runtime exception\. This class of errors is partially addressed by Hidx but may persist for errors outside column\-reference scope — for example,ORA\-30483\(window function in an invalid context\) orORA\-00907\(missing right parenthesis from malformed CTE syntax\)\. The error message and offending token position are captured and included in the feedback to the LLM\.
2. 2\.Execution success, empty result: the statement executes but returns zero rows\. In the context of TPC\-H data at SF=1, empty results are often a symptom of an overly restrictive predicate \(e\.g\., a string literal that does not match any anonymised region name, or a date range outside the dataset window 1992–1998\), but they may also be valid for some narrowly scoped questions\.
3. 3\.Execution success, non\-empty result: the result setR=⟦S⟧𝒟R=\\llbracket S\\rrbracket\_\{\\mathcal\{D\}\}is captured for semantic comparison\.

### 5\.4Semantic Comparison

###### Definition 8\(Semantic Equivalence\)\.

Two result setsR1R\_\{1\}andR2R\_\{2\}are*semantically equivalent*\(R1≡R2R\_\{1\}\\equiv R\_\{2\}\) if and only if, after applying a row\-wise canonicalisation functioncanonical​\(⋅\)\\text\{canonical\}\(\\cdot\), the resulting collections are equal under multiset comparison:

\{\{canonical​\(R1\)\}\}=\{\{canonical​\(R2\)\}\}\.\\displaystyle\\\{\\\!\\\{\\text\{canonical\}\(R\_\{1\}\)\\\}\\\!\\\}=\\\{\\\!\\\{\\text\{canonical\}\(R\_\{2\}\)\\\}\\\!\\\}\.\(7\)The canonicalisation normalises numeric types to a fixed decimal precision, strips trailing whitespace fromCHARcolumns \(an Oracle padding artefact\), and convertsDATEvalues to ISO\-8601 strings\.

Row ordering is checked only when the reference SQLS∗S^\{\*\}contains anORDER BYclause; otherwise, results are compared as multisets\.

This definition operationalises the semantic equivalence check used by our EGT evaluation and is implemented in the evaluation framework’ssemantic\_matchfunction, which canonicalises both result sets to JSON arrays of row dictionaries before comparison\.

In evaluation mode \(Condition C3b\), the reference resultR∗R^\{\*\}is pre\-computed by executingS∗S^\{\*\}against𝒟\\mathcal\{D\}during the baseline phase\. OEGV comparesR=⟦S⟧𝒟R=\\llbracket S\\rrbracket\_\{\\mathcal\{D\}\}againstR∗R^\{\*\}; ifR≢R∗R\\not\\equiv R^\{\*\}, it triggers a semantic retry \(Section[5](https://arxiv.org/html/2607.22572#S5)\) up to once\.

In deployment mode \(no reference SQL available\), OEGV cannot certify correctness and instead applies conservative plausibility checks\. In our prototype, “aggregation query” is detected by the presence of an aggregate function \(e\.g\.,COUNT,SUM,AVG,MIN,MAX\) without aGROUP BYmismatch, and expected row\-count ranges are computed from lightweight schema statistics \(e\.g\., table cardinalities\) for the specific benchmark schema \(TPC\-H SF=1\):

- •Row\-count plausibility: flag aggregates whose magnitude is implausible given table cardinalities \(TPC\-H\-specific in this paper\)\.
- •Type consistency: verify that numeric columns do not return string values and vice versa, catching cases whereTO\_CHARis incorrectly applied to a numeric aggregate\.
- •NULL density: flag results where more than 50% of values areNULL, which can indicate a join\-key mismatch or incorrect outer\-join direction\.

### 5\.5Semantic Feedback Construction

WhenR≢R∗R\\not\\equiv R^\{\*\}\(or when heuristic checks fail in deployment mode\), OEGV constructs a structured semantic feedback message for the LLM retry:

\[OEGV\] Your SQL executed successfully but returnedan incorrect result\.Expected: 3 rows \| Got: 0 rowsHint: Your WHERE clause may exclude valid rows\.Check date range predicates against the datasetwindow 1992\-01\-01 to 1998\-12\-31\.Check that string literals match the anonymisednaming convention \(e\.g\., ’Region\#2’, not ’ASIA’\)\.Rewrite the SQL to return the correct result\.

The feedback is appended to the conversation and submitted to the LLM for a semantic correction pass\. OEGV allows a maximum of one semantic retry \(separate from the two Hidx structural retries\), giving the LLM a total of up to three revision opportunities per question\.

### 5\.6Relationship to Hidx

OEGV and Hidx are complementary and operate at different levels of the validation stack, as shown in Table[3](https://arxiv.org/html/2607.22572#S5.T3)\.

Table 3:Hidx vs\. OEGV: Scope and Failure Classes AddressedIn the evaluation framework used in this paper, OEGV is realised by the baseline phase ofrun\_sql\_evaluation\.py, which pre\-computesR∗R^\{\*\}for all 500 questions and stores them as the ground\-truth result cache against which SAL\-generated results are compared\. In a production deployment without reference SQL, the heuristic plausibility checks described above provide a partial OEGV signal at the cost of reduced precision, a direction for future work discussed in Section[11](https://arxiv.org/html/2607.22572#S11)\.

### 5\.7OEGV Impact on EGT Accuracy

OEGV adds a post\-execution semantic retry beyond the pre\-execution Hidx validator\. In our evaluation setting \(TPC\-H,N=500N=500\), the retry is triggered when the executed resultRRdoes not match the cached reference resultR∗R^\{\*\}under Definition[8](https://arxiv.org/html/2607.22572#Thmdefinition8)\. In our evaluation, OEGV\-triggered semantic retry did not recover additional queries beyond those corrected by Hidx; all 174 semantic mismatches remained unresolved within the two\-pass retry budget\.

## 6Offline Benchmark Harness

We evaluate using execution\-grounded truth \(EGT\): the fraction of generated SQL statements that both execute without error and return the correct result set on the live database\. This is stricter than execution accuracy, which only requires the query to run without error\.

The offline benchmark harness is the evaluation infrastructure that orchestrates the four\-condition ablation study, executes all SQL against the live Oracle ADB instance, collects runtime metrics, and computes the EGT, EA, and latency statistics reported in Section[7](https://arxiv.org/html/2607.22572#S7)\. It is implemented as a Python module \(run\_sql\_evaluation\.py\) and uses Oracle SQLcl via our MCP integration to execute queries and capture results\.

### 6\.1Harness Architecture

The harness operates in two sequential phases for each experimental condition: a*baseline phase*that executes reference SQL against Oracle ADB to pre\-compute ground\-truth result sets, and a*SAL phase*that submits each natural language question to the SAL server, executes the returned SQL, and compares results against the cached ground truth\. Fig\.[3](https://arxiv.org/html/2607.22572#S6.F3)shows the high\-level control flow\.

Question set𝒬\\mathcal\{Q\}\(N=500\)Baseline Phase\(executeS∗S^\{\*\}\)Result cache\{Ri∗\}\\\{R^\{\*\}\_\{i\}\\\}NL questionqiq\_\{i\}SAL Server\(/generate\-sql\)ExecuteSiS\_\{i\}on Oracle ADBRi≡Ri∗R\_\{i\}\\equiv R^\{\*\}\_\{i\}?PASSFAILResults JSON\+ metricsPhase 1Phase 2

Figure 3:Offline benchmark harness control flow\. Phase 1 precomputes ground\-truth result sets by executing reference SQL on Oracle ADB\. Phase 2 submits each question to the SAL server, executes the returned SQL, and compares results against the Phase 1 cache\. All metrics are written to a timestamped JSON file\.
### 6\.2Question Dataset

The 500 evaluation questions are stored inexperiments/new\-practice\-questions\.jsonas a JSON array\. Each entry specifies:

- •id: unique integer identifier \(1–500\)\.
- •question: the natural language question string\.
- •sql: the reference SQL statementS∗S^\{\*\}written by a domain expert familiar with the TPC\-H Oracle schema\.
- •complexity: one ofsimple,medium, orcomplex, following the Spider benchmark convention\[[34](https://arxiv.org/html/2607.22572#bib.bib13)\]\.
- •tags: optional list of SQL feature tags \(aggregate,join,subquery,window,cte, etc\.\) used for failure\-mode analysis\.

Questions are drawn from three tiers in a 20/20/60 ratio \(100 simple, 100 medium, 300 complex\), reflecting the proportion of complex analytical queries in typical enterprise SQL workloads\. All reference SQL statements were validated for execution correctness against the live Oracle ADB instance prior to evaluation\. The question set was authored by the same team that designed SAL’s keyword maps and adjacency graph; see T\-I4 \(Section[10](https://arxiv.org/html/2607.22572#S10)\) for the leakage implications\.

### 6\.3Phase 1: Baseline Execution

For each questionqiq\_\{i\}, the harness executesSi∗S^\{\*\}\_\{i\}against Oracle ADB using thepython\-oracledbthick\-mode driver with the wallet credentials of the ADB instance\. The following are recorded:

- •Execution status:okorfail\(with theORA\-error code\)\.
- •Result setRi∗R^\{\*\}\_\{i\}: serialised as a JSON array of row dictionaries with canonicalised values \(Section[5](https://arxiv.org/html/2607.22572#S5)\)\.
- •Row count:\|Ri∗\|\|R^\{\*\}\_\{i\}\|\.
- •Wall\-clock latency: measured from driver call to result fetch completion \(ms\)\.
- •EXPLAIN PLAN cost: obtained viaEXPLAIN PLAN FORfollowed by a query onPLAN\_TABLE, capturing the root\-node estimated cost and cardinality for RQ3 analysis\.

Questions for whichSi∗S^\{\*\}\_\{i\}fails execution \(e\.g\., due to data\-dependent predicates or schema state at test time\) are excluded from all conditions \(i\.e\., from the comparable set used to compute EGT/EA\) and flagged in the results JSON\. In our evaluation, all 500 reference queries executed successfully\.

### 6\.4Phase 2: SAL Generation and Evaluation

For each questionqiq\_\{i\}, the harness submits an HTTP POST request to the SAL server:

```
POST http://localhost:3000/generate-sql
Content-Type: application/json

{
  "question": "<q_i>",
  "sal": true,
  "schema_hint": true
}
```

The server returns a JSON response containingsql,source, and optionalhidx\_corrections\. The harness then executes the returned SQLSiS\_\{i\}against Oracle ADB and records:

- •Generation status: whether the server returned a non\-empty SQL string\.
- •Execution status:okorfailwithORA\-error\.
- •Semantic match:Ri≡Ri∗R\_\{i\}\\equiv R^\{\*\}\_\{i\}per Definition[8](https://arxiv.org/html/2607.22572#Thmdefinition8)\.
- •Exact order match: whether row ordering matchesRi∗R^\{\*\}\_\{i\}where anORDER BYis specified inSi∗S^\{\*\}\_\{i\}\.
- •MCP latency: wall\-clock time from HTTP request to SQL returned by the server \(includes LLM API round\-trip\)\.
- •Execution latency: time to executeSiS\_\{i\}on Oracle ADB\.
- •Cost delta: difference between EXPLAIN PLAN cost ofSiS\_\{i\}andSi∗S^\{\*\}\_\{i\}\(positive = generated SQL is more expensive\)\.

Per\-question results are accumulated in a list and written to a timestamped JSON file on completion:

experiments/results/sql\_evaluation\_YYYYMMDD\_HHMMSS\.json

### 6\.5Metric Aggregation

After both phases complete, the harness computes the following aggregate statistics:

##### RQ1: Semantic Correctness

EGT=\|\{i:Ri≡Ri∗\}\|N×100%\\displaystyle=\\frac\{\|\\\{i:R\_\{i\}\\equiv R^\{\*\}\_\{i\}\\\}\|\}\{N\}\\times 100\\%\(8\)EA=\|\{i:Si​executes without error\}\|N×100%\\displaystyle=\\frac\{\|\\\{i:S\_\{i\}\\text\{ executes without error\}\\\}\|\}\{N\}\\times 100\\%\(9\)Both are reported overall and by complexity tier\.

##### RQ2: Execution Efficiency

Latency is reported as mean, median, and 95th percentile \(p95\) across all executed queries, separated into baseline and SAL phases\. The overhead ratio is computed per question as:

ρi=ℓiMCPℓibase\\rho\_\{i\}=\\frac\{\\ell^\{\\text\{MCP\}\}\_\{i\}\}\{\\ell^\{\\text\{base\}\}\_\{i\}\}\(10\)and summarised by tier\. Median ratio is reported in preference to mean ratio to reduce sensitivity to the long tail of complex\-query retries\.

##### RQ3: Optimisation Potential

For each pair\(Si∗,Si\)\(S^\{\*\}\_\{i\},S\_\{i\}\)where both execute successfully, the cost deltaΔi=cost​\(Si\)−cost​\(Si∗\)\\Delta\_\{i\}=\\text\{cost\}\(S\_\{i\}\)\-\\text\{cost\}\(S^\{\*\}\_\{i\}\)is computed\. Queries are classified as*lower*\(Δi<0\\Delta\_\{i\}<0\),*same*\(Δi=0\\Delta\_\{i\}=0\), or*higher*\(Δi\>0\\Delta\_\{i\}\>0\)\. Correct\-but\-expensive queries \(EGT PASS withΔi\>100\\Delta\_\{i\}\>100\) are flagged as optimisation candidates\.

##### RQ4: Complexity Robustness

EGT is disaggregated by tier and the accuracy degradationδs→m=EGTm−EGTs\\delta\_\{s\\to m\}=\\text\{EGT\}\_\{m\}\-\\text\{EGT\}\_\{s\}andδm→c=EGTc−EGTm\\delta\_\{m\\to c\}=\\text\{EGT\}\_\{c\}\-\\text\{EGT\}\_\{m\}are reported in percentage points\.

### 6\.6Experimental Controls

The following controls were applied to ensure reproducibility:

1. 1\.LLM temperature: set to 0 for all SAL conditions to eliminate sampling variance between runs\.
2. 2\.Server isolation: the SAL server was restarted before each condition run to clear any cached LLM conversation state\.
3. 3\.Question order: questions were evaluated in fixed index order \(1–500\) without shuffling to ensure identical Oracle buffer cache state across condition runs\.
4. 4\.Oracle statistics:DBMS\_STATS\.GATHER\_SCHEMA\_STATSwas executed once before the evaluation series to ensure stable EXPLAIN PLAN costs across runs\.
5. 5\.Network isolation: all experiments were conducted on the same machine with a stable connection to the Oracle ADB instance to minimise network jitter in latency measurements\.
6. 6\.Result validation: the harness validates that the baseline phase result cache is fully populated before beginning Phase 2, aborting if any reference query failed execution\.

Harness CLI usage \(including the full flag set and example run commands\) is documented in the supplementary material\.

## 7Empirical Results

We report results for the four research questions defined in Section[6](https://arxiv.org/html/2607.22572#S6)\. All experiments use the 500\-question TPC\-H benchmark \(100 Simple / 100 Medium / 300 Complex\) executed against a live Oracle Autonomous Database instance under identical network and concurrency conditions\.

Table 4:Evaluation conditions\.Condition labels follow Table[4](https://arxiv.org/html/2607.22572#S7.T4):C1\(no schema hint\),C2\(static schema hint\),C3a\(SAL v1\), andC3b\(SAL v2, the proposed system\)\.

### 7\.1RQ1: Execution\-Grounded Accuracy \(EGT\)

Table[5](https://arxiv.org/html/2607.22572#S7.T5)summarises the primary accuracy metric\.

Table 5:Ablation Results: Execution\-Grounded Truth \(EGT\),N=500N=500questions\. 95% Wilson confidence intervals shown for EGT\.C1 \(No hint\)\.Removing schema context reduces EGT to 2\.2 %, a drop of 59\.8 percentage points \(pp\) relative to SAL v2\. Only 12 of 500 generated queries execute without anORA\-error; the remainder reference hallucinated table or column names that do not exist in the Oracle schema\.

C2 \(Static hint\)\.Providing the full static schema string recovers 62\.0 % EGT, establishing a strong single\-prompt upper bound that requires no infrastructure beyond a long context window\.

C3a \(SAL v1\)\.SAL v1 scores 58\.4 % EGT, 3\.6 pp below the static baseline\. Investigation reveals that SAL v1’s binary keyword matcher occasionally omits tables required by multi\-hop joins\.

C3b \(SAL v2, proposed\)\.SAL v2 reaches62\.6 %EGT, statistically on par with the static baseline \(62\.0 %\), with the 0\.6 pp gap within the binomial margin of error atN=500N=500, while retaining dynamic grounding\.

### 7\.2RQ2: Latency Overhead

Table[6](https://arxiv.org/html/2607.22572#S7.T6)reports end\-to\-end latency measured at the client\. SAL v2 introduces a small median overhead \(17\.9 ms\) but a larger mean overhead because a minority of complex queries trigger retries and dominate the tail\. Table[7](https://arxiv.org/html/2607.22572#S7.T7)shows that this tail is concentrated in the complex tier\.

Table 6:End\-to\-End Latency \(ms\): Baseline vs\. SAL v2Table 7:Median Latency \(ms\) by Complexity Tier
### 7\.3RQ3: Token\-Cost Analysis

To isolate the incremental prompt tokens introduced by MCP, we compare only queries where both the baseline and SAL v2 produce an execution\-grounded result\. Table[8](https://arxiv.org/html/2607.22572#S7.T8)shows SAL v2 reduces mean token cost by avoiding the full static schema dump\.

Table 8:Token\-Cost Comparison: Baseline vs\. SAL v2 \(Ncomparable=433N\_\{\\text\{comparable\}\}=433\)OutcomeCount%MCP lower cost13531\.2Equal cost24556\.6MCP higher cost5312\.2Mean cost delta \(Δ\\Delta\)−207\.8\-207\.8tokensMedian cost delta0\.00\.0tokens
### 7\.4RQ4: Performance by Complexity Tier

As shown in Table[9](https://arxiv.org/html/2607.22572#S7.T9), EGT is explained according to the complexity of the question\.

Table 9:EGT \(%\) by Complexity Tier\.Static\-hint \(C2\) tier\-level logs were not retainedfor this run; therefore we report only its overall EGT in Table[5](https://arxiv.org/html/2607.22572#S7.T5)and*do not make tier\-level parity claims*between SAL v2 and the static\-hint baseline\.C2 limitation\.Because the C2 per\-question telemetry was not preserved, we cannot attribute the static\-hint baseline to Simple/Medium/Complex and thus cannot substantiate claims of “matching” C2*at the tier level*\. All comparisons to C2 in this paper should be read as*overall*\(aggregate\) accuracy comparisons; we plan to re\-run C2 with tier\-tagged logging in a revision/artifact update\.

The tier\-level degradation for SAL v2 is steep from medium to complex, indicating a reasoning boundary rather than a schema\-linking boundary\. Givenn=100n=100per simple and medium tier andn=300n=300for the complex tier, tier\-level differences between SAL v1 and SAL v2 should be interpreted as directional rather than statistically conclusive; the aggregate comparison in Table[5](https://arxiv.org/html/2607.22572#S7.T5)remains the primary accuracy claim\.

### 7\.5SAL v2 Outcome Breakdown

Table[10](https://arxiv.org/html/2607.22572#S7.T10)decomposes EGT into the main post\-processing paths: direct passes, deterministic Hidx auto\-corrections, and retry\-based recoveries\. Of the 37 Hidx\-recovered queries, 22 were resolved by deterministic auto\-correction requiring no additional LLM call; the remaining 15 required at least one LLM retry pass within the two\-pass budget, accounting for the elevated mean latency relative to the median reported in Table[6](https://arxiv.org/html/2607.22572#S7.T6)\.

Table 10:SAL v2 Query Outcome Decomposition \(N=500N=500\)PathOutcomeCount%Direct passPASS: 1st attempt27655\.2Hidx correctionPASS: auto\-correct224\.4LLM retryPASS: retry153\.0Total PASS31362\.6Semantic failFAIL: mismatch17434\.8Execution failFAIL: ORA\- error132\.6Total FAIL18737\.4
### 7\.6Summary of Findings

Table[11](https://arxiv.org/html/2607.22572#S7.T11)summarises the answers to RQ1–RQ4\.

Table 11:Research Question Answers

## 8Hallucination and Failure\-Mode Study

The aggregate EGT metric in Section[7](https://arxiv.org/html/2607.22572#S7)summarises*what*goes wrong; this section examines*why*\. We develop a four\-class hallucination taxonomy grounded in the experimental evidence, quantify each class, and trace the causal chain from LLM generation to observable failure\.

### 8\.1Hallucination Taxonomy

Prior work distinguishes surface hallucination \(wrong tokens\) from factual hallucination \(wrong world knowledge\)\[[11](https://arxiv.org/html/2607.22572#bib.bib32)\]\. In the NL2SQL setting both manifest as structural errors in the generated SQL\. We refine this into four classes observable in our data:

H1: Phantom identifier\.The model emits a table or column name that does not exist in the connected schema\. Example:SELECT o\_totalprice FROM ORDERS\_SUMMARYwhen noORDERS\_SUMMARYtable exists\.

H2: Column–table mismatch\.A real column name is attributed to the wrong table\. Example:SELECT c\_name FROM LINEITEMwherec\_namebelongs toCUSTOMER\.

H3: Dialect confusion\.Oracle\-specific syntax is replaced with a construct from another RDBMS dialect \(PostgreSQL, SQL Server, MySQL\)\. Example: usingTOPnn\(T\-SQL\) instead of Oracle’sFETCHFIRSTnnROWS ONLY, orPIVOTwith SQL ServerFOR … INsyntax\.

H4: Structural reasoning error\.Schema identifiers are correct and dialect is correct, but the logical plan is wrong: a wrong aggregate, missingGROUP BYkey, inverted join predicate, or incorrect correlated sub\-query\. The query executes but the result set is semantically incorrect\.

H1 and H2 are*schema hallucinations*, suppressible by grounding\. H3 is a*dialect hallucination*, suppressible by dialect\-aware prompt engineering\. H4 is a*reasoning hallucination*, not suppressible by schema injection alone\.

### 8\.2Hallucination Evidence from the No\-Hint Ablation \(C1\)

Condition C1 \(no schema hint\) provides the clearest signal: the model receives only the natural\-language question and is free to hallucinate any schema it imagines\. Of the 500 queries submitted:

- •488 failed to execute\(ORA\- errors\), yielding EGT = 2\.2 %\.
- •Manual sampling of 50 failed queries found 41 cases of H1 \(phantom table/column\), 7 cases of H2 \(column–table mismatch\), and 2 cases of H3 \(dialect confusion\)\.
- •The 12 queries that did execute \(EGT = 11/500 after semantic check\) succeeded because the question happened to name a table explicitly\.

The dominant failure mode in C1 is H1\. The model spontaneously invents plausible table names absent from TPC\-H — for example generating identifiers such asORDERS\_SUMMARYrather than the actualORDERStable\. This pattern, observed in 41 of 50 manually sampled C1 failures \(Table[12](https://arxiv.org/html/2607.22572#S8.T12)\), reflects the model drawing on schema naming conventions internalized during pretraining rather than the target schema provided at inference time; it is a failure mode that schema grounding is specifically designed to suppress\.

Table 12:Hallucination class distribution in C1 \(50\-query manual sample\)\.
### 8\.3Hallucination Suppression by SAL

By injecting a dynamically selected column\-level hint, SAL v2 eliminates the precondition for H1 and H2: the model receives the exact set of table and column names that are valid for the question, and the Hidx validator enforces a post\-generation check\. The empirical effect is direct:

Execution rate:C​1=2\.4%⟶C​3​b=97\.4%\\text\{Execution rate:\}\\quad C1~=~2\.4\\,\\%\\;\\longrightarrow\\;C3b~=~97\.4\\,\\%\(11\)
The 97\.4 % execution rate of SAL v2 \(487/500\) means that only 13 queries still produce ORA\- errors after the full grounding pipeline\. This represents a37\.5×\\timesreductionin execution failures relative to C1\.

Hidx contribution\.Hidx caught and corrected 22 additional H1/H2 violations that survived initial hinting\. An additional 15 queries were recovered by the Hidx\-triggered LLM retry\. Together, these two sub\-pipelines account for a 7\.4 pp EGT uplift\.

### 8\.4Residual Failure\-Mode Analysis

The 187 queries that fail under SAL v2 decompose as follows \(see also Table[10](https://arxiv.org/html/2607.22572#S7.T10)\)\.

#### 8\.4\.1Execution Failures \(13 queries: H3 \+ unrecovered H1\)

Manual inspection of all 13 ORA\- residuals identifies three disjoint root causes:

1. 1\.Hierarchical queries \(6 queries\)\.Questions framed as hierarchies elicitCONNECT BYsyntax\. The model generates incorrect pseudo\-column references \(LEVEL,SYS\_CONNECT\_BY\_PATH\), producing ORA\-01788 or ORA\-30004\.
2. 2\.CorrelatedEXISTSsub\-queries \(4 queries\)\.The model misplaces the correlation predicate, producing a query that either times out or returns ORA\-01652 due to resource exhaustion\. Identifiers are valid but logic is wrong \(H4\)\.
3. 3\.PIVOTdialect confusion \(3 queries\)\.The model emits SQL Server bracket notation inside OraclePIVOT, producing ORA\-00907\. This is an H3 failure\.

#### 8\.4\.2Semantic Failures \(174 queries: H4\)

All 174 semantic failures execute without error but return a result set that does not match the reference answer\. They fall into three sub\-categories identified by output\-level inspection:

1. 1\.Aggregate scope errors \(estimated 60–70 %\)\.MissingGROUP BYkeys or wrong aggregation grain\.
2. 2\.Wrong join predicate direction \(estimated 15–20 %\)\.Join keys are swapped or attached to the wrong bridge table\.
3. 3\.Filter predicate inversion or omission \(estimated 15–20 %\)\.Conditions are dropped or inverted, especially under negation or relative temporal phrasing\.

These are H4 reasoning errors independent of schema knowledge\.

### 8\.5Schema\-Hallucination Suppression Rate

We define the*schema\-hallucination suppression rate*ηSH\\eta\_\{\\text\{SH\}\}as the fraction of schema\-class failures \(H1\+H2\) that the grounding pipeline eliminates:

ηSH=1−\|H1\+H2 failures under SAL v2\|\|H1\+H2 failures under C1\|\\eta\_\{\\text\{SH\}\}=1\-\\frac\{\|\\text\{H1\}\+\\text\{H2 failures under SAL v2\}\|\}\{\|\\text\{H1\}\+\\text\{H2 failures under C1\}\|\}\(12\)
From the C1 sample, H1\+H2 account for 96 % of execution failures, implying≈\\approx469 schema\-class failures at full scale\. SAL v2 reduces execution failures to 13, of which at most 6 are schema\-adjacent\. Thus:

ηSH≈1−6469≈98\.7%\\eta\_\{\\text\{SH\}\}\\approx 1\-\\frac\{6\}\{469\}\\approx\\mathbf\{98\.7\\,\\%\}\(13\)SAL v2 eliminates 98\.7 % of observable schema hallucinations\.

### 8\.6Implications for System Design

The failure\-mode analysis yields three actionable design recommendations:

1. 1\.Dialect guard\.Strengthen the Oracle dialect reminder \(row limiting, PIVOT syntax, and avoidingCONNECT BYunless warranted\)\.
2. 2\.Complexity\-aware chain\-of\-thought\.Inject step\-by\-step reasoning scaffolds for questions that trigger multiple complexity signals\[[27](https://arxiv.org/html/2607.22572#bib.bib41)\]\.
3. 3\.Retry budget tuning\.DetectEXISTS\-heavy cases early and route them to decomposition rather than verbatim retry\.

## 9Broader Context for Enterprise SQL Assistants

The experimental results in Section[7](https://arxiv.org/html/2607.22572#S7)were obtained on a single Oracle ADB instance running a well\-defined synthetic schema\. Before SAL can be recommended for production enterprise deployment, its assumptions, generalisation boundaries, and integration surface must be examined critically\. This section situates the work within four dimensions of enterprise reality: schema scale, multi\-tenancy, heterogeneous RDBMS backends, and the evolving regulatory landscape for AI\-generated data queries\.

### 9\.1Schema Scale and Detection Complexity

TPC\-H contains 8 tables and 61 columns — a deliberately compact schema chosen to provide clean ground truth\. Enterprise data warehouses routinely expose hundreds of tables and thousands of columns across multiple schemas\. SAL’s scored detection heuristic \(Section[4\.2](https://arxiv.org/html/2607.22572#S4.SS2)\) isO​\(\|Q\|⋅\|T\|\)O\(\|Q\|\\cdot\|T\|\)in question tokens and table count, which remains sub\-millisecond up to\|T\|≈500\|T\|\\approx 500tables on commodity hardware\. Beyond this threshold two challenges emerge:

1. 1\.Keyword collision\.At large scale, the same business term \(e\.g\.,*“order”*\) maps to multiple candidate tables \(SALES\_ORDERS,WORK\_ORDERS,PURCHASE\_ORDERS\)\. The current scoring function has no inter\-table disambiguation mechanism; it would include all candidates, inflating the hint\.
2. 2\.Hint length vs\. context window\.If SAL v2 detects 15\+ tables for a complex question, the column\-level hint may approach or exceed the LLM’s context window limit\. An adaptive*hint budget*— a maximum token cap on the injected hint, with columns ranked by detection score and truncated from the bottom — is the natural mitigation\.

Both issues are tractable engineering extensions\. The scoring framework of Equation \([3](https://arxiv.org/html/2607.22572#S4.E3)\) is designed to accept additional disambiguation signals \(e\.g\., user role, active business domain, recent query history\) as additive score terms\.

### 9\.2Multi\-Tenancy and Role\-Scoped Schema Injection

Enterprise databases are typically multi\-tenant: different user roles have access to different table subsets, and the same natural\-language question may be legally answerable with different schemas depending on who is asking\. SAL v2 currently loads a single shared schema reference at startup \(loadSALSchema\(\)\) — a design valid for a single\-tenant educational deployment but inadequate for multi\-tenant production\.

A role\-scoped extension would:

1. 1\.Accept arole\_idparameter on each MCP request\.
2. 2\.Resolve the caller’srole\_idto an OracleSESSION\_PRIVSsnapshot cached per role\.
3. 3\.RestrictsalDetectRelevantTables\(\)to tables visible under that role, so that the hint never leaks column names the caller is not authorised to query\.
4. 4\.Return an HTTP 403 at the Hidx validation stage if the generated SQL references a table outside the caller’s privilege set\.

This extension preserves the SAL architecture while enforcing least privilege at the schema\-injection layer\.

### 9\.3Heterogeneous RDBMS Backends

SAL v2 uses three Oracle\-specific mechanisms: theALL\_TAB\_COLUMNSdata dictionary view for schema introspection, theFETCH FIRSTnnROWS ONLYrow\-limiting clause, and theORA\-error code namespace in the Hidx validator\. Porting SAL to other enterprise RDBMS platforms requires replacing these three touch points:

Table 13:SAL portability: Oracle\-specific touch points and platform equivalents\.The SAL core logic — scored table detection, JOIN\-chain expansion, complexity gating, and identifier checking — is largely backend\-agnostic\. A configuration object mapping these touch points per backend is sufficient for portability\.

### 9\.4Integration with BI and Data Catalogue Tools

Enterprise SQL assistants are embedded within business intelligence stacks that already maintain schema metadata\. SAL’sschema\-reference\.jsonis architecturally similar to the*semantic layer*concept present in modern BI platforms\.

- •dbt \(data build tool\)\.A dbtschema\.ymlmanifest can be mechanically transformed into SAL’s column inventory JSON\. A dbt\-to\-SAL adapter would allow SAL to consume production dbt metadata directly\.
- •Apache Atlas / OpenMetadata\.Enterprise catalogues expose REST APIs returning schema metadata with business glossary tags\.loadSALSchema\(\)could be replaced by a catalogue API call\.
- •Oracle Analytics Cloud \(OAC\)\.OAC subject areas map business terms to physical columns — the same function as SAL’s keyword\-to\-table detection\. An OAC integration could replace heuristic detection with the subject\-area resolver\.

These paths suggest SAL is best characterised as a*grounding adapter*that fronts an LLM with schema metadata sourced from the enterprise’s authoritative catalogue\.

### 9\.5Long\-Context LLMs and the Future of Static Hints

The static hint baseline \(C2\) achieves 62\.0 % EGT by injecting the full schema into a single prompt\. With context windows expanding, one might ask whether dynamic schema injection remains necessary\.

We argue dynamic injection retains durable advantages even at very large context windows:

1. 1\.Token cost\.Injecting a large schema into every query has non\-trivial per\-query cost\. SAL’s targeted injection reduces prompt tokens substantially relative to full\-schema injection\.
2. 2\.Attention dilution\.Long\-context models can lose accuracy when task\-relevant tokens are buried in large contexts\[[17](https://arxiv.org/html/2607.22572#bib.bib45)\]\.
3. 3\.Governance compliance\.Injecting the full schema may expose column names a user is not authorised to know\.
4. 4\.Latency budget\.Prefill latency grows with prompt length\. SAL’s median overhead is below the prefill cost of a full\-schema injection at large scale\.

We therefore expect dynamic schema injection to remain preferred for enterprise SQL assistants as context windows expand\.

### 9\.6Comparison with Retrieval\-Augmented Generation Approaches

Schema\-aware SQL generation can be framed as a retrieval\-augmented generation \(RAG\) problem: embed column descriptions, retrieve the most relevant, and inject retrieved context\[[22](https://arxiv.org/html/2607.22572#bib.bib25),[8](https://arxiv.org/html/2607.22572#bib.bib24)\]\. SAL differs from embedding\-based RAG in three respects:

1. 1\.No embedding infrastructure\.SAL requires no vector store or embedding model\.
2. 2\.Structural JOIN awareness\.Embedding retrieval does not necessarily recover join\-bridge tables; SAL’s JOIN\-chain expansion addresses this structural gap\.
3. 3\.Determinism\.Embedding retrieval can change after embedding model updates; SAL’s keyword scoring is deterministic\.

Hybrid architectures that combine semantic retrieval with SAL’s structural graph traversal are a natural direction for future work\.

## 10Threats to Validity

We organise threats following the Wohlin et al\. framework for empirical software engineering studies\[[28](https://arxiv.org/html/2607.22572#bib.bib44)\], covering internal, external, construct, and conclusion validity\. For each threat we state its severity, our mitigation, and the residual risk\.

### 10\.1Internal Validity

T\-I1: Confounding between LLM non\-determinism and condition differences\.The LLM backend \(gpt\-4o\-mini\) is a stochastic process\. We used temperatureT=0T=0for all evaluation runs to suppress sampling variance\. The residual risk is that the provider may update the model endpoint between evaluation runs\. We mitigate this by recording themodelfield from each API response and verifying it is constant across the 500\-question run\.

T\-I2: Evaluation harness as confounder\.The Python harness \(experiments/run\_sql\_evaluation\.py\) acts as both the stimulus generator and the response scorer\. A bug in the semantic comparison logic could inflate or deflate EGT independently of SQL quality\. We mitigate this by manual verification on randomly sampled query–result pairs, running a baseline condition whose EGT is consistent with prior work, and open\-sourcing the harness for audit\. Residual risk: column\-order sensitivity yields a conservative bias \(slightly underestimating correctness\)\.

T\-I3: Network and Oracle latency variability\.Latency measurements \(RQ2\) were collected on a single machine over a single run\. Oracle ADB response times can vary with shared\-cloud load\. We ran all conditions sequentially within a bounded time window and observed no anomalous timeout events\. Absolute latency values should be treated as indicative; the relative ordering is the primary scientific claim\.

T\-I4: SAL detection designed with dataset knowledge\.The keyword maps and JOIN\-chain adjacency graph in SAL v2 were developed with awareness of TPC\-H table names\. This is a form of dataset leakage\. We acknowledge this as the primary internal validity threat\. Replication on held\-out schemas would resolve it\.

### 10\.2External Validity

T\-E1: Single schema \(TPC\-H\)\.All experiments use the TPC\-H schema\. Enterprise schemas are structurally richer and may contain naming ambiguity, nullable keys, and non\-relational types\. Planned replication on larger benchmarks \(e\.g\., TPC\-DS\) and real enterprise schemas would bound generalisability\.

T\-E2: Single LLM family \(GPT\-4o\-mini\)\.SAL v2 was evaluated with one model\. Different LLMs have different hallucination rates and sensitivity to hint formatting\. The architectural claim is expected to hold across models, but effect size is model\-dependent\.

T\-E3: Single deployment target \(Oracle ADB\)\.Hidx validation and error handling are tuned to Oracle dialect and ORA error codes\. Porting to other engines requires the adapter changes described in Section[9\.3](https://arxiv.org/html/2607.22572#S9.SS3); we have not measured this\.

T\-E4: Synthetic question dataset\.The 500 questions are synthetic and do not include multi\-turn dialogue or context\-dependent references\. Real enterprise questions may be more colloquial and ambiguous\.

### 10\.3Construct Validity

T\-C1: EGT as a proxy for user value\.EGT is a strict correctness criterion but does not capture query\-plan quality or user\-facing utility \(e\.g\., additional informative columns\)\.

T\-C2: Semantic match via set equality\.The comparator is sensitive to formatting and canonicalisation choices\. Rounding and session formatting differences may cause conservative false negatives\.

T\-C3: Hidx score as a grounding proxy\.A high Hidx score indicates identifier validity but does not guarantee semantic correctness \(H4 failures\)\.

T\-C4: Token cost as an economic proxy\.Token deltas proxy API cost, but dollar cost varies by provider and time\. We therefore report token counts rather than currency\.

### 10\.4Conclusion Validity

T\-V1: Single experimental run per condition\.Each condition was evaluated once\. WithT=0T=0and fixed model weights, re\-running would be deterministic; the practical risk is provider drift\.

T\-V2: No statistical significance testing\.The 0\.6 pp difference between C2 and C3b is within a wide binomial margin of error atN=500N=500; we therefore claim parity rather than strict superiority\.

T\-V3: Researcher degrees of freedom in SAL tuning\.SAL v2 hyperparameters were set based on v1 failure inspection without cross\-validation\. Independent test sets are required\.

T\-V4: Comparison condition \(C2\) not independently replicated\.The static hint baseline may be sensitive to environment differences\. A fully controlled comparison would run C2 and C3b in the same harness invocation\.

### 10\.5Threat Summary

Table 14:Threat Summary: Severity and Mitigation StatusThe two high\-severity threats \(dataset leakage and schema generalisability\) share the same remedy: replication on held\-out schemas with independently constructed keyword maps\.

## 11Discussion

### 11\.1What the Results Actually Show

The headline finding, SAL v2 at 62\.6 % EGT vs\. static hint at 62\.0 %, understates the practical significance of the work\. The correct interpretation is not that SAL v2 is marginally better than a static hint, but that SAL v2*achieves parity with the static hint while being architecturally superior in every other dimension*: it costs less per query, it enforces schema access boundaries dynamically, it is self\-updating when the schema changes, and it provides a structured audit trail of which tables and columns were grounded for each response\.

The ablation gap that does matter is C1 vs\. C3b:2\.2%→62\.6%2\.2\\,\\%\\rightarrow 62\.6\\,\\%, a28×28\\timesimprovement from zero grounding to SAL v2\. This gap answers the motivating question:*does live schema injection into an MCP pipeline make LLM\-generated SQL practically usable on a real Oracle database?*The answer is yes\.

### 11\.2The SAL v1→\\rightarrowv2 Transition

The 4\.2 pp recovery from v1 \(58\.4 %\) to v2 \(62\.6 %\) is attributable to two mechanisms:

- •JOIN\-chain expansionaccounts for the majority of the medium\-tier gain \(\+8 pp\)\. Multi\-hop queries that previously missed a bridge table now receive the correct column set on the first attempt\.
- •Complexity gateaccounts for most of the complex\-tier gain \(\+3 pp\) by triggering full multi\-table inclusion when complexity signals are present\.

Together these components validate the architectural intuition: the primary failure mode of binary keyword matching is*join\-path blindness*, omitting structurally necessary but linguistically absent tables\.

### 11\.3The Hidx Layer as an Independent Contribution

Without the Hidx post\-validator and retry loop, SAL v2 would score 55\.2 % EGT \(direct\-pass only\)\. The Hidx layer recovers 37 queries \(7\.4 pp\) that would otherwise fail\.

The ratio of Hidx auto\-corrections \(22\) to LLM retries \(15\) suggests that approximately 60 % of Hidx\-recoverable failures are simple identifier substitutions resolvable without a second LLM call\.

### 11\.4Why Complex Queries Remain Hard

The 40\.7 % complex\-tier EGT ceiling is not a schema\-linking problem; it is a reasoning problem\. The steep cliff from medium to complex corresponds to the transition from direct joins to correlated sub\-queries and multi\-level aggregations\.

At the aggregate level, SAL v2 reaches 62\.6 % EGT, leaving 37\.4 % unsolved \(Table[10](https://arxiv.org/html/2607.22572#S7.T10)\)\. This ceiling likely reflects a mix of base\-model capability \(GPT\-4o\-mini\), TPC\-H complexity artefacts, and limited plan\-level search in our current SAL instantiation; disentangling these is future work\.

For the complex queries that fail, improvement requires a stronger base model, a chain\-of\-thought decomposition strategy, or a query rewriting layer that breaks questions into simpler sub\-problems and composes the results\.

Future directions\.Three extensions are most immediately valuable: \(i\) cross\-schema generalisation beyond TPC\-H to test whether SAL’s schema\-localisation transfers with independently constructed keyword maps; \(ii\) embedding\-augmented detection to improve recall for paraphrases and domain synonyms in table/column selection; and \(iii\) chain\-of\-thought scaffolding for complex questions via structured decomposition into intermediate sub\-queries whose results are composed into a final SQL statement\.

## 12Limitations

We summarise the principal limitations of this work concisely, without attempting to mitigate them here; related threats to validity and broader implications are discussed in Sections[10](https://arxiv.org/html/2607.22572#S10)and[11](https://arxiv.org/html/2607.22572#S11), respectively\.

1. 1\.Single schema\.All measurements are on the TPC\-H schema\. Keyword maps and JOIN\-chain adjacency were designed with knowledge of TPC\-H table names\.
2. 2\.Single model\.All LLM calls usegpt\-4o\-mini\. Absolute EGT values are model\-specific\.
3. 3\.Single RDBMS\.The system is tested exclusively on Oracle ADB\. The validator, error handling, and introspection are Oracle\-specific\.
4. 4\.No statistical significance for C2 vs\. C3b\.The 0\.6 pp EGT difference between static and SAL v2 falls within a wide 95 % binomial confidence interval\.
5. 5\.Synthetic benchmark\.TPC\-H questions do not include conversational, ambiguous, or multi\-turn interactions\.
6. 6\.No human evaluation\.Pedagogical utility and explanation quality are not measured\.
7. 7\.Single evaluation run per condition\.Provider\-side model updates between runs could introduce systematic shifts\.
8. 8\.Closed\-source model dependency\.Reproducibility is sensitive to API/provider drift and pricing changes\.

## 13Ethics and Responsible Deployment

### 13\.1Intended Use

SAL is designed for*read\-only, pedagogical SQL assistance*: helping students and analysts learn to write correct Oracle SQL against a known schema\. It is not designed for autonomous database administration, schema modification, bulk data extraction, or any context where an incorrect SQL result could cause harm\.

### 13\.2Risk of Over\-Reliance

At 62\.6 % EGT, SAL v2 returns a wrong or non\-executing answer for 37\.4 % of queries\. Deployments should surface the Hidx signal alongside responses and include a clear disclaimer that LLM\-generated SQL must be reviewed before use\.

### 13\.3Data Privacy

In educational deployments, user questions constitute learner activity data\. Operators must:

1. 1\.Store query logs within the institution’s data perimeter\.
2. 2\.Execute LLM API calls under a data\-processing agreement \(DPA\) that prohibits use of submitted content for training\.
3. 3\.Obtain appropriate consent consistent with FERPA \(US\), GDPR \(EU\), or applicable local regulation\.
4. 4\.Implement log retention limits \(e\.g\., 90 days for operational logs\)\.

### 13\.4Schema Confidentiality

When deployed against a proprietary enterprise schema, column names injected into the LLM prompt may constitute sensitive metadata\. Operators should consider role\-scoped hint injection \(Section[9\.2](https://arxiv.org/html/2607.22572#S9.SS2)\) and, where required, on\-premise LLM deployment\.

### 13\.5Conflict of Interest

Ganesh Naik serves on the*IEEE Access*Editorial Board\. This role had no involvement in the handling of this manuscript, including peer review or the publication decision\.

## 14Conclusion

We presentedSchema\-Aware Localisation \(SAL\), a zero\-retraining grounding architecture that eliminates schema hallucination in LLM\-generated Oracle SQL by dynamically injecting execution\-verified column context at query time via the Model Context Protocol\. The system combines scored keyword detection, JOIN\-chain expansion, a complexity gate, and an online Hidx validation layer with automatic correction and LLM retry, all operating without modification to the underlying language model\.

A three\-condition ablation on 500 TPC\-H questions against a live Oracle Autonomous Database instance produces four findings:

1. 1\.Schema context is a hard prerequisite\.Removing schema hints collapses EGT from 62\.6 % to 2\.2 %\.
2. 2\.SAL v2 matches the static baseline at lower cost\.SAL v2 achieves 62\.6 % EGT, equalling the 62\.0 % of a full\-schema static hint, while reducing mean prompt tokens and maintaining a low median latency overhead\.
3. 3\.Dynamic detection quality matters\.SAL v1 scores 58\.4 % EGT; SAL v2 recovers 4\.2 pp via scored detection and JOIN\-chain expansion\.
4. 4\.Online verification adds independent value\.The Hidx post\-validator recovers 37 queries \(7\.4 pp EGT\) that would otherwise fail\.

The primary remaining barrier to higher EGT is LLM reasoning depth on complex analytical queries, an orthogonal problem that schema grounding cannot address\.

## Acknowledgements

All experiments were conducted on synthetic TPC\-H data; no personally identifiable information was used\.

## References

- \[1\]Anthropic\(2024\)Model context protocol specification\.Note:[https://modelcontextprotocol\.io](https://modelcontextprotocol.io/)Cited by:[§1](https://arxiv.org/html/2607.22572#S1.SSx1.p1.1),[§2\.5](https://arxiv.org/html/2607.22572#S2.SS5.p2.1),[§4\.5](https://arxiv.org/html/2607.22572#S4.SS5.p1.1)\.
- \[2\]Y\. Caiet al\.\(2020\)IGSQL: database schema interaction graph for conversational text\-to\-sql\.InProc\. ACL,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.
- \[3\]R\. Caoet al\.\(2021\)LGESQL: line graph enhanced text\-to\-sql model with mixed local and non\-local relations\.InProc\. ACL,Cited by:[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p2.1)\.
- \[4\]B\. Chenet al\.\(2021\)ShadowGNN: graph neural networks for multi\-turn text\-to\-sql parsing\.InProc\. AAAI,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.
- \[5\]J\. Devlin, M\. Chang, K\. Lee, and K\. Toutanova\(2019\)BERT: pre\-training of deep bidirectional transformers for language understanding\.InProc\. NAACL,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p3.1)\.
- \[6\]L\. Dong and M\. Lapata\(2016\)Language to logical form with neural attention\.InProc\. ACL,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.
- \[7\]X\. Donget al\.\(2023\)C3: zero\-shot text\-to\-sql with chatgpt\.Note:arXiv preprint arXiv:2307\.07306Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p4.1)\.
- \[8\]D\. Gaoet al\.\(2023\)Text\-to\-sql empowered by large language models: a benchmark evaluation\.Note:arXiv preprint arXiv:2308\.15363Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p4.1),[Table 1](https://arxiv.org/html/2607.22572#S2.T1.3.1.3.2.1),[§9\.6](https://arxiv.org/html/2607.22572#S9.SS6.p1.1)\.
- \[9\]J\. Guoet al\.\(2019\)IRNet: a general framework for complex text\-to\-sql parsing\.InProc\. ACL,Cited by:[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p2.1)\.
- \[10\]G\. G\. Hendrix, E\. D\. Sacerdoti, D\. Sagalowicz, and J\. Slocum\(1978\)Developing a natural language interface to complex data\.ACM Transactions on Database Systems\.Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p1.1)\.
- \[11\]Z\. Jiet al\.\(2023\)Survey of hallucination in natural language generation\.ACM Comput\. Surv\.55\(12\),pp\. 1–38\.Cited by:[§2\.3](https://arxiv.org/html/2607.22572#S2.SS3.p1.1),[§8\.1](https://arxiv.org/html/2607.22572#S8.SS1.p1.1)\.
- \[12\]F\. Leiet al\.\(2020\)SemQL: a meaning representation for natural language to sql\.InProc\. ACL,Cited by:[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p1.1)\.
- \[13\]P\. Lewiset al\.\(2020\)Retrieval\-augmented generation for knowledge\-intensive nlp tasks\.InProc\. NeurIPS,Cited by:[§2\.5](https://arxiv.org/html/2607.22572#S2.SS5.p1.1)\.
- \[14\]J\. Liet al\.\(2023\)BIRD: a big bench for large\-scale database grounded text\-to\-sql evaluation\.InProc\. NeurIPS,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p1.1)\.
- \[15\]X\. V\. Linet al\.\(2020\)BRIDGE: bridging the gap between neural text\-to\-sql and sql execution\.InProc\. ACL,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p3.1)\.
- \[16\]J\. Liuet al\.\(2023\)Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation\.InProc\. NeurIPS,Cited by:[§2\.3](https://arxiv.org/html/2607.22572#S2.SS3.p2.1)\.
- \[17\]N\. F\. Liu, K\. Lin, J\. Hewitt, A\. Paranjape, M\. Bevilacqua, F\. Petroni, and P\. Liang\(2023\)Lost in the middle: how language models use long contexts\.InProceedings of the 61st Annual Meeting of the Association for Computational Linguistics \(ACL\),Cited by:[item 2](https://arxiv.org/html/2607.22572#S9.I4.i2.p1.1)\.
- \[18\]J\. Maynez, S\. Narayan, B\. Bohnet, and R\. McDonald\(2020\)On faithfulness and factuality in abstractive summarization\.InProc\. ACL,Cited by:[§2\.3](https://arxiv.org/html/2607.22572#S2.SS3.p1.1)\.
- \[19\]A\. Niet al\.\(2023\)SQL generation with execution\-guided decoding\.InProc\. ACL,Cited by:[§2\.3](https://arxiv.org/html/2607.22572#S2.SS3.p2.1)\.
- \[20\]Oracle Corporation\(2024\)Oracle apex ai assistant\.Note:[https://apex\.oracle\.com/en/platform/features/ai/](https://apex.oracle.com/en/platform/features/ai/)Accessed May 12, 2026Cited by:[§2\.4](https://arxiv.org/html/2607.22572#S2.SS4.p3.1)\.
- \[21\]Oracle Corporation\(2024\)Oracle database SQL language reference 23c\.Note:[https://docs\.oracle\.com/en/database/oracle/oracle\-database/23/sqlrf/](https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/)Cited by:[§2\.4](https://arxiv.org/html/2607.22572#S2.SS4.p2.1)\.
- \[22\]M\. Pourreza and D\. Rafiei\(2023\)DIN\-sql: decomposed in\-context learning of text\-to\-sql with self\-correction\.InProc\. NeurIPS,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p4.1),[§2\.3](https://arxiv.org/html/2607.22572#S2.SS3.p2.1),[Table 1](https://arxiv.org/html/2607.22572#S2.T1.3.1.4.3.1),[§9\.6](https://arxiv.org/html/2607.22572#S9.SS6.p1.1)\.
- \[23\]C\. Raffelet al\.\(2020\)Exploring the limits of transfer learning with a unified text\-to\-text transformer\.Journal of Machine Learning Research\.Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p3.1)\.
- \[24\]T\. Schicket al\.\(2023\)Toolformer: language models can teach themselves to use tools\.InProc\. NeurIPS,Cited by:[§2\.5](https://arxiv.org/html/2607.22572#S2.SS5.p1.1)\.
- \[25\]Transaction Processing Performance Council \(TPC\)\(2022\)TPC Benchmark H Standard Specification\.Note:Revision 2\.18\.0Accessed 2026\-05\-12External Links:[Link](http://www.tpc.org/tpch/)Cited by:[§3\.4](https://arxiv.org/html/2607.22572#S3.SS4.p1.1),[Definition 3](https://arxiv.org/html/2607.22572#Thmdefinition3.p1.1)\.
- \[26\]B\. Wanget al\.\(2020\)RAT\-sql: relation\-aware schema encoding and linking for text\-to\-sql parsers\.InProc\. ACL,Cited by:[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p1.1),[§2\.2](https://arxiv.org/html/2607.22572#S2.SS2.p2.1),[Table 1](https://arxiv.org/html/2607.22572#S2.T1.3.1.2.1.1)\.
- \[27\]J\. Wei, X\. Wang, D\. Schuurmans, M\. Bosma, F\. Xia, E\. Chi, Q\. V\. Le, and D\. Zhou\(2022\)Chain\-of\-thought prompting elicits reasoning in large language models\.InAdvances in Neural Information Processing Systems,Cited by:[item 2](https://arxiv.org/html/2607.22572#S8.I5.i2.p1.1)\.
- \[28\]C\. Wohlin, P\. Runeson, M\. H”ost, M\. C\. Ohlsson, B\. Regnell, and A\. Wesslén\(2012\)Experimentation in software engineering\.Springer\.Cited by:[§10](https://arxiv.org/html/2607.22572#S10.p1.1)\.
- \[29\]W\. A\. Woods\(1973\)Progress in natural language understanding: an application to lunar geology\.InProc\. AFIPS Natl\. Comput\. Conf\.,pp\. 441–450\.Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p1.1)\.
- \[30\]X\. Xu, C\. Liu, and D\. Song\(2017\)SQLNet: generating structured queries from natural language without reinforcement learning\.Note:arXiv preprint arXiv:1711\.04436Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.
- \[31\]S\. Yaoet al\.\(2023\)ReAct: synergizing reasoning and acting in language models\.InProc\. ICLR,Cited by:[§2\.5](https://arxiv.org/html/2607.22572#S2.SS5.p1.1)\.
- \[32\]T\. Yu, Z\. Li, Z\. Zhang, R\. Zhang, and D\. Radev\(2018\)TypeSQL: knowledge\-based type\-aware neural text\-to\-sql generation\.InProc\. NAACL,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.
- \[33\]T\. Yuet al\.\(2021\)GRAPPA: grammar\-augmented pre\-training for table semantic parsing\.InProc\. ICLR,Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p3.1)\.
- \[34\]T\. Yu, R\. Zhang, K\. Yang, M\. Yasunaga, D\. Wang, Z\. Li, J\. Ma, I\. Li, Q\. Yao, S\. Roman,et al\.\(2018\)Spider: a large\-scale human\-labeled dataset for complex and cross\-domain semantic parsing and text\-to\-sql task\.InProc\. EMNLP,pp\. 3911–3921\.Cited by:[§1](https://arxiv.org/html/2607.22572#S1.p1.1),[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p1.1),[4th item](https://arxiv.org/html/2607.22572#S6.I1.i4.p1.1)\.
- \[35\]V\. Zhong, C\. Xiong, and R\. Socher\(2017\)Seq2SQL: generating structured queries from natural language using reinforcement learning\.Note:arXiv preprint arXiv:1709\.00103Cited by:[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p1.1),[§2\.1](https://arxiv.org/html/2607.22572#S2.SS1.p2.1)\.