Define the terms your team actually uses
‘Active customer’ might mean a login in the last 28 days, a paid subscription, or an order this quarter. A language model cannot infer your company's definition from the phrase alone. Store that definition in project Knowledge alongside the columns and tables it refers to.
Add examples of approved calculations and explain joins that are not obvious from column names. Schema descriptions and project rules provide context on each grounded request; they are not a promise that every generated query will be correct.
Turn a broad question into a reviewable request
Instead of ‘How is revenue doing?’, ask ‘Show paid invoice revenue by month for January through August 2026, in USD, excluding test accounts.’ This specifies a metric, grain, period, currency, and exclusion that can each be checked in the SQL.
When a question has material ambiguity, the query workspace can ask for clarification. Resolve the definition before running the query. In a follow-up, explicitly say which filters should stay the same and which should change.
- Metric: count customers, sum invoice amounts, or average elapsed time?
- Time: which timestamp, timezone, and complete or partial period?
- Population: include cancelled orders, internal accounts, or customers with no activity?
- Grain: one row per customer, region, month, or event?
Review meaning as well as syntax
An English to SQL converter can generate valid SQL that answers a different question. Check whether a join multiplies amounts, whether NULL values are excluded, and whether the result covers the requested population.
Analysts can inspect these choices directly. Business users can keep the question, SQL, and resulting evidence together in an answer thread for review with the person who owns the metric.