Define the decision and the metric
Start with the decision the dashboard supports and the cost of a wrong or late number. Define each important metric in business terms: population, period, timezone, inclusion rules, exclusions and owner. Revenue, active customers and available inventory can each have several legitimate definitions. The chosen meaning must be explicit and consistently applied.
Record the required level of freshness and acceptable uncertainty. A monthly management review and an operational stock decision need different update behaviour. Show the reporting period and last successful refresh to users. A recent page-load time should not be presented as evidence that the underlying data is current.
Agree data contracts at source boundaries
For each input, specify required fields, identifiers, types, valid values, nullability, expected delivery timing and schema-change handling. Identify the source owner and the receiving team. These agreements make assumptions testable before a source change silently alters a report. They can begin as documented rules and evolve into automated checks.
Select quality dimensions that match the use: completeness, uniqueness, consistency, timeliness, validity and accuracy. They describe different properties. A record can satisfy a date format while containing the wrong date, and a complete table can contain duplicate business events. Passing structural checks does not establish that a reported fact matches reality.
Reconcile across transformations
Compare record counts and relevant control totals at ingestion, transformation and reporting boundaries, using the same units and period. Explain intentional exclusions and aggregation. Check join cardinality: a supposedly unique lookup key with two matches can multiply rows and inflate totals without creating an obvious technical error. Validate deduplication against the business definition of an event.
Handle late arrivals, corrections, currency conversion and timezone boundaries explicitly. Test incremental loads for repeated or missed records and establish how backfills affect earlier reports. Use known examples and sampled source records to challenge the transformations. A successful pipeline execution only confirms that the configured process ran, not that its business result is correct.
Make exceptions visible and actionable
Define thresholds by consequence and assign an owner to each material failure. Decide whether a failed check blocks publication, quarantines records or permits a clearly labelled provisional result. A dashboard should not quietly display partial data as complete. Retain enough context to identify the affected source, period, transformation and downstream outputs.
Avoid silently filling critical missing values with plausible defaults. Such defaults can turn a visible failure into a credible but wrong metric. Record the reason for an exception, its treatment, authorisation and review date. Protect exception logs and samples with appropriate access because troubleshooting data may contain the same sensitive information as the source.
Preserve lineage and control metric changes
Maintain a traceable relationship from a reported measure to source datasets, transformation versions and calculation rules. The level of detail should support the decisions and investigation needs of the organisation. Record a stable release reference for important reporting changes so a reviewer can explain why two versions of a dashboard differ.
Review changes with the metric owner, test representative cases and compare against the previous definition. Decide whether historical periods are recalculated, frozen or presented under separate versions. Explain material changes to users. Altering the definition while leaving the label unchanged can create a misleading trend even when every individual calculation is internally correct.
Build acceptance around evidence
A reporting acceptance pack should contain metric definitions, source agreements, transformation and reconciliation checks, known exceptions and approved sample results. Include freshness monitoring and a response owner. Ask a business reviewer to trace a meaningful number back to supporting records, rather than approving the dashboard only on appearance.
TRUST-IT can assess an existing dashboard or design data-quality controls alongside analytics and integration projects. Deliverables can include a metric catalogue, source-to-report lineage map, automated quality checks, reconciliation evidence and an exception workflow. The objective is information that decision-makers can interpret and challenge, with visible limits when the evidence is incomplete.
Further reading
Put the guidance to work
Data pipelines, databases, business intelligence, forecasting, and preparation of data for AI.
Data engineering & analytics