TRUST-SQL: Unknown Schema Text-to-SQL

• TRUST-SQL is a text-to-SQL framework designed for unknown-schema environments, leveraging active metadata discovery and a structured four-phase protocol.
• It integrates dual-track GRPO to separate schema exploration rewards from SQL execution, significantly improving performance and reducing hallucinations.
• The framework supports multi-turn tool-based interaction and outperforms baseline models on benchmarks like Spider and BIRD, demonstrating robust schema verification.

TRUST-SQL, short for Truthful Reasoning with Unknown Schema via Tools, is a text-to-SQL framework for the Unknown Schema scenario, in which the model is not given the full database schema in advance and must instead discover and verify the relevant subset through tool use before producing SQL (Jian et al., 17 Mar 2026). It departs from the Full Schema Assumption common in benchmark-oriented text-to-SQL research and recasts the task as multi-turn decision making under partial observability, with a structured protocol, explicit verified-schema state, and a reinforcement-learning objective that separates schema-exploration credit from final SQL-execution credit. In adjacent literature, the label “trust” in SQL has also been used for reliability benchmarking, trust-aware intrusion detection, access control, and trusted execution; within that broader landscape, TRUST-SQL refers specifically to the 2026 tool-integrated text-to-SQL system (Jian et al., 17 Mar 2026).

1. Unknown-schema text-to-SQL as a partially observable problem

The motivating claim of TRUST-SQL is that much of contemporary text-to-SQL work assumes a setting that is convenient for benchmarks but unrealistic for enterprise databases: the model receives the complete schema in context, and query generation is treated as a static translation problem. TRUST-SQL replaces that assumption with the Unknown Schema scenario, in which the complete schema is not available upfront and the agent must interact with the database to uncover only the subset of metadata needed for the current question (Jian et al., 17 Mar 2026).

This formulation is motivated by the properties the paper attributes to real-world enterprise environments: databases may contain hundreds of tables, metadata may be noisy or stale, schemas evolve over time, and context windows are finite. In such settings, pre-injecting the full schema can be harmful because irrelevant tables and columns distract the model, outdated metadata can mislead it, and the schema text can stress or exceed the context budget. TRUST-SQL therefore emphasizes active schema discovery and verification rather than passive schema consumption.

The framework formalizes the task as a Partially Observable Markov Decision Process,

$$(\mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{R}, \Omega, \mathcal{Z}, \gamma),$$

over discrete steps $t=0,1,\dots,T$ (Jian et al., 17 Mar 2026). The hidden environment state $s_t$ is the complete database schema; observations $o_t$ are produced by tool execution; and the agent’s context is

$c_t = (q, h_t, \mathcal{K}_t),$

where $q$ is the user question, $h_t$ is the interaction history, and $\mathcal{K}_t$ is the accumulated Verified Schema Knowledge, initialized as

$\mathcal{K}_0 = \emptyset.$

The action space is partitioned into four strict categories—Explore, Propose, Generate, and Confirm—and the trajectory is

$\tau = \{(c_t, a_t, o_t)\}_{t=0}^{T}.$

The optimization objective is

$t=0,1,\dots,T$0

The formalization is not merely decorative. It encodes the central design claim that the agent never sees the whole schema directly and must instead maintain a belief-like internal state grounded in interaction history and verified metadata. This is the basis for both the protocol design and the later reinforcement-learning decomposition.

2. Four-phase protocol and tool-grounded reasoning

TRUST-SQL organizes interaction through a structured four-phase protocol: Explore, Propose, Generate, Confirm (Jian et al., 17 Mar 2026). The protocol is the operational core of the system because it constrains when metadata can be collected, when schema commitments must be made, and when SQL can be generated.

Phase	Primary purpose	Output form
Explore	Query metadata only	explore_schema with <tool_call>
Propose	Commit to verified relevant schema	propose_schema with <schema>
Generate	Produce and test candidate SQL	generate_sql with <tool_call>
Confirm	Submit final SQL answer	confirm_answer with <answer>

