PremiseSQL catches a safety trade-off: stronger critique prompts reject valid SQL requests

PremiseSQL tests a failure mode that ordinary text-to-SQL leaderboards largely miss: whether a model notices that a request rests on a bad premise before it emits plausible SQL. Its central result is not that models never criticize a question. It is that prompting them harder to criticize can turn caution into indiscriminate rejection.

The prompt changes both sides of the error

The benchmark pairs 1,800 constructed flawed questions with 1,800 unmodified originals drawn from Spider 1.0 and BIRD/BIRD-filtered. Sixteen models process every pair under base, implicit and explicit prompting, producing 172,800 responses at temperature zero. The flawed cases span expression errors, contradictions, missing premises and requests beyond what SQL or the available database can answer. (PremiseSQL paper)

With ordinary generation instructions, aggregate flaw detection was just 31.9%, while models generated SQL for 98.8% of the valid originals. An implicit warning that a question may contain an error raised detection to 67.2% and retained a 90.3% generation rate on originals. The explicit prompt—telling the model that the question contains a flaw—raised detection to 93.1%, but valid-query generation fell to 52.3% and only 32.1% of originals were explicitly judged valid. Every evaluated model moved in the same direction: more flaw detection and less generation on valid controls. (PremiseSQL paper, Table 3 and Appendix B.9)

That is an operational warning against a simplistic guardrail such as “always find what is wrong before writing SQL.” Premise checks need paired acceptance tests: malformed requests should trigger clarification or abstention, while valid controls must continue to produce SQL. Otherwise a team can improve its headline safety metric by making the system broadly refusal-prone.

Ambiguity remains the harder case

The aggregate score also hides where critique works. Under implicit prompting, contradiction categories exceeded 91% for both detection and type identification. Ambiguity and unclear intent remained below 25% detection and below 14% type identification. The benchmark therefore suggests that models respond much better to overt incompatibilities than to missing specificity—the class of issue most likely to require a clarifying question rather than a hard refusal. (PremiseSQL paper, Table 4)

The authors add an execution check on 1,726 valid originals. Across model and prompt combinations, SQL-generation coverage correlated strongly with execution accuracy (Pearson r=0.990), and the change from implicit to explicit prompting correlated with the execution-accuracy change at r=0.992. Conditional accuracy among generated queries moved only from 72.2% to 76.2%, indicating that the overall execution loss came mainly from withholding SQL, not from worse SQL among answers that remained. (PremiseSQL Appendix B.7)

Inspectable code, incomplete reproduction bundle

The accompanying MIT-licensed repository includes construction, generation, evaluation and failure-attribution code, plus dry-run paths and taxonomy metadata. But it says the original datasets, generated responses and annotations are distributed separately where terms permit, and that the full pipeline with the paper’s datasets and live endpoints has not been reproduced during release preparation. (PremiseSQL repository)

That makes PremiseSQL more inspectable than a result with no artifacts, but not yet a one-command reproduction of the reported table. Its strongest immediate contribution is the paired measurement design: any production SQL agent adding premise critique should score both unsafe compliance on flawed questions and false abstention on valid ones.