Implicit Prompt (PremiseSQL): a gentle “the question may contain errors” warning gets the model to decline a broken query

ONE PROMPT:
  1. Warning: "the question MAY contain errors, assess validity before answering"
  2. Context: table schema + question
  3. Output format: JSON {sql, is_valid, reason}
     - question is valid → sql filled in, is_valid = true
     - question is invalid → sql = null, is_valid = false, reason = what's wrong

DON'T: "The question contains an error" (Explicit) → false refusals

The four types of question errors the researchers tested: - E1 Expression: ambiguity, unclear intent. - E2 Contradiction: conditions rule each other out or clash with the schema. - E3 Omission: a missing filter, table or column; a concept that doesn't map onto the schema. - E4 Out of scope: SQL can't express it, or it needs outside knowledge.

Task: You head analytics at an online electronics store in Denver. A product manager pings the company Slack bot: “Show me the average margin on orders for March.” The database has orders(id, customer_id, city, total, created_at) and order_items(order_id, product_id, qty, price). There's no cost column, so margin can't be calculated. A regular prompt will produce SQL where “margin” quietly turns into total or price. The number will look great and be wrong.

Prompt:

You help analysts write SQL (PostgreSQL).
The input question MAY contain errors: ambiguity, contradictions,
data missing from the schema, or requirements SQL cannot fulfill.
First assess whether the question is valid and can be answered with this schema.
Do not fill in anything that's missing.

Schema:
orders(id, customer_id, city, total, created_at)
order_items(order_id, product_id, qty, price)

Question: Show me the average margin on orders for March.

Return JSON:
{
  "sql": "<query, or null if it can't be answered>",
  "is_valid": true/false,
  "reason": "<why the question is valid, or what exactly is wrong>"
}

Result: The model will most likely, though not guaranteed, return sql: null, is_valid: false and an explanation that the schema has no cost data. Without the warning, the same model would usually produce SQL that passes revenue off as margin. If the question is valid (“average order value for March”), you should get normal SQL with is_valid: true. But some models start playing it too safe even with this gentle warning, so test it on your own valid queries.

The weakness. The model is trained to be helpful and to answer. To it, the question is the problem statement, not something to audit. So it silently fills in the gaps: it maps “person” to “actor” and “margin” to “revenue.” The SQL is syntactically correct, and the error is invisible.

The strength. Ask the model to evaluate the question explicitly, and it can. It does know the column is missing; that knowledge just doesn't kick in on its own. On top of that, its own verdict drives its behavior: when is_valid = false, it almost never writes SQL, and vice versa.

How the method exploits this. The “there may be an error” warning switches the check on, and the is_valid field with reason forces the model to write down its conclusion before or alongside the answer. The word “may” matters. It leaves the model room to say “everything's fine.” Stating “there is an error” takes that room away. The model accepts it as fact and goes hunting for an error where there isn't one.

Control knobs: - Phrasing strength. “May contain errors” strikes the balance. “Contains errors” boosts the catch rate but breaks normal queries. No warning at all means a near-zero catch rate. - The reason field. Keep it: it shows whether the model spotted a real problem or was just nitpicking. - What to return on refusal. Instead of null, you can ask for “a clarifying question to the user.” That's part of the scenario in Figure 1 of the paper. - List of error types. The more specific the list in the warning, the more hints the model gets, but the higher the risk of overcaution. Test on your own valid questions.

You are {role_and_task}.
The input request MAY contain errors. First assess whether it is valid
and whether it can be answered given the context below.
Do not fill in anything that's missing.

Context:
{context_or_schema}

Request: {request}

Return JSON:
{
  "sql": "<result, or null if it can't be answered>",
  "is_valid": true/false,
  "reason": "<why the request is valid, or what exactly is wrong>"
}

What to fill in: {role_and_task}: for example, “an analyst who writes SQL.” {context_or_schema}: a description of the tables or rules. {request}: the user's question. You can rename the sql key to answer if your task isn't about SQL, but the idea has only been tested on SQL.

🚀 Quick start: paste this into the chat:

Here's a prompt template that makes the model check whether a question is valid
before answering. Adapt it to my task: [your task].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what data or context you have and what counts as “can't be answered.” That way the warning is anchored to your context, and the model knows what to check the request against.

⚠️ The price of a gentle warning: even neutral phrasing makes some models refuse perfectly normal questions. For one model, almost half of the valid queries went unanswered. Test on your correct questions, not just the broken ones.

⚠️ Hard-line phrasing hurts: “the question contains an error” pushes the catch rate close to the maximum, but the model starts rejecting valid queries too. One model refused practically every normal question. The high catch numbers are misleading here: that's obedience, not verification.

⚠️ Scale won't save you: newer and larger models are only partly better, and the best model without a warning catches fewer than half the errors. In one comparison, a smaller model caught more than a bigger one. Test on your own model.

⚠️ A wrong verdict drags the answer down with it: the model almost always acts on its own is_valid. If the verdict is wrong, the action will be wrong too. The reason field doesn't guarantee the verdict is right.

⚠️ One domain: everything was tested on Text-to-SQL, with errors artificially injected by another LLM. Carrying it over to other tasks makes sense, but the authors didn't test that. Identifying the type of error is also harder for models than simply noticing that one exists.

⚠️ No ready-made prompt: the available text describes the three modes rather than giving the full prompt wording. The template above is built from that description. The paper's text also cuts off at the section on error types.

The researchers took two popular SQL question sets, Spider and BIRD, and corrupted 1,800 questions using a taxonomy of four error types. One LLM did the corrupting, another LLM checked the results, and then humans reviewed them. Each corrupted question was paired with its original as a control. That's the key design idea: otherwise you can't tell genuine checking apart from a habit of refusing.

Then 16 current models were run through three modes: plain (Base), with a gentle warning (Implicit), and with the statement “there is an error” (Explicit). That came to about 173,000 responses in total. The responses were graded by two LLM judges that agreed with each other and with humans.

The results. In Base, models caught about a third of the errors and almost always produced SQL. In Implicit, the catch rate roughly doubled, while the share of normal questions that got an answer dropped only from 99% to 90%. In Explicit, the catch rate came close to the maximum, but the share of normal questions answered fell to about half. For every model, switching to Explicit raised the catch rate and cut answers to valid questions.

The surprises: there's no clean “newer and bigger is better” trend. And the is_valid verdict almost perfectly predicted whether SQL would be written, even when the verdict was wrong. The practical takeaway: how you phrase the warning and whether you test on “good” queries matter more than which model you pick.

These are my ideas; the authors didn't test them.

🔧 Technique: add the error types → hint at what to look for

Check the request for: (1) ambiguity, (2) conditions that contradict each other or the schema, (3) missing data or filters, (4) anything that can't be computed from this data.

The paper has separate metrics for the error types, but it didn't test listing them inside the prompt. This might make reason more precise, or it might amplify overcaution. Be sure to test on valid queries.

Extrapolation: a rule in the agent's instructions file. For an agent that answers questions about data (CLAUDE.md, a custom GPT's system prompt):

Before writing a query or a report, check: are all the fields, periods and
metrics from the question present in the available data? If something is missing or the question
allows more than one interpretation, don't substitute concepts. State exactly what
is missing or unclear, and ask one clarifying question. If the question
is valid, answer right away, without unnecessary second-guessing.

The last sentence is there so you don't get the Explicit-mode effect, where the model refuses normal requests.

• PremiseSQL: Evaluating Premise Critique and Abstention in Text-to-SQL Systems by Shuo Lin, Jinzhe Li, Chenlu Guo, Yanhan Li, Yuan Wu, Yi Chang.
• Affiliations: Jilin University (School of AI; Engineering Research Center of Knowledge-Driven Human-Machine Intelligence; International Center of Future Science), Bilibili Inc., China Telecom AI Technology (Beijing).
• Code and benchmark: https://github.com/vegeet/PremiseSQL
• Source datasets: Spider 1.0, BIRD. Related work: TriageSQL, TrustSQL, NL2SQL-BUGs, AbstentionBench.