The data reliability mental model — freshness, completeness, correctness

At a glance

Learning objectives

• Name the three properties a consumer experiences — freshness, completeness, correctness
• Read a data contract's SLA section as the table's reliability promise
• Explain why an unenforced SLA is documentation, not a contract

What you need

• A table your team's consumers depend on
• The pipeline's schedule and the source's declared freshness SLA
• [object Object]

Steps

1. Reliability is the first word in DDIA's list of what data systems must balance — reliability, scalability, replication, partitioning, consistency — and every chapter maps directly to patterns in this registry. (from ref-ddia )
2. A contract has six parts — owner, schema, semantics, SLA, breaking-change policy, enforcement — and part four is the SLA (freshness, completeness). (from skill-data-contract-author )
3. Specify a freshness and completeness SLA — the two promises consumers experience first. (from skill-data-contract-author )
4. Freshness is computed, not felt — compare the schedule/cron with the source's declared freshness SLA, and when a change can produce data older than the SLA, warn with the computed worst-case lag. (from hook-freshness-pre-merge )
5. Correctness needs a written definition before anyone re-runs anything — what should the values be, and how will you check? (from runbook-backfill-required )
6. Design for the forces that never go away — retries are inevitable, backfills are routine, consumers must see stable values. (from pattern-idempotent-partition-overwrite )
7. A contract with no enforcement is documentation. Documentation is not a contract. (from skill-data-contract-author )

Check yourself

• You can name freshness, completeness and correctness for a table you consume, and say where each is declared.
• Given a cron change, you can compute the worst-case lag and say whether it violates the declared freshness SLA.

Worked example

1. Owner (a team, with an on-call).
2. Schema (typed, versioned).
3. Semantics (what each field *means*, units, nullability).
4. SLA (freshness, completeness).
5. Breaking-change policy (notice period, deprecation path).
6. Enforcement (which CI test fails on violation).

Compare the schedule/cron in the diff with the source's declared freshness SLA.
If the new schedule can produce data older than the SLA (e.g. daily when the
SLA is 6h), warn with the computed worst-case lag.

Sourced from

• Designing Data-Intensive Applications (O'Reilly)
• Data Contract Author
• Freshness Pre-Merge Check
• Backfill required
• Idempotent Partition Overwrite

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• A contract with no enforcement is documentation. Documentation is not a contract.
• The SLA miss cascades — downstream tasks sit skipped/upstream_failed until the failure is classified and recovered.
• Retries are inevitable and backfills are routine — design for them instead of hoping.

Production considerations

• Put freshness and completeness in the contract's SLA section, with the CI test that enforces each.
• Compute the worst-case lag when a schedule changes instead of trusting the cron.

Diagram

data reliability mental model
   |
   |- freshness --> declared SLA --> worst-case lag computed on schedule change
   |
   |- completeness --> SLA section of the contract
   |
   |- correctness --> written definition: what should the values be?
   |
   |- enforcement --> a CI test that fails on violation, or it is not a contract

Registry stats