PaperlayerView exact revision on arXiv

Source-linked AI summary

Never the Number: Structural Abstention for AI Systems Whose Answers Are Consumed as Fact

Zhelun, Wu

arXiv:2608.13926v1cs.AIcs.CLcs.DB

TL;DR

Fact-consumed AI systems can produce fluent wrong answers that users cannot distinguish from correct ones. The paper proposes structural abstention, separating a generative shell from a deterministic kernel, and reports that capability coverage became explicit while data iteration mattered more than architectural changes. The central claim remains untested directly against generative systems.

  • Problem

    Fact-consumed systems can produce plausible wrong answers that recipients cannot distinguish from correct ones, making accuracy alone insufficient for reliable deployment.

  • Method

    Structural abstention separates a generative shell that shapes questions from a deterministic kernel that computes values, declining requests the kernel cannot express.

  • Results

    The question pool became an explicit capability contract with countable coverage gaps, while data iteration produced larger quality movements than architectural changes.

  • Takeaways & Limitations

    The pattern makes system capability and coverage legible for deployments where users cannot verify answers and question shapes repeat.

  • Takeaways & Limitations

    The central claim that visible failure beats fluent failure has not been directly measured against a generative system, and the pattern has been built once in one domain.

Abstract

from arXiv · show

Large language models have made natural language interfaces to databases (NLIDB) newly credible, but LLM text-to-SQL systems fail in a way that matters for deployment: a hallucinated column or a mis-aggregated total yields a fluent wrong answer, indistinguishable at the point of use from a right one. Where the consumer cannot inspect the generated query, as in enterprise AI deployments and operational dashboards, and increasingly where the consumer is a tool-using agent rather than a person, accuracy alone is insufficient: nothing marks which answers to distrust. This is a reliability problem before it is an accuracy problem. We propose an architectural pattern for such systems, a trusted kernel with a generative shell, resting on one invariant: a component that can fabricate may influence which question the system answers, never which value it returns. A generative shell interprets underspecified input and phrases replies; a deterministic kernel matches fully specified questions against a bounded set of answerable question shapes and compiles them to queries by deterministic execution. The two meet at a confirmation the user reads before any value is computed, and requests the kernel cannot express are declined rather than approximated. We call this structural abstention, and distinguish it from the statistical abstention of selective prediction and calibrated confidence: refusal here needs no confidence estimate, because unanswerable requests are unrepresentable. We specify the pattern implementation-independently, give a five-decision recipe and work it across three domains, extend the invariant from returned values to the actions of agentic systems, and report a two-year production case study alongside two generative alternatives, a fine-tuned parser and a tool-retrieval agent. We close against enterprise and reliability benchmarks published since.

1 Introduction · 2 Related Work

