Is a data contract just a schema?

No. It can include meaning, freshness, usage and other expectations beyond structure.

Does writing a rule enforce it?

No. Checks and operational handling must support the relevant commitment.

Can a change be disruptive without changing the field type?

Yes. A different unit or time window can change the meaning while preserving the same type.

AI Glossary / Data governance and quality / Advanced

Data Contract

Definition

A data contract is an explicit specification of expectations about data supplied to a consumer. In the Hopsworks feature-data context used by the supplied source, it covers schema guarantees and metadata about usage and freshness, with optional service-level expectations. More generally, the useful idea is making dependencies clear enough to check and manage. A written specification does not enforce itself: the producer, consumer and supporting controls must implement the relevant commitments.

What it means

A model or downstream application depends on more than a column's name. It needs to know what values mean, which types and units to expect, how current the data should be and what uses are intended. In an original AI glossary recommendation service, a feature called recent_views could be ambiguous unless its time window and counting rule are defined. A contract makes those expectations explicit so a producer's change does not silently alter a consumer's interpretation. The document is a technical and operational agreement; the word contract alone does not establish legal enforceability.

How it works

The parties define the data interface and relevant expectations, then connect them with checks, ownership and change handling. Hopsworks describes contracts for feature groups that include schema and metadata such as freshness, permitted usage and optional lookup service levels. In an original workflow, a producer can validate a published batch against the agreed fields and rules while the consumer checks whether the version and freshness meet its needs. A failed check needs a defined response. Recording a rule is different from detecting a violation, and detection is different from deciding whether to reject, quarantine or otherwise handle the affected data.

Three practical examples

A recommendation pipeline agrees that a view-count feature is a nonnegative integer covering the previous complete calendar day in a specified time zone.
A feature producer announces a unit change through an agreed versioning process instead of replacing seconds with minutes under an unchanged field definition.
A data consumer checks the agreed freshness condition before using a batch and follows the documented response when that condition is not met.

Think of it this way

Imagine a delivery specification stating what a package contains, how it is labeled and when it must arrive. A correctly labeled package can still be late, and an on-time package can still contain the wrong item. The specification lets both sides discuss the same expectations, but someone must check the delivery and respond to failures. Similarly, a data contract coordinates requirements rather than making every delivered value correct by declaration.

Worked example

Consider an original fictional feature batch for three glossary articles. The local contract requires article_id, daily_views and window_end. Each daily_views value must be a nonnegative integer representing views during the previous complete UTC day. The batch must arrive by 02:00 UTC on the following day. The rows contain counts 12, 0 and -3, with otherwise valid identifiers and window labels. The batch arrives at 02:10. Two of three rows pass the stated count rule; the negative count fails. Separately, the arrival misses the deadline by ten minutes. Correct column names and integer types would not eliminate either problem. Now suppose the negative value is corrected to 3 but the producer actually counted a rolling 24-hour window. The numeric rule can pass while the agreed meaning still fails. These checks address different requirements. The example's dates, fields and deadline are local choices, not mandatory Hopsworks conventions, and no pass percentage establishes complete data fitness.

Illustrative case study

In a fictional AI glossary service, a recommendation pipeline consumes daily view counts. A producer changes the aggregation window while keeping the same field names and types. The pipeline continues running, but its inputs no longer mean what the model team expects. The teams revise the specification to state the window precisely, identify the affected data version and agree how future changes are communicated and checked. They also define handling for late batches explicitly. The scenario illustrates preventing silent interpretation changes. It does not claim that a contract alone repairs past predictions or guarantees a model's performance.

Common misconceptions and mistakes

A schema is an important part of many contracts, but field names and types do not express every relevant expectation. A data-quality test is also not the whole contract; ownership, intended use and change handling may matter. Another mistake is assuming that documented guarantees are automatically enforced by every tool. A consumer needs to understand which conditions are tested and how violations are handled. Finally, compatible file structure does not guarantee compatible meaning. Changing a unit, time window or inclusion rule can affect downstream behavior without changing a column's data type.

Business use

For an AI project, focus a contract on the dependencies that could otherwise surprise downstream users. In the fictional recommendation service, define the count's meaning, batch timing, owner and change process alongside the schema. Agree who investigates a failed check and what the consumer does while the issue remains unresolved. Keep the specification aligned with the implemented pipeline and the versions actually in use. This supports coordination. It does not replace evaluating whether the data is appropriate for the model's purpose or whether the resulting recommendations are useful.

Check your understanding

Answer: Which count violates the toy numeric rule? -3.

How late does the batch arrive?

Answer: Ten minutes.

Would correcting -3 to 3 fix the missed deadline?

Answer: No.

Why can a rolling 24-hour count still fail the example's contract?

Answer: The agreed meaning is the previous complete UTC day.

What needs to happen after a failed check?

Answer: The producer and consumer follow the defined handling and ownership arrangements rather than assuming the rule repairs the data automatically.

Related terms

Schema
Data Quality
data validation
feature group
data freshness
schema evolution

Learn next

Write a fictional contract for one AI input dataset, specifying fields, units, time meaning and an arrival expectation. Create one example that passes the schema but violates the meaning, and another that is correct but late. Explain the agreed response to each and how a future definition change would be introduced.

Schema

Sources

Hopsworks, Data Contract, MLOps Dictionary: https://www.hopsworks.ai/dictionary/data-contract The three-row batch, UTC deadline, delivery analogy and glossary recommendation scenario are original educational illustrations. The source grounds the feature-group context; the example's operational rules are not universal product requirements. Technical contract terminology is not presented as a determination of legal status or enforceability.

Previous: Data contamination Next: Data control