Reconcile totals against a trusted source (finance, the source system, a known-good query), spot-check a few rows end to end, and confirm filters and date logic behave at the edges — empty selection, a single day, a year boundary — at every drill level. A dashboard that is wrong once loses trust for good, so validation is the job, not an afterthought.
How to answer it
Validation is the job, not a step after it. A dashboard that is wrong once loses trust for good, so ship it only when you can say how you know it is right.
Reconcile the totals. The headline numbers against a trusted source: finance for revenue, the source system for counts, a known-good query for anything else. Exact match, or a documented reason for the difference.
Trace a few rows end to end. Pick three specific orders or users and follow them from the source through every transformation to the tile. This catches join fan-out and filter mistakes that totals can hide.
Test the edges. An empty filter selection, a single day, a month boundary, a year boundary, a timezone edge, a segment with no data. Every drill level, because a total can be right while a breakdown double-counts.
Check the definitions. Every metric on the page has a definition written next to it, and that definition matches the model it reads. "Active users" on this dashboard means the same thing as on every other.
Check the refresh. When the underlying data updates, does the dashboard, and does the page say when it last did?
Get a second reader. Someone who did not build it, ideally the person who will use it, spends ten minutes trying to break it.
Then a short note in the dashboard's description: what was reconciled, against what, on which date. When a number is questioned later, that note is the answer.
What they are checking: reconciliation against an external source, row-level tracing, and edge cases at every drill level.
Common mistake: checking that the dashboard matches the query that built it. That checks the tool, not the number.