Validate the SQL answer before trusting the sentence

Translate the question into a data contract

Before reading SQL, write the requested population, date basis, unit of analysis, measure, and exclusions in plain language. “Revenue by customer last quarter” is incomplete until revenue basis, customer identity, time zone, refunds, and quarter boundaries are named. This contract becomes the checklist for the query.

Run exploratory work with read-only permissions where possible. PostgreSQL supports read-only transaction mode; BigQuery separates data-viewing access from query-job permissions and provides dry runs that validate a query and estimate processed data without running it. A dry run checks syntax and some planning concerns, not whether the result means what the user asked.

Inspect the query in six passes

1. Base tables: confirm each table's grain and freshness.
2. Joins: state expected cardinality for every join: one-to-one, many-to-one, or intentionally one-to-many.
3. Filters: list inclusion and exclusion predicates in prose.
4. Nulls: check whether missing values are excluded, retained, or converted.
5. Dates: inspect boundaries, time zones, and which date column defines the period.
6. Aggregation: confirm grouping columns and denominator.

PostgreSQL's join tutorial shows that a join builds rows from matching records across tables. That simple operation can multiply measures when the relationship is not what the author assumed. Count rows and distinct business keys before and after each important join. If 410 invoices become 1,247 rows after joining payments, summing invoice totals may triple-count them.

Make null behavior explicit

SQL null means unknown, not zero or an empty string. PostgreSQL documents that ordinary comparisons involving null return null, and recommends IS NULL or IS NOT NULL rather than = NULL. Check how nulls interact with filters and aggregates. A left join followed by a WHERE condition on the right-hand table can effectively remove unmatched rows. A COUNT(column) can differ from COUNT(*).

Test slices, not just the final total

Choose a few known records and trace them from source to output. Compare a simple subgroup total with the production report or a reconciled spreadsheet. Reverse the question: list records excluded by each filter. Examine zero-result groups and unexpectedly large contributors.

Hypothetically, a query reports 90 active clients. A validation query finds 96 distinct client IDs before an inner join to account managers. The six missing clients have no current manager. The SQL is valid, but the answer silently changed from active clients to active clients with a manager. The correct fix depends on the question, not on syntax.

Preserve the answer's conditions

Save the exact SQL, execution timestamp, source snapshot or freshness note, row count, and validation results beside the narrative. Do not copy only the final number. If an assistant drafted the query, review it under the same process; generated SQL is a proposal.

For spreadsheet outputs, use the reconciliation guide. For generated code changes around the query, use the AI code-change review. The query is ready when a second person can see what population it measured and reproduce the checks that support the answer.