In the Explore phase, the agent is allowed to query the database for metadata only. The main executable function is execute_sql_query, exposed with parameters db_id and sql, and described as returning “partial results containing column names” with a maximum of 30 records (Jian et al., 17 Mar 2026). Exploration may inspect tables, columns, foreign keys, and SQLite catalog metadata; the paper’s case study also shows value-level probing such as SELECT DISTINCT "Charter Funding Type" FROM frpm;. This matters because the framework treats grounding as extending beyond structural schema discovery to value verification when question semantics require it.

In the Propose phase, the agent must explicitly summarize the subset of schema that has been verified. The output is a structured <schema> block, for example with "tables", "columns", and optionally "joins". The paper characterizes this as a “mandatory cognitive checkpoint”, because it forces the model to separate verified schema knowledge from speculative parametric prior. The system prompt is correspondingly strict: “You must never hallucinate tables or columns,” “All schema knowledge MUST come from metadata queries only,” and “Include ONLY tables/columns actually verified through tag_explore” (Jian et al., 17 Mar 2026).

In the Generate phase, the agent produces candidate SQL using only the latest proposed schema and may execute that SQL to inspect whether it runs correctly. If required elements are missing, the prompt instructs the agent to return to Explore or Propose. In the Confirm phase, the agent emits the final SQL inside an <answer> block, and the prompt explicitly requires that the final output contain only the SQL query and not result rows.

The framework also imposes a rigid per-turn format. Each turn must contain exactly one > ... block, exactly one <action>...</action> block naming one of the four actions, and the correct action-specific content tag. The paper defines a FormatCheck function and later uses compliance with this protocol as part of the reward design (Jian et al., 17 Mar 2026).

3. Dual-Track GRPO and reward decomposition

TRUST-SQL uses a two-stage training pipeline: supervised fine-tuning to warm up structured exploration behavior, followed by reinforcement learning based on Group Relative Policy Optimization (GRPO) (Jian et al., 17 Mar 2026). The central claim is that standard trajectory-level rewards are poorly matched to multi-turn tool use because early actions retrieve schema while later actions generate and execute SQL, so credit assignment becomes heterogeneous.

To address this, the paper introduces Dual-Track GRPO. For each question $t=0,1,\dots,T$1, the model samples $t=0,1,\dots,T$2 trajectories, and each trajectory $t=0,1,\dots,T$3 is split into two optimization tracks $t=0,1,\dots,T$4. The schema track ends at the Propose step, while the full track spans the entire interaction. Each track receives a different reward: $t=0,1,\dots,T$5 Trackwise normalized advantages are then computed as

$t=0,1,\dots,T$6

The paper’s novel mechanism is token-level masked advantages. The schema-track advantage is broadcast only to tokens generated up to the Propose checkpoint; later tokens receive zero schema advantage. The full-track advantage applies over the trajectory’s active tokens. The paper describes this as “strictly finer-grained than trajectory-level weighting,” because it prevents exploration rewards from incorrectly reinforcing generation tokens and vice versa (Jian et al., 17 Mar 2026).

The total loss is

$t=0,1,\dots,T$7

with $t=0,1,\dots,T$8 controlling the relative weight of the schema track. The paper does not reproduce the full clipped GRPO objective in the main text, but it specifies the reward components. The execution reward is

$t=0,1,\dots,T$9

the format reward is

$s_t$0

and the schema reward is defined as

$s_t$1

The appendix-level ablations reported in the paper further identify the best schema-reward configuration as Sparse + Coupled, meaning binary schema matching conditioned on successful execution. This is presented as superior to both sparse uncoupled and dense coupled variants, because uncoupled reward encourages overexploration and dense grading introduces conflicting pressure between recall and unnecessary-column avoidance (Jian et al., 17 Mar 2026).

4. Data construction, implementation, and benchmark performance

