Skip to content
AlgoCoder
Report № DA-06Data EngineeringSub-pattern · Quality + observability06 / 12

Data Quality and Lineage Implementation for a Reporting Layer Nobody Trusted

The dashboards showed numbers. Nobody trusted the numbers. Decisions were being made by gut.

§ Client

An organization with mature reporting infrastructure — dashboards, models, scheduled deliveries — and a workforce that had stopped relying on it. Reports had been wrong often enough that even when they were right, leadership treated the numbers with skepticism. Decisions that should have been data-driven were being made on the basis of executive intuition because the executives had stopped trusting the data.

§ Problem

The leadership had concluded that the trust problem wasn't going to fix itself. Either the reporting infrastructure became reliably correct and demonstrably so, or the organization's data investment would continue to fail to produce the decision-quality improvements it had been built to support.

§ Engagement

A data quality and lineage layer covering the reporting stack end-to-end.

Data quality expectations were defined at every meaningful boundary. Source ingestion checks. Transformation invariants — sums that should match across joins, counts that should hold across aggregations, freshness windows that should not be exceeded. Output checks before reports were published. Each expectation was instrumented with Great Expectations or equivalent tooling.

Failures of expectations were surfaced visibly rather than absorbed silently. A report that depended on data that had failed quality checks was marked as such; consumers saw the quality status alongside the numbers. Reports that passed all checks displayed the validation status to communicate provenance, not just the numbers.

Lineage was instrumented across the transformation stack. Every metric in the reporting layer could be traced back through the transformations and source systems it depended on. When a number was questioned, the answer to "where does this come from" was a lineage view rather than an investigation.

Anomaly detection was added on top of the metrics themselves. Numbers that changed in ways inconsistent with their historical patterns surfaced as anomalies for review rather than being absorbed as new normals.

A quality dashboard was built specifically for the data team — not the consumers — showing the health of every pipeline, every quality check, and every report. The team gained a unified view of where to focus remediation effort instead of discovering quality issues from downstream complaints.

§ Outcome

Reports shipped with provenance. The visible quality indicators surfaced where reports were trustworthy and where they weren't. Trust returned not because every report became correct overnight, but because consumers could distinguish reliably between the reports they could act on and the ones still being investigated. The data team's remediation work became targeted rather than reactive.

The cultural change was as material as the technical one. The data team stopped being the team that produced numbers people doubted. Numbers had provenance, and consumers had a basis for trusting or questioning them.

End of Report
DA-06 · Data
End of Transmission

Building something with shape similar to this?

Talk to a Data Architect →