A validation and UAT layer that tests analytical outputs before publication, with expected result, actual result, severity and PASS/WARN/FAIL controls.
A chart can be neat, colourful and completely wrong if a duplicate row, missing period, invalid date or broken join entered the model. In reporting work, the question is not only “Can I calculate the KPI?” but “Can I prove the number is safe to publish?”
I wanted a repeatable UAT layer that checks the analytical models before their numbers are shown publicly, and that keeps warnings visible instead of hiding them.
I created a catalogue of 22 validation tests covering completeness, uniqueness, allowed values, date logic, keys, ranges and source coverage. Each test has an expected result, actual result, severity and PASS/WARN/FAIL outcome.
Run repeatable tests against the analytical datasets.
Define what fields and valid values should look like.
Separate blocking failures from explainable warnings.
Stop a failed analytical run from silently replacing trusted numbers.
With the problem and data purpose clear, the next section shows the result first. The detailed steps below then show exactly how I got there.
The warning remains visible because two historical comparison values are genuinely missing. Replacing them with zero would create a false result.
Yatify UAT validation catalogueDefined expected results before running each test.
Built completeness, uniqueness, domain, range, date and key checks.
Separated PASS, WARN and FAIL and applied publication rules.
Kept evidence files linked to each validation result.
A dashboard can be visually correct and still be wrong. Management reporting needs evidence that keys, dates, ranges, source gaps and reconciliations were actually tested before publication.
Each of the 22 checks is stored as a controlled record containing the analytical area, the rule being tested, the expected result, the actual result, severity and final status.
areatestexpectedseverityactualstatusevidence_filePassed tests ÷ Total tests × 100÷ × 100 = 0.0%.
That does not mean “ignore the other 4.5%”. The one warning remains visible because it affects source coverage.Historical comparison gapsExpected: documented source gaps. Actual: 2 missing historical comparison values.
Action: keep them missing. Do not replace them with zero, because zero would mean “no movement”.High-severity FAIL → stop publicationCurrent run: FAIL, WARN, PASS.
A warning can remain only when its limitation is understood and disclosed.The headline chart gives the decision signal. These additional views show whether the same conclusion survives when the data is sliced another way.
The analytical models pass their blocking tests.
The correct treatment is to disclose the missing comparison periods, not manufacture values.
A future high-severity FAIL would stop the dashboard update until reconciled.
The current test run covers portfolio datasets, not every future Yatify source. Production API pipelines require additional source-specific reconciliation tests.
Every interactive chart above already has a CSV button for its exact plotted numbers. These files are the deeper audit trail: source extract, model, SQL/DAX and validation.