In 2011, a federal inspector general tried to answer a simple question: was a government agency's hiring process getting faster? The agency's own dashboard said it was tracking time-to-hire. The auditors found key dates missing, records that didn't match the underlying case files, and HR staff quietly rebuilding numbers by hand because the system of record couldn't be trusted. Their final conclusion wasn't "hiring is slow." It was that they couldn't tell, because the KPI itself was unreliable.
That's the failure mode a dashboard hides best: not a wrong number, but a number nobody can actually stand behind. You don't need to audit the pipeline yourself to catch it. You need three questions, and you need to notice when the answers are reassurance instead of specifics.
1. What exactly was checked?
"The data is clean" is not an answer. Ask whether duplicates were tested, whether joins preserved the intended row grain, whether missing values were handled deliberately, and whether the metric definition matches the question being asked. A good answer names checks and boundaries: "we tested for duplicate account IDs and found none above our threshold, but we didn't check for near-duplicate names." That's a real answer, because it tells you exactly where the coverage ends.
2. What period and version does this represent?
Ask when the source was last refreshed, when its meaning was last verified, and which policy, schema, or business definition is in force. Those are different clocks, and conflating them is how a table can be technically current and practically wrong at once: the pipeline ran on schedule this morning, but the pricing rule it applied was replaced last week and nobody updated the join. A successful refresh proves the machinery ran. It doesn't prove the data still describes the world the dashboard claims to describe.
3. What did you find and decide not to fix?
A trustworthy process produces exceptions, plural, because real data always has some. The important question is whether someone can name one, explain its likely impact, and identify who accepted the residual risk. GSA's auditors ran into the opposite pattern: a system with no visible exceptions turned out to be one where the limitations had simply never been written down, not one where none existed.
None of these three questions substitutes for actual controls, and asking them once doesn't fix a broken pipeline. What they do is cheap and fast: they tell you in about ninety seconds whether the person presenting the dashboard can trace it back to something real, or whether "the data is clean" is doing all the work reassurance usually does.