The paper frames fact-consumed NLIDB systems as a reliability problem: fluent schema, aggregation, or interpretation errors can reach users as unmarked values. It proposes structural abstention through a trusted kernel and generative shell, situating the design against prior NLIDB, dialogue, agentic, reliability, and interaction work.

  • 1 Introduction: The paper’s perimeter invariant permits fabricating components to shape the question but forbids them from influencing the returned value.The shell interprets underspecified input and phrases replies; the kernel deterministically executes fully specified questions, with confirmation between them.
  • 1 Introduction: Structural abstention makes unanswerable requests unrepresentable, so refusal requires no confidence estimate, unlike statistical abstention after candidate generation.The design declines at grounding time, before any query exists, trading coverage for calibrated-confidence independence.
  • 2.1 Natural language interfaces to databases: Earlier NLIDB research established the coverage–correctness tension, while NaLIR and ATHENA added user correction and ontology-based separation from physical schema layout.These precedents motivate showing users the intended question before execution and decoupling user vocabulary from database structure.
  • 2.2 Neural and LLM text-to-SQL: Neural text-to-SQL methods improved schema linking, SQL wellformedness, decomposition, and self-correction, but constrained decoding cannot guarantee semantic agreement with the user’s question.The proposed compiler instead fixes and audits the mapping from a confirmed question to SQL within a bounded pool.
  • 2.2 Neural and LLM text-to-SQL: Spider 2.0 reports 21.3% task success against 91.2% on the earlier benchmark, highlighting failures caused by industrial schema complexity, joins, nested aggregation, and private schemas.The paper argues that average execution accuracy is unsuitable for an unsupervised oracle because incorrect cases are not visibly labeled.
  • 2.3 Conversational semantic parsing and dialogue state: Conversational parsing and task-oriented dialogue inform the system’s clarification and entity-state mechanisms, but this design clarifies when grounding fails because that condition is decidable.It therefore exchanges conversational flexibility for a guarantee.
  • 2.4 Retrieval-augmented generation, tool use, and agentic pipelines: The second prototype draws on retrieval-augmented generation and tool use, including executor-based computation for improved arithmetic reliability, while the paper’s invariant constrains what tools may determine.This extends the concern from generated answers to downstream agentic actions.
  • 2.5 Reliability, abstention, and knowing when not to answer: TrustSQL formalizes the deployment concern that users cannot identify answerable questions and that incorrect SQL can go unnoticed; this work addresses it structurally before query generation.Its guidance mechanism also aligns with mixed-initiative interaction and guidelines for capability scoping, correction, and deferral.

3 The Pattern

The pattern separates generative interpretation and phrasing from deterministic grounding, compilation, and execution, making refusal explicit when requests cannot be represented. Its guarantees are visible failure and auditable, non-fabricated values, traded against bounded coverage under specific deployment conditions.

  • Core obligations: GROUNDER must be total, returning either a question or refusal, while COMPILER must be deterministic so confirmed questions uniquely determine auditable queries.These obligations ensure refusal is distinguishable from an answer and eliminate dependence on model-output logs for query reconstruction.
  • State and dialogue: The system represents dialogue state explicitly, supporting completeness, gap enumeration, and consistency tests rather than passing raw text between turns.The bounded-answer loop branches on inconsistency, successful grounding, or continued progress before deterministic execution after user assent.
  • Three-branch policy: When elicitation stops converging, the system must state its capability boundary and refuse rather than continue questioning or guess.This makes the boundary visible to users instead of allowing them to discover it through wrong answers.
  • Guarantees and limits: The pattern guarantees no generatively fabricated values, query recovery without logging, visible coverage failures, and semantic confirmation before computation.It does not guarantee that users confirmed the intended question, that templates are semantically correct, or that coverage is adequate.
  • Applicability: The coverage trade is favorable when outputs are consumed as fact, questions recur in bounded shapes, and errors cost more than refusals.If question demand is novel, a hybrid can route grounded requests to the kernel and use a generative fallback for the rest.
  • Abstention strategy: Structural abstention makes unanswerable requests unrepresentable, unlike statistical abstention, which estimates whether to trust a generated candidate answer.Its fixed coverage depends on authored question shapes, while the two approaches can compose through structural refusal and statistical abstention over generative fallback.

4 Instantiating the Pattern

Section 4 turns the pattern into five implementation decisions, showing which choices transfer across domains and which require domain expertise. It also generalizes the invariant from returned values to executed actions: generative components may propose, but only the trusted kernel may determine what is returned or executed.

  • Five implementation decisions: The implementation must define an enumerable answer space, represent partial requests, compile deterministically, render confirmations in user vocabulary, and specify refusal behavior.The answer space must have decidable membership and be authored by someone who knows the data; partial requests must support completeness, gap enumeration, and consistency.
  • Cross-domain transfer: Only two decisions are strongly domain-dependent: confirmation vocabulary and compilation target.A slot frame and reusable refusal branch transfer across domains, while confirmation must reflect professional vocabulary and compilation should target the narrowest governed interface available.
  • Cross-domain transfer: A confirmation that users cannot evaluate voids the pattern’s guarantee, especially when financial ambiguity concerns the computation basis rather than the number.Users may assent without understanding a restatement, making an omitted basis worse than no confirmation because it creates false assurance.
  • Generalizing the invariant: For acting systems, a fabricating component may influence which action is proposed but never which action is executed.The kernel maps confirmed intent to one parameterized effect, unsupported requests are refused, and confirmation becomes an explicit approval step.
  • Generalizing the invariant: The action form is offered as a hypothesis rather than a built-system result because executed actions are irreversible consequences of uninspected inferences.This motivates treating the extension as an agent-safety concern, particularly for tool-using agents that execute effects based on inferred intent.

