Check and correct an answer

You can inspect an Explore in View. To change its source, select Edit. If you need the notebook controls, see Edit an analysis.

1. Compare with a trusted result

Put the expected and observed results side by side. Note the metric definition, period, timezone, units, data refresh time and database access used for each. A different snapshot or database identity can produce a different total even when both calculations are correct. If access differs, check credential selection.

Compare a small set of included and excluded records, not only the totals. If the trusted result has no clear definition or its records also look wrong, check it independently before changing the Explore.

Example: an incorrect period boundary

The September orders fixture has seven synthetic orders. Revenue is the sum of paid, non-refunded amounts assigned by paid_at in UTC. Each row is one order; amounts are in USD.

September includes A, B and G: 100 + 40 + 10 = 150 USD. G's October 1 timestamp has a +01:00 offset, so it is September 30 at 23:30 UTC. An inclusive October 1 midnight UTC upper bound also includes D's 70 USD and gives the wrong total, 220 USD.

2. Inspect the query and its inputs

Open Notebook and use Expand code on the query and calculation cells behind the answer. Trace a chart or summary back through its input cells. Compare the code with the definition and the records from your trusted result.

For the fixture, inspect whether the query includes D or excludes G. That identifies a boundary or timezone error more clearly than the total alone. Available context may state your team's rule; check the code to see whether this analysis applied it.

3. Correct the source and rerun

Change the logic that caused the mismatch. In the editing conversation, name the records and rule that expose it:

The September upper bound must be exclusive in UTC. Order D is outside
the period; order G is inside it. Correct the existing query cell,
rerun it and its dependent calculations, and show the included rows
and resulting total. Keep the paid and non-refunded filters.

Or edit the existing query cell yourself and use Run cell. For the synthetic orders table, this PostgreSQL-style query uses the correct boundary:

SELECT SUM(amount) AS revenue_usd
FROM orders
WHERE status = 'paid'
  AND refunded = FALSE
  AND paid_at >= TIMESTAMPTZ '2026-09-01 00:00:00+00'
  AND paid_at < TIMESTAMPTZ '2026-10-01 00:00:00+00';

Use your own table, fields and database's timestamp syntax. Fix the calculation rather than replacing its output with a hard-coded 150. If the shared definition was wrong too, improve the context; updating context does not rerun existing cells.

4. Check the revised output

Wait for the query and dependent cells to finish. Check their current source, errors and outputs together. In the example, the query should include A, B and G, exclude D, and return 150 USD. Check the downstream summary or chart against the same records.

An earlier output may remain visible after an edit. Up to date, idle or a success flag alone does not show that your intended cells ran. If the result has not changed, inspect execution errors and the upstream inputs. A disabled upstream cell can leave older dependent output visible. Through CLI or MCP Code Mode, check ctx.result.errors and ctx.result.run_cell_ids after the transaction, then inspect the affected cells. See notebook status and errors for the detailed rules.

If the calculation is correct but the numbers still differ, compare source refresh times, data snapshots, query cache behavior and database access. Rerunning cells alone does not prove that the source data refreshed or that a cached query was bypassed.

Check what was saved

Resolve any saving or connection error before leaving the editor. Reopen the Explore from Explores or its saved URL, select Edit and Notebook, and check that the saved source contains the correction and the stored output matches the result you checked. A reopened output alone is not proof of a new computation; execution and saving explains the distinction.

If saving failed after execution, keep the live session open and resolve the error. Do not recreate cells or replay authoring code to retry the save.

If the difference remains

5. Keep useful rules as context

Record a vetted definition or recurring exception in context so the next analysis can use it. Keep the period, units, data snapshot and any unresolved limitation with this Explore. Once the saved result makes sense, share the Explore with the intended audience.

For an execution or saving failure, use Troubleshoot Querio.