Correct SQL starts with a precise question.

Separate four kinds of correctness

A parser checks syntax, the database checks whether referenced objects exist, and a result check tests the question's meaning. Access and cost constraints form another independent requirement. Passing one layer does not prove the others.

• Dialect: does the engine support every function and identifier convention?
• Schema: do join keys and column types match the real database?
• Meaning: do period, grain, statuses, NULL handling and denominator match the request?
• Operation: is the query permitted for this user and reasonable to run on this dataset?

Give the model facts it cannot infer

Describe foreign keys, the grain of fact tables and ambiguous columns. An orders.created_at timestamp is not necessarily a payment timestamp. Record domain definitions such as 'active subscriber means paid through the reporting date' in project context rather than repeating vague labels.

Refresh schema context after a migration. For two plausible join paths, state the intended relationship. If a question omits the time zone or whether refunds reduce revenue, settle that requirement before accepting the SQL.

Inspect the joins and the row population

Trace one business record through each join. Joining orders to three items produces three rows for one order, so SUM(orders.total) now overcounts it. Aggregate items first, or sum item-level amounts when that matches the metric.

Check whether a filter on a right-hand table in WHERE accidentally turns a LEFT JOIN into an inner join. Distinguish customers with no orders from customers with no paid orders; test both with a tiny fixture.

Build a result-based evaluation set

Write representative questions and have a domain reviewer establish expected answers on a fixed, non-production dataset. Include no matches, one match, duplicates, NULL values, tied timestamps, month boundaries and a customer with no related rows.

Compare result sets after applying the ordering and numeric tolerance the question requires. Different SQL strings can be equivalent; identical-looking SQL can be wrong after a schema change. Keep failed cases with the prompt, schema version, generated SQL and the corrected business definition.

• Track the fraction of questions with the right result, separately from syntax success.
• Break down failures by joins, dates, aggregation, permissions and missing context.
• Rerun the same set when schema context, generation settings or the model changes.
• Do not treat a public benchmark percentage as an accuracy promise for your own database.

Use generation as a reviewable step

TTSQL uses project schema and policy context to generate SQL. Correction can help repair a query, but it cannot establish an unstated business definition or prove that the result is correct.

Read the SQL before manually choosing Run in the workspace. Start with an appropriate restricted database account and inspect expensive queries with your database's planning tools. The generation API returns executed: false and is not an execution endpoint.

• Worked examples with edge cases
• API contract