5 A Deployed Instantiation

GROUNDER was a roughly two-year production conversational analytics system for repetitive, quantitative retail questions where users consumed answers as fact and errors could affect decisions. Its trusted kernel deterministically grounded confirmed questions and generated SQL, while the generative shell handled dialogue and prose and returned unmatched requests for further guidance rather than fabricating answers.

  • Domain and requirements: GROUNDER served retail sales staff whose recurring questions concerned quantitative product, inventory, forecast, and store-entry measures sliced by product, geography, channel, and time.Users could not inspect SQL, error tolerance was low, and refusal imposed delay rather than silently introducing a wrong figure.
  • Pipeline: The four-stage pipeline used language models for conversation guidance and answer rendering, but deterministic grounding and SQL generation jointly determined the returned number.The kernel’s failures were coverage failures—declining questions it could have answered—instead of factual errors.
  • Pipeline: Failure to match a template returned control to the shell, making abstention a defined outcome instead of forcing every input into a best-effort query.This return path is identified as a central source of trustworthiness in the deployed design.
  • Question grounding: The system represented questions as binary entity vectors with resolved values stored separately, providing a compact address for matching partially specified questions against an explicit template pool.A template was grounded only when the entity vector and value dictionary satisfied its typed slot requirements.
  • Question grounding: The template pool explicitly specified system capability, target tables, slot-to-column mappings, and aggregation semantics, so coverage gaps were measurable and ungroundable inputs were detected rather than coerced.The pool contained a few thousand templates, each defining the mapping needed to answer its question shape.

6 Conversation Guidance

Conversation guidance turns incomplete or ambiguous input into grounded questions through three modes: direct answering, entity-by-entity elicitation, and honest suggestion of nearby answerable questions. Discrete dialogue states and deterministic transitions keep guidance within configurations the kernel can express, while language generation only renders known transitions.

  • Conversation modes: Guidance selects direct answering, question guidance, or question suggestion according to how completely the current turn satisfies an answer template.Question suggestion is triggered when intent falls outside the pool or elicitation fails to converge, and it states what can be asked instead.
  • Question guidance: Question guidance elicits missing entities one at a time, using predicted co-occurrences and user history to choose likely next entities and defaults.Prediction errors can produce irrelevant clarification, but users can correct them at the cost of an additional turn.
  • Dialogue state: A discrete-state pushdown automaton lets the system suspend, resolve, and resume partially specified questions while ensuring every reachable state has a template and defined next action.Nearest-neighbor projection keeps dialogue inside the finite set of configurations the system can act on.
  • Dialogue state: The language model only renders transitions between known states; it cannot influence grounding or query construction, so poor wording may confuse users but cannot return a wrong number.The deterministic state transition decides what to ask, while the model produces the fluent prompt.
  • Boundary and confirmation: The bounded design exposes semantically unanswerable requests, such as overlapping store classes, and sends the ambiguity back to the user before computation.Confirmation makes the exact question that will receive a number visible in ordinary language.

7 SQL Generation