The implementation is built on Qwen3-4B and Qwen3-8B and uses SLIME (Jian et al., 17 Mar 2026). The supervised stage uses 9.2k source questions and retains 70,970 trajectories from annotation models. The RL stage uses 11,642 retained training questions from Spider and BIRD after difficulty filtering. Additional implementation details given in the paper include rollout count 8, RL epochs 3, RL batch size 32, $s_t$2, training turn budget 10, and inference budget 15 turns for majority voting or sampling. Hardware allocation is reported as 16×A100 for both 4B and 8B SFT, 8×A100 for 4B RL, and 32×A100 for 8B RL; the 4B model uses synchronous training and the 8B model asynchronous training (Jian et al., 17 Mar 2026).

The experimental suite spans five benchmarks: BIRD-Dev, Spider-Test, Spider-DK, Spider-Syn, and Spider-Realistic. The primary metric is Execution Accuracy (EX), with both greedy decoding (“Gre”) and execution-based majority voting (“Maj”). A critical condition is evaluation without pre-loaded metadata, meaning the model is not given the full schema at the start and must retrieve schema information through tool interactions (Jian et al., 17 Mar 2026).

Benchmark	TRUST-SQL-4B (Gre / Maj)	TRUST-SQL-8B (Gre / Maj)
BIRD-Dev	64.9 / 67.2	65.8 / 67.7
Spider-Test	82.8 / 85.0	83.9 / 86.5
Spider-DK	71.6 / 73.8	72.1 / 75.7
Spider-Syn	74.7 / 77.3	75.4 / 77.4
Spider-Realistic	79.9 / 82.5	82.1 / 84.1

Across these five benchmarks, the paper reports an average absolute improvement of 30.6% for the 4B variant and 16.6% for the 8B variant over their respective base models (Jian et al., 17 Mar 2026). On BIRD specifically, TRUST-SQL-4B improves over Qwen3-4B from 29.3% to 64.9%, a 35.6% absolute gain. The paper also states that Dual-Track GRPO yields a 9.9% relative improvement over standard GRPO on BIRD-Dev.

The comparison is intentionally strong because several baselines—OmniSQL, SQL-R1, SQL-Trail, and MTIR-SQL—operate under schema prefilling. Despite not receiving pre-loaded metadata, TRUST-SQL often matches or surpasses these baselines. On BIRD-Dev, the paper reports the best score for TRUST-SQL-8B at 65.8 Gre / 67.7 Maj (Jian et al., 17 Mar 2026).

5. Empirical behavior, protocol effects, and acknowledged limitations

The paper’s pilot study on BIRD-Dev with Qwen3-8B compares three protocols: EC, EGC, and EPGC (Jian et al., 17 Mar 2026). The reported finding is that adding Generate reduces hallucinations somewhat, but adding Propose reduces them dramatically: hallucinations fall from 26.4% of failures in EC to 2.8% in EPGC, described as a 9.4× reduction. This makes the Propose checkpoint the main architectural explanation for the system’s “truthful reasoning” claim.

The ablations on reward weighting further support the separation of exploration and generation. In the $s_t$3 study, a pure execution-only baseline with $s_t$4 reaches 60.9% EX, naive reward aggregation reaches 58.7%, Dual-Track GRPO with $s_t$5 reaches 64.5%, and excessive schema weighting at $s_t$6 collapses performance to 54.2% because the model over-optimizes exploration and keeps interacting too long (Jian et al., 17 Mar 2026). This is presented as evidence that schema reward should be separated rather than mixed into a single terminal signal.

A notable empirical result is that schema prefill barely helps TRUST-SQL, and can even hurt it. For TRUST-SQL-4B, the paper reports BIRD changing from 64.9 to 64.8 with prefill, Spider from 82.8 to 83.1, Spider-DK from 71.6 down to 69.2, and Spider-Syn from 74.7 down to 72.5 (Jian et al., 17 Mar 2026). In contrast, the raw Qwen3-4B base model drops by 17.0 absolute points on BIRD when metadata is not preloaded. The stated interpretation is that TRUST-SQL learns to retrieve only the necessary metadata, making full-schema injection redundant and sometimes noisy.

