How to Verify an AI-Generated Data Answer Before It Reaches the Board

To verify an AI-generated data answer, check the question, the reporting period and the business definition first, then have the executed SQL reviewed when the figure matters. Datarelix shows the executed query, source tables, returned row count and runtime with each answer, so the review starts from what actually ran rather than from a paraphrase. The sections below split the work: checks anyone can make, an eight-step SQL review for analysts, and a worked example of an order total counted twice.

Which checks can you make without writing SQL?

Keep the original question beside the answer. Confirm the period, currency, unit and definition before comparing totals. “Revenue last month” might mean booked orders, paid invoices or sales after refunds. A plausible number does not settle that choice.

Use the source names to confirm the dataset. Ask its owner when the data was last updated and whether the period is complete. An incomplete load can explain a low total even when the query is correct.

Check	What to look for	Example clarification
Period	Exact boundaries; complete or partial period	“Use the previous complete calendar month.”
Definition	Statuses, refunds, tax and discounts	“Exclude cancellations; show refunds separately.”
Unit	Currency and what is being counted	“Show EUR only and count distinct customers.”
Source	Approved table and last update	“Use the reporting orders table.”
Plausibility	Comparable report or known sample	“Break the total down by week.”

These checks help you decide whether to investigate further. They do not establish that joins and calculations are correct.

An annotated result

Example of a sales report:

Visible item	Example	Review note
Period	1–31 August 2026	Is the whole month loaded?
Completed sales	EUR 2,300	Does the reference report use the same status definition?
Refunds	EUR 200	Refunds issued in August, or refunds on August orders?
Sales after refunds	EUR 2,100	The subtraction reconciles; the inputs still need checking.
Output rows	1	This is one summary, not one order.

The category guide explains the execution details Datarelix displays.

Review the interpretation and SQL together

Bring the business definition and the technical review together when totals disagree, several tables are joined or a figure will be used externally. An analyst can review their own exploratory work; significant reports benefit from a second reviewer who understands the source.

How to verify an AI-generated SQL answer in eight steps

Use this sequence for a joint review. Business users establish the intended definition, period and source. Analysts translate those choices into checks of the SQL, including intermediate results where needed.

1. Confirm the interpretation matches your intent. Read your original question next to the executed query and check that they describe the same measurement. “Revenue last quarter” can mean the previous calendar quarter or the trailing ninety days, and “top customers” can mean by revenue or by order count — the query commits to one reading, and it must be yours.

2. Check the metric definition. Decide whether the figure should be gross or net, and whether returns, refunds, discounts, taxes, and shipping are in or out — then check that the query’s arithmetic and filters agree. A technically correct query can still measure the wrong thing here.

3. Check the data scope. Look at which tables the query read and confirm they are the canonical ones, not a staging copy or an abandoned _v2. Then check completeness and freshness: whether the period is fully loaded, and whether the current month is partial and should be excluded or labeled.

4. Check the joins for fan-out. Joining an order-level amount to line items multiplies it once per line, silently inflating any sum built on top. Confirm that amounts are summed at the grain where they live, and compare joined rows with distinct business identifiers before aggregation. The final returned-row count cannot diagnose this by itself.

5. Check the filters. Look for status filters (completed vs. cancelled vs. refunded), test rows, internal accounts, and deleted records. Whether these are included or excluded is a business decision, and the query’s WHERE clause is where that decision is visible.

6. Check time zone and currency. A day boundary in UTC is not a day boundary in your reporting time zone, and month-end figures can shift when the cutoff moves. If the data spans currencies, confirm amounts were converted before being summed rather than added raw.

7. Sanity-check the execution result. Compare the row count and the magnitude of the answer against expectation: a request for all customers should not return twelve without an explained filter or limit, and a quarterly revenue figure should be in the neighborhood of previous quarters. A result that is wildly off is a prompt to revisit steps three through six, not a rounding quirk.

8. Read the exceptions and warnings. Check whether the result was truncated by an automatic row limit, whether the query failed and was revised and retried, and whether any step of the run flagged partial data. If the row count equals the row limit, check for possible truncation: re-ask the question as an explicit aggregate so the total is computed in the database rather than over a capped slice.

Worked SQL review: an order total counted twice

Consider three August orders. All values are EUR, item prices include the same components as the order total, and there are no discounts or refunds in this example.

Order	Status	Order total	Item rows and values
A	completed	100	60 + 40
B	completed	200	200
C	cancelled	50	20 + 30

There are five item rows across three orders. The completed order value is 300. Three query choices illustrate different errors:

Calculation	Result	Interpretation
Sum every item, without a status filter	350	Includes the cancelled order
Sum items belonging to completed orders	300	Matches the requested completed order value
Sum order totals after joining completed orders to items	400	Counts A’s total twice because A has two items

Every aggregate can return one output row. To inspect the join, an analyst can run this diagnostic:

SELECT COUNT(*) AS joined_rows,
       COUNT(DISTINCT o.order_id) AS distinct_orders,
       SUM(o.total_eur) AS repeated_order_total,
       SUM(i.quantity * i.unit_price_eur) AS item_total
FROM orders AS o
JOIN order_items AS i ON i.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= DATE '2026-08-01'
  AND o.ordered_at < DATE '2026-09-01';

The output is joined_rows = 3, distinct_orders = 2, repeated_order_total = 400, and item_total = 300. The difference in row counts identifies the one-to-many relationship; the choice of amount determines whether it inflates the sum.

For an order-level total, sum the orders without the item join. For an item-level measure, sum item amounts once at that level. With refunds or payments, aggregate each input to the required level before combining them. SUM(DISTINCT total_eur) is not a general repair: two separate orders can legitimately have the same total.

Filtering completed orders does not calculate revenue after refunds. That requires the refund source and a decision about whether to report refunds by their issue date or against the original order period. The weekly sales report works through that distinction.

What should you keep with a reviewed figure?

Keep the definition, exact period and time zone, source names, executed SQL, result, execution date and reconciliation reference. Record any known exclusion, such as a late source load. For an analyst, this makes later investigation possible; for a business user, it explains why the figure can differ from a report with another definition.

If a query was revised after an error, retain the successful version. If source data later changes, rerunning that version may produce a different result. Preserving the original output as well as the query allows the reviewer to distinguish changed data from changed logic.

Match review to the decision

For exploration, check definitions and a known sample before continuing. For board reports or externally reported figures, reconcile with the approved reporting source and involve an appropriate second reviewer. This is a review workflow, not an accounting or regulatory standard.

When two answers differ, preserve both queries and examine the definitions, freshness and joins. Do not assume either an existing dashboard or the AI result must be correct.

Keep the evidence available

Reopen the Datarelix conversation to inspect its query and result. Accounts are private, so export the result or copy the query into review notes for a colleague. A checked chart can be saved and refreshed using its stored query; see dashboards.

Use the question guide to refine your next request. For product access and data handling, use the security checklist.