Grounded questions are compiled into SQL through deterministic template selection, parse-tree construction, dictionary resolution, and depth-first rendering. Primitive tree nodes support compositional numeric operations while database execution performs arithmetic, and confirmed results are rendered with templated sentences rather than free-text summarization.

  • Grounding and compilation: Grounding extracts entities and operators, selects a template using entity-vector and sentence-similarity matching, then resolves dictionary values into concrete SQL tables and columns.The resulting intermediate parse tree represents SQL constructs and operators internally, with entity slots as leaves.
  • Grounding and compilation: Depth-first traversal emits SQL by recursively rendering child nodes, making new aggregates or comparisons modular additions rather than traversal changes.Leaf nodes resolve table, column, or literal values; interior nodes render their typed children.
  • Compositional operations: Primitive nodes compose thresholds, ratios, and top-k rankings without a combinatorial template pool, while the database engine performs arithmetic instead of the model.Templates fix question shapes, while parse trees compose arithmetic and delegate computation to database execution.
  • Result rendering: Confirmed results are rendered as templated sentences over small result sets, with free-text summarization reserved for the alternative architecture where result shape is unknown.The confirmed question supplies the response frame.

8 Bilingual Support

Bilingual support separates question-form translation from entity recognition and grounding. This lets one extraction path serve both languages while preserving non-Latin outlet and reseller names through direct registry matching.

  • 8 Bilingual Support: A compact open translation model normalized non-primary-language queries into the schema’s language before entity extraction, enabling one extraction and grounding path for both languages.The small model was selected because translation lies on the critical path of every non-primary-language turn.
  • 8 Bilingual Support: A named-entity recognition model extracted outlet and reseller mentions before translation, then matched them directly against the canonical registry.This avoids inconsistent transliteration or semantic rendering of proper nouns written in a non-Latin script.
  • 8 Bilingual Support: The division of labor translates question form but recognizes and resolves entity values against ground truth, because translating entire queries can corrupt the branch names users need.Users queried in two languages and mixtures of them against an English-language schema, with entity names sometimes using another script.

9 Designs Considered

The two generative alternatives broadened coverage but could not match the rule-grounded core’s reliable failure behavior. A tool-retrieval pipeline ultimately superseded the fine-tuned parser because it retained database-delegated arithmetic and a partial audit trail.

  • Fine-tuned parser: The fine-tuned LLM covered text-to-SQL, response-template generation, and context completion using data substantially produced by the rule-grounded system.Its training resources included a few thousand templates and tens of thousands of question–query pairs accumulated during kernel operation.
  • Fine-tuned parser: The fine-tuned model reached usable quality on common question shapes but offered no reliable signal separating correct outputs from fluent, plausible errors.The interface could not distinguish a query using a plausible-looking column and returning a plausible-magnitude number from a correct answer.
  • Tool-retrieval agent: The tool-retrieval agent resolved entities and dates through tools before generating and executing SQL, making the design relatively language-agnostic and its intermediate steps auditable.Tool calls and returns formed an audit trail, while entity resolution handled colloquial names and date formats that would require explicit rule-based patterns.
  • Tool-retrieval agent: The tool-retrieval design incurred latency and non-determinism from multiple model round trips, although inference acceleration and a columnar analytical engine brought it within an interactive budget.Mitigation reduced the latency cost without eliminating it, and identical questions could follow different paths on different occasions.
  • Comparison: The tool-retrieval pipeline became the successor because it preserved database-delegated arithmetic and a partial audit path, whereas the fine-tuned parser offered broader coverage without auditability.The comparison emphasizes that all systems make mistakes, but the rule-grounded system declines visibly while end-to-end SQL generation answers without signaling failure.

10 Deployment and Usage