The case study on california_schools illustrates another design point. Under the Unknown Schema setting, the model lists tables through sqlite_master, retrieves table definitions, probes actual values using SELECT DISTINCT "Charter Funding Type" FROM frpm;, proposes a verified schema containing frpm and schools, generates SQL using the discovered value 'Directly funded', and confirms the final query (Jian et al., 17 Mar 2026). In the schema-prefill condition, by contrast, the model sees structural schema immediately, skips value exploration, and produces a broader query that retrieves all charter schools opened after the date. This suggests that active exploration serves not only to compensate for hidden schema but also to encourage evidence-driven value grounding.

The paper nonetheless states several limitations. First, there is inference overhead from multi-turn interaction because each step may involve a live database call. Second, experiments are limited to the SQLite dialect because the benchmark datasets use SQLite. Third, the method uses a fixed turn budget at training time; the authors suggest future work on dynamically adapting the budget based on database complexity (Jian et al., 17 Mar 2026). The turn-budget analysis also shows instability when the horizon is too large, with 12 turns causing overexploration.

6. Related meanings of “trust” in SQL research

The TRUST-SQL framework belongs to a broader family of SQL research in which “trust” denotes different technical objectives rather than a single unified paradigm. A nearby but distinct use is TrustSQL, a 2024 benchmark for text-to-SQL reliability that defines a reliable system as one that generates correct SQL for answerable questions and abstains on unanswerable ones, evaluated by a penalty-based reliability score

$s_t$7

That benchmark emphasizes abstention, answerability detection, and selective reliability rather than unknown-schema exploration (Lee et al., 2024).

A second line of work uses trust in a behavioral or security-monitoring sense. The SSF (SQL Injection Shield Framework) constructs trusted profiles of legitimate SQL behavior from clean historical logs, stores them in XML plus association-rule profiles, and performs anomaly detection followed by misuse detection before query execution at the database end. It is described as conceptually close to a “TRUST-SQL-style trust-aware SQL IDS,” but it does not define an explicit trust calculus, trust propagation, or adaptive trust score (Ali et al., 2020).

A third line concerns trust in execution, confidentiality, and authorization. “Strong and Provably Secure Database Access Control” formalizes SQL security through database integrity and data confidentiality over runs, with a labeled transition system, an active attacker model, and a policy decision point

$s_t$8

thereby treating trustworthy SQL authorization as a semantic and noninterference-like property rather than a simple ACL lookup (Guarnieri et al., 2015). “Information Flows in Encrypted Databases” similarly shows that encrypted columns and client-held keys are insufficient by themselves, and proposes SecureSQL, which partitions query processing between an untrusted server and a trusted client while enforcing absence of information flows from stronger to weaker encrypted representations (Vaswani et al., 2016).

Trusted execution and trust minimization yield further variants. QShield uses Intel SGX, a lightweight secret-sharing scheme for multi-user access control, and a signed trust proof intended to audit per-query workflow correctness in SQL-like outsourced processing (Chen et al., 2019). Qrlew places trust in a privacy-expert rewriting layer that parses SQL into a metadata-rich intermediate representation called a Relation and rewrites standard SQL into differentially private SQL executable on ordinary datastores (Grislain et al., 2024). At the opposite end of the trust spectrum, FHE-SQL explicitly avoids trusted execution environments and instead uses fully homomorphic encryption, with a UC-style theorem claiming that the protocol realizes an ideal functionality against a static malicious server under secure FHE and signature assumptions (Tseng et al., 17 Oct 2025).

Taken together, these systems indicate that “trust” in SQL research is polysemous. It can refer to truthful schema grounding and tool-based reasoning, selective reliability with abstention, trusted profiles for intrusion detection, semantically secure authorization, trusted runtime processing, differentially private rewriting, or end-to-end cryptographic protection. TRUST-SQL in the narrow sense is the unknown-schema text-to-SQL framework, but it sits within a larger technical vocabulary in which trust is operationalized through verification, policy, interaction structure, or cryptographic assumptions rather than through a single common formalism (Jian et al., 17 Mar 2026).