How dashboards, reports, and analytical outputs accurately and consistently represent the organisation's data through agreed definitions and calculations.
DST-01
Accuracy of domain data as represented in dashboards and reports
How confident can you be that dashboards and reports built on your domain's data accurately reflect the agreed definitions, business rules, and calculations for that data, rather than a report-builder's own interpretation?
Maturity level descriptions
No check exists on whether dashboards/reports correctly represent domain data; report builders interpret definitions and calculations however they see fit. Dashboards and reports are built using whatever definitions or calculation logic the individual report builder assumes, with no verification against agreed domain definitions.
Inaccuracies are occasionally discovered and corrected once a report is already published and someone notices something looks wrong. Data Engineer or others notice, after the fact, that a published report has misapplied a definition or calculation, and it gets corrected reactively.
A defined check exists (e.g. Data Engineer review, validation against the glossary) applied to at least priority dashboards/reports before or shortly after publication. Data Engineer reviews priority dashboards/reports against agreed definitions and business rules, using a documented check.
Accuracy checks are systematically applied across the domain's dashboards/reports, with discrepancies tracked and corrected, and recurring root causes addressed. Data Engineer's domain tracks accuracy-check outcomes across dashboards/reports, with identified discrepancies corrected and recurring causes investigated.
Dashboards and reports are built on governed, certified metrics and definitions pulled directly from a single authoritative source (e.g. a semantic layer), making misapplication of definitions structurally difficult. Report builders draw calculations and definitions directly from a governed semantic layer or certified metric store rather than reimplementing logic independently, removing most opportunity for divergence.
DST-02
Traceability of visualisations back to source data and definitions
If someone looking at a chart or dashboard built on your domain's data wants to understand exactly what data it's built from, how it's defined, and how current it is, how easily can they find that out?
Maturity level descriptions
Dashboards and reports carry no information about their source data, definitions, or freshness; a viewer has no way to know what they're actually looking at. A chart or dashboard shows numbers with no accompanying information about source, definition, or data currency.
This information exists, if at all, only by asking the report's builder directly; there is no documentation a viewer could consult independently. A viewer wanting to understand a chart's source must track down and ask the specific person who built it.
Priority dashboards/reports include basic source and definition information (e.g. a footnote, a linked glossary entry) that a viewer can consult independently. Data Engineer ensures priority dashboards/reports carry basic source/definition annotations, reducing reliance on asking the builder directly.
All dashboards/reports using domain data include source, definition, and freshness information as a standard, enforced practice, kept current as underlying data changes. Data Engineer's domain has a standard requiring source/definition/freshness annotation on all dashboards/reports, checked and kept current as part of ongoing practice.
Source, definition, and freshness information is surfaced automatically and interactively within the dashboard itself (e.g. hover tooltips linked live to the catalogue), requiring no manual annotation effort. Dashboards pull source, definition, and freshness metadata live from the catalogue and surface it interactively to viewers, with no manual annotation required.
DST-03
Feedback loop: issues found in dashboards/reports traced back to source data
When a Data Consumer spots something that looks wrong in a dashboard or report built on your domain's data ("this number doesn't look right"), how effectively does that get traced back to you and resolved at the source?
Maturity level descriptions
No mechanism exists for Data Consumers to report suspected issues in dashboards/reports back to the Data Engineer; concerns are raised informally, if at all, and go nowhere. A Data Consumer who suspects a number is wrong has no clear way to raise it, and typically either ignores it or mentions it informally with no follow-up.
Issues are occasionally reported informally (a hallway comment, a one-off message) and investigated ad hoc, with no consistent process or tracking. Data Engineer occasionally hears about a suspected issue informally and looks into it without a defined process or record.
A defined channel exists (e.g. a "report an issue" mechanism on the dashboard, a data issue ticket queue) that Data Consumers are encouraged to use. Data Engineer receives dashboard/report issue reports through a specific, named mechanism, with the issue recorded.
Reported issues are logged, tracked to resolution, and the root cause is identified in source data, metadata, or calculation logic, with the reporting user informed of the outcome. Data Engineer tracks dashboard/report issues to resolution, identifying whether the cause was source data, metadata, or calculation logic, and informs the reporting user.
Issue reporting is frictionless and directly embedded in dashboards (e.g. an in-context "flag this" control), with resolution patterns feeding back into DV-1 accuracy checks and DV-3 documentation practices to prevent recurrence. Business users can flag a suspected issue directly within the dashboard interface, with resulting fixes systematically feeding back into accuracy-check and documentation practices for the domain.