GROUNDER operated in production for roughly two years, showing that a small team could maintain an affordable kernel-first system with a generative shell against a live warehouse. It enabled business teams to self-serve recurring questions, but failed to instrument how turns divided among direct answering, elicitation, and disclosure.

  • Production deployment: GROUNDER ran in production for roughly two years after about a year of kernel development, demonstrating that a small team could build and maintain the pattern against a live warehouse.The deployment also established that the system was affordable at conversational latency.
  • Production deployment: After deployment, business teams self-served recurring questions that had previously required technical staff to query fragmented dashboards.The system was commissioned to reduce dependence on analysts for those requests.
  • Measurement limitation: The deployment did not measure the share of turns resolved by direct answering, elicitation, or disclosure.The paper recommends instrumenting these three branches from the first deployment because their distribution indicates whether demand is converging or falling behind.

11 Discussion

The discussion finds that the template pool became GROUNDER’s capability contract, while building the deterministic system first enabled the data needed for later model development. It also reports that data interventions outweighed architectural changes and identifies instrumentation and early capability disclosure as low-cost improvements.

  • Template pool: The template pool became the system’s capability contract, making additions concrete and coverage gaps countable rather than anecdotal.Unlike learned-parser coverage, pool coverage is an explicit list that teams can inspect.
  • Deterministic foundation: Building the deterministic system first was load-bearing because it generated the corpus that enabled the fine-tuned prototype.Without an existing question–query corpus or traffic, the constrained system was the mechanism by which training data came to exist.
  • Iteration: The four data interventions produced larger quality movements than any architectural change, with shorter target queries mattering more than expected.The discussion characterizes data iteration as dominating model iteration.
  • Deployment lessons: The authors would instrument Algorithm 1’s three branches from first deployment and use the confirmation turn as an early capability-disclosure surface.They describe both changes as cheap omissions and note that users formed system capability models through trial and error before disclosure existed.

12 Revisiting the Design in 2026

The 2026 review finds that enterprise benchmarks exposed a larger reliability gap than anticipated, while several implementation choices have become obsolete. It retains the trusted-kernel invariant, database execution, and user confirmation as the enduring design elements.

  • Evidence and research context: Later enterprise-warehouse benchmarks suggest the text-to-SQL reliability gap was much larger than the authors’ 2021 caution had assumed.The bounded pool was chosen because published accuracy looked strong while the authors’ schema appeared harder, and they avoided discovering the difference in production.
  • Evidence and research context: TrustSQL formalizes the same obstacles: users cannot tell what systems can answer, and unnoticed incorrect SQL destroys trust.It evaluates systems by weighing correct answers against wrong ones under an explicit penalty.
  • What changed: The fine-tuned parser and hand-assembled bilingual front end are now obsolete approaches because current multilingual models largely remove the problem the front end addressed.The parser depended on a bespoke corpus and from-scratch training, while the front end combined a small translation model with a purpose-trained entity recognizer.
  • What remains: The core invariant remains unchanged: faster models and standardized tool calls may reduce shell-building costs but do not justify letting models compute decision-critical numbers.The authors still regard the database as more reliable at arithmetic than reasoning models.
  • What remains: The confirmation turn still costs about two seconds and remains the design’s mechanism for non-technical user verification before relying on an answer.The passage presents confirmation as unaffected by improvements in model reasoning or arithmetic.

13 Limitations · 14 Directions We Would Have Pursued · 15 Conclusion

The paper’s limitations are bounded coverage, user elicitation costs, and poor fit for exploratory analysts, while its central user-detected-error claim remains untested. It proposes hybrid routing and broader template coverage, concluding that the durable contribution is the invariant that keeps computation outside the model and exposes answer provenance.

  • 13 Limitations: The central claim remains untested because the relevant evaluation is user-detected error rate, not execution accuracy, and the pattern has been built directly only in one domain.A paper-based specialization elsewhere demonstrates that the five decisions can transfer, but not that the resulting system would work.
  • 13 Limitations: Coverage is bounded by construction: requests outside the question pool can only be redirected, while pool growth depends on manual engineering attention.The limitation is structural rather than incidental.
  • 13 Limitations: GROUNDER imposes elicitation turns, serving users who know and can clearly phrase their questions worse than a system that simply parses those sentences.The design prioritizes underspecified requests and requires confirmation before answering.
  • 13 Limitations: Exploratory research analysts may be better served by the architecture the report rejects because their novel, iterative questions are inspectable and cannot be gracefully handled by a bounded kernel.For these users, redirection to answerable alternatives is an obstruction rather than a graceful refusal.
  • 13 Limitations: The system automates the recurring request queue, not analyst judgment, freeing human capacity for exploratory questions that no kernel can express.The report explicitly rejects describing this pattern as an automated analyst.
  • 14 Directions We Would Have Pursued: The proposed roadmap is design analysis rather than a statement of anyone’s current plans, centered on hybrid routing by grounding success instead of confidence scores.A rule-grounded path would handle groundable questions, while a tool-retrieval agent would handle the remainder; presentation across paths with different reliability remains open.
  • 14 Directions We Would Have Pursued: Further directions include using observed acceptance of recommended questions to drive template authoring and extending the question pool beyond the single retail channel.These directions would connect user demand to pool coverage and broaden the engagement surfaces.
  • 15 Conclusion: The conclusion identifies the durable contribution as an invariant: the language model shapes the question but never computes the answer, with assent and explicit decline protecting trust.The implementation is largely obsolete; what survives are the invariant, the five decisions, and the observation that the successor preserved computation outside the model and left an answer trace.

A Entity Type Inventory … D Fine-Tuning Procedure for the Abandoned Alternative

The paper specifies a bounded, typed template-and-compiler pipeline whose deterministic mappings and renderers constrain SQL generation, while production-derived data supports an abandoned fine-tuned alternative without solving its trust problem. The examples illustrate transferable compilation structure rather than a deployed schema or real figures.

  • A Entity Type Inventory: The exercised entity inventory includes product family, model, store class, store, city, region, sales, inventory, traffic, date, quarter, and numeric threshold types.Store classes may overlap, and dates support fiscal and relative forms; numeric values serve as operands for COMPARE nodes.
  • B Template Pool Record Structure: Each template record binds typed surface slots and an entity vector to a target table, slot-to-column mapping, and aggregation semantics.The entity vector makes matching a lookup rather than a search, while aggregation semantics determine emitted SELECT and GROUP BY clauses.
  • B Template Pool Record Structure: Template authoring fixes the table, grain, and aggregation before query time, with reviewed schema mappings carrying the correctness guarantee.The compiler is trusted because it applies mappings written and reviewed by someone who knew the schema.
  • B Template Pool Record Structure: The template pool concentrates on a few query families, so the first few hundred templates provide most coverage despite a long thin tail.This short-head distribution is what makes the authoring cost tractable.
  • C Worked SQL Compilation Example: The worked compilation example uses an invented schema to demonstrate transferable node types, their contributions, and their locations in emitted SQL.The report states that no deployed-system table or column names, and no real figures, appear in the example.
  • 2. Entity dictionary.: A matched question is converted through typed entities and a parse tree into SQL by depth-first rendering, with leaves resolved before interior nodes.The example identifies store, model, sales, inventory, date, and numeric thresholds, then emits SELECT, WHERE, GROUP BY, and HAVING clauses.
  • 2. Entity dictionary.: Aggregate thresholds render in HAVING through the COMPARE node, while changing from model to product-family grain changes only the target table.The template author does not control the aggregate-threshold placement, and the parse tree remains identical across those grains.
  • D Fine-Tuning Procedure for the Abandoned Alternative: Production-grounded question–query pairs supplied no-cost, correct labels for three jointly trained tasks, but the fine-tuned model was not deployed because it could not signal outputs to distrust.The corpus comprised a few thousand question shapes and tens of thousands of pairs; vocabulary, target shortening, input noise, and annotated head questions improved quality more than architectural changes.
Loading 2608.13926v1…