A syntactically valid SQL query can still be the wrong answer.
Ask, “How many active customers do we have?”
The system finds a customers table, guesses what active means, counts every tenant, ignores trials and timezone boundaries, and returns one confident number.
Natural language SQL needs an answerability contract.
For each supported question class, define:
- metric and definition version
- grain, filters, time window, and timezone
- authenticated user, tenant, role, and environment
- approved source and database identity
- freshness and completeness requirements
- row, byte, duration, and cost limits
- evidence required in the result
Then support more than one outcome:
- answer
- clarify
- refuse
- partial
- stale
- unknown
An empty result is not automatically zero. A truncated first page cannot support a global ranking. Yesterday's snapshot may not answer “right now.” Two valid metric definitions should trigger clarification, not a coin flip.
Generate SQL only after resolving meaning and scope. Validate the result before turning it into prose.
The goal is not to answer every question.
It is to answer only when the governed evidence supports the conclusion.
Full guide: Natural language SQL answerability contract
Top comments (0)