Trusting Data

• Trust is an engineering property because it decomposes into answerable questions. Where did this come from; what does one row mean; is it complete; how fresh is it; can it be reproduced; what exactly does the metric mean; who owns it. A number that answers all seven is trustworthy in a way that has nothing to do with how anyone feels about it (Data Contracts).
• Each question is satisfied by an artefact rather than by a reassurance: lineage answers provenance, a declared grain answers meaning, reconciliation answers completeness, a freshness signal answers currency, immutable raw plus deterministic transformation answers reproducibility, a metrics definition answers semantics, a catalog entry answers ownership (Metadata: Technical, Operational and Business).
• Trust is asymmetric in time. It accrues from many uneventful months in which nothing was noticed, and it is destroyed by a single event that is noticed by the wrong person. There is no proportionality between how large the error was and how much trust it cost — what matters is who saw it and whether they found it themselves.
• The reason it is so much harder to rebuild is behavioural. A consumer who has been burned starts verifying independently: they build their own extract, their own definition, their own spreadsheet. That fork is rational, it is very hard to undo, and it permanently removes the platform's ability to be the single answer (Data Platform Anti-Patterns).
• Which means the operationally important quantity is not error rate but who discovers the error. The same bug found by a freshness alert and announced proactively costs almost nothing; found by a controller during a close, it costs a year (Data Incidents).

Respond to each challenge individually. Explain why the number is right, show the query, point out that the pipeline ran successfully, and ask the consumer to trust the process.

Maintain a dataset page like the one above, updated automatically, that a sceptical consumer can read without asking anyone — including the incident history and the known gaps. Announce every restatement before it can be discovered.

dataset:      revenue_daily
owner:        data-platform  ·  #data-platform  ·  business owner: finance-ops
grain:        one row per (country, order_date)   [asserted: unique, not null]
definition:   net revenue = gross - refunds - chargebacks, order currency
              converted at the rate on order_date   [metrics layer: rev.net_v3]

freshness:    SLO 06:00 local  ·  met 98 of last 100 runs  ·  now 24 min behind
completeness: reconciled vs source nightly for closed periods
              last run: 0 rows / 0 minor units divergence   (history: 90d chart)
tests:        14 assertions, all passing        last failure: 41 days ago
lineage:      source.orders -> stg_orders -> fct_orders -> revenue_daily
              generated on every run  ·  12 known downstream consumers

revisions:    closed periods are NEVER restated without an announcement
              last restatement: 2026-02-11, Jan 1-31, +0.4%, announced 2026-02-10
incidents:    3 in the last 12 months  ·  median time-to-detection 40 min
              2 found by signal, 1 found by a consumer          <- the one that cost

KNOWN GAPS:   marketplace orders are excluded before 2025-06-01
              refunds settled after 90 days are not reflected

• Publish the evidence, not the assurance. A dataset page showing current freshness against its SLO, the last reconciliation result, the test suite's pass state and the incident history does more for trust than any amount of stated confidence (The Data Quality Dashboard).
• Make the seven questions answerable without a human in the loop. If the fastest way to learn what one row of a table means is to ask its author, the dataset is not trustworthy yet regardless of how correct it is (Dataset Documentation).
• Announce every restatement before the consumer finds it, including the small ones. Being told a number moved is a routine event; discovering it is a trust event (Rolling Back Data).
• Reconcile against the source on a schedule and publish the result whether or not it diverged. A green reconciliation nobody sees provides no trust; the same check with a visible history provides a lot (Reconciliation).
• Keep the alert set small enough that every alert is acted on. An alert that is routinely ignored is worse than no alert, because it converts an absent check into a check everyone believes exists (Quality Alerting).
• Centralise definitions where consumers can read and review them, so that two teams presenting the same metric are presenting the same computation (The Metrics Layer).

• None of this guarantees the numbers are right. It guarantees they are checkable, which is the strongest property actually available and the one consumers are really asking for.
• A published freshness signal guarantees currency and says nothing about correctness. A green test suite guarantees the assertions somebody wrote hold. Neither should be presented as more than it is, and presenting them as more is itself a trust risk (Data Tests).
• Reproducibility is guaranteed only if raw is retained and transformations are pure. A transformation that reads now() or a mutable dimension cannot reproduce last month's number, and any claim that it can is false (Idempotent Data Pipelines).
• Nothing guarantees a consumer will look at the evidence. Publishing it makes trust possible; it does not make it automatic, and the first time it is used is usually during an incident.