Data Contracts Explained: Stop Bad Data Before It Reaches a Dashboard

Updated October 13, 2026 · Practical data engineering

A sales dashboard shows a sudden 40% revenue jump. The team celebrates. Two days later, an analyst discovers that a source system changed a price field from dollars to cents, and the pipeline accepted the values without a warning. The exact percentage in this scenario is fictional, but the failure mode is real: a pipeline can run successfully while producing incorrect decisions.

A data contract is an explicit agreement about what a dataset should contain, how fields should be interpreted, who owns changes and what happens when expectations are violated. It can include schema, units, allowed values, freshness, uniqueness, privacy constraints and change procedures. The important shift is from "the file loaded" to "the data still means what we think it means."

Why schemas are not enough

A schema may say that amount is a number. It may not say whether that number is in dollars, cents or another currency. It may not prevent a timestamp from being recorded in the wrong time zone. Nor does it guarantee that two systems use the same definition of an "active customer."

Good contracts capture both structure and meaning. They should also define who is accountable for the contract. A perfectly documented field with no owner can still break when a source team changes its export process.

A small example: online orders

Suppose an analytics team receives an orders table. It needs a unique order ID, a timestamp, a currency code, an amount in minor units and a status. The following example is illustrative, not a universal ecommerce standard.

The team must still decide how to represent refunds, canceled orders and negative adjustments. A contract should not hide those business rules behind a generic validation function.

Validation is a gate, not a dashboard decoration

Great Expectations documentation defines an Expectation as a verifiable assertion about data and an Expectation Suite as a collection of such assertions. The concept is useful even if you do not adopt a specific library: make assumptions executable and report failures with enough context to investigate.

A robust pipeline can use three outcomes: accept records that meet the contract, quarantine suspicious records for review, and reject or stop processing when a critical invariant fails. The right policy depends on impact. A missing optional marketing tag might deserve a warning; duplicated payment transactions may justify stopping financial reporting.

A minimal Python validation example

The following code checks a tiny, synthetic batch. It deliberately uses only the standard library so the idea is visible without framework setup.

orders = [
    {"order_id": "A1", "amount_minor": 1299, "currency": "USD"},
    {"order_id": "A2", "amount_minor": -50, "currency": "USD"},
]

seen = set()
errors = []
for row in orders:
    order_id = row.get("order_id")
    if not order_id or order_id in seen:
        errors.append((order_id, "missing or duplicate ID"))
    seen.add(order_id)
    amount = row.get("amount_minor")
    if type(amount) is not int or amount < 0:
        errors.append((order_id, "invalid amount for ordinary sale"))

print(errors)  # [('A2', 'invalid amount for ordinary sale')]

The example is intentionally narrow: real systems must handle refunds, schema evolution, nulls, privacy and failure reporting. Do not apply the non-negative rule to a ledger that legitimately represents credits as negative amounts.

What to do when the upstream team changes a field

Treat changes as versioned events. A producer should announce a proposed change, provide sample records and identify whether it is backward-compatible. Consumers should test the new format against existing queries. If a field is renamed, provide a migration window or an explicit mapping. If a unit changes, never silently reinterpret old records.

Data quality also needs lineage: knowing which inputs and transformations produced a metric. Without lineage, teams may know that a dashboard is wrong but spend days identifying the upstream source. Record source tables, transformation versions, run times and downstream consumers wherever practical.

Metrics that help more than a single "quality score"

Track freshness, completeness, validity, uniqueness and reconciliation separately. A composite score can conceal a severe problem. A dataset that is 99.9% complete can still be unusable if the missing 0.1% contains all high-value transactions. Evaluate quality against the business decision, not only a generic percentage.

For an executive dashboard, establish a release criterion: the source is fresh enough, totals reconcile with an authoritative system, key dimensions are valid and anomalies have an owner. For a machine-learning pipeline, additionally monitor distribution shift and whether training and inference use consistent definitions.

A one-week implementation plan

Start with one important dataset and its top three downstream decisions. Interview the producer and consumers to identify hidden assumptions. Write a short contract, automate five critical checks and agree on escalation ownership. Test a deliberately broken batch to confirm that the alert reaches a person and the dashboard does not quietly publish corrupted numbers.

The goal is not to validate everything imaginable. It is to make the assumptions behind important decisions visible, testable and maintainable. A modest contract that catches a costly unit error is more valuable than a large dashboard of meaningless quality metrics.

Sources and editorial notes

• Great Expectations, Define Expectations, documentation checked October 13, 2026.
• Great Expectations, Run Validations, documentation checked October 13, 2026.

Related reading: Global Economic Forecasts and Python 3.14. Reader action: Write down the units, owner and failure policy for one critical dataset.