What you will take away
- A contract includes meaning and responsibilities, beyond names and types.
- Quality must be checked against the intended use of the data.
- Version incompatible changes and test consumers before migration.
- Use authorized, traceable data as the foundation for AI systems.
A correct schema can answer the wrong question
An assistant can query a sales table with valid types and return an incorrect answer if it confuses created orders with collected payments. It can also sum amounts in different currencies or present yesterday’s data as current. The failure is not always in the model: it may be in a meaning that nobody documented.
For an AI-oriented architecture, the contract should explain what each record represents and which questions it can answer. This October 2026 edition proposes an approach to data readiness; it does not introduce a new certification or a universal rule for every assistant.
Start with a small, usable contract
| Element | Example for collected sales |
|---|---|
| Identity and version | sales_collected, contract 1.0 |
| Granularity | One row per confirmed payment, not per order |
| Fields and meaning | payment_id, amount, currency, paid_at |
| Time | paid_at in UTC; agreed refresh schedule |
| Quality | Unique identifier, explicit currency and required amount |
| Owner | Payments team and designated operational contact |
| Access and retention | Authorized roles and policy-defined retention period |
This is a synthetic example. Its value lies in producers and consumers agreeing on the same rules, rather than in the name of the file describing them. Store the contract alongside its change history and connect each rule to an executable check or an explicit review.
Define what blocks, what alerts and what can wait
Not every breach requires the same response. A duplicate payment key may block publication; a missing optional description may raise a warning. A delayed source needs a freshness rule and a decision about whether the consumer receives older data, an age indicator or no answer.
Google Cloud documentation distinguishes row-level checks with passing thresholds from aggregate rules evaluated across the dataset. [1] This distinction helps design your own controls: “each payment has a currency” and “the batch total matches the source system” validate different things.
- Completeness: required fields present and nulls explicitly handled.
- Uniqueness: agreed keys without unexpected duplicates.
- Validity: types, ranges and allowed values.
- Reconciliation: counts and totals by currency compared with the source.
- Freshness: event time and refresh time clearly separated.
Avoid turning an arbitrary threshold into a commercial promise. Negotiate tolerances with the consumer and test a case that should fail. A rule never tested with a known violation provides little evidence of protection.
A change in meaning also breaks the contract
Renaming a column is visible. Changing a time zone, unit or definition of “active” may be more dangerous because the schema stays unchanged. Classify changes by their actual impact: adding an optional field may be compatible, but only if consumers tolerate additional fields.
For an incompatible change, publish a new version, identify consumers, communicate the deadline and run comparison tests. Maintain the previous contract during an agreed transition when practical. Define who can approve migration and how to return to an earlier version without losing new events.
The contract accompanies the data used by AI
If an AI system queries data or retrieves it from an index, retain provenance, effective date and contract version alongside the relevant information. Restrict access to the authorized context and apply retention to extracts and derived indexes too. Making a copy does not remove obligations attached to the original data.
Evaluate specific questions: which period does the answer cover, which currency does it use, are cancelled payments included, and is the user authorized? Structured outputs can help organize answers, but they do not guarantee semantic accuracy. [2] When evidence is missing or data is stale, the system should express that limitation according to its policy.
From contract to an operable Dova workflow
In Dova, a Mapping can represent documented transformations and quality rules. The reference describes required-field, type, pattern, range and allowed-value checks; their thresholds do not automatically create a quarantine output. [3] Verify the action your design actually performs when a rule fails.
Link the contract version with the Mapping version and record the Session and Workflow used in the trial. Independently verify columns, values and counts. The operation guide recommends distinguishing a completed execution from a correct result. [4] The contract still requires owners and agreements outside the canvas.
Start with a high-value dataset and a few consumers. Measure contract incidents, detection time, recovery time and migrated consumers. Expand the method when the team can explain its response to a breach, rather than simply display a document catalog.
Questions worth asking
Is a data contract the same as a schema?
No. A schema describes structure; a contract adds meaning, granularity, quality, freshness, access, responsibilities and change handling.
Do I need to buy another tool?
Not necessarily. Start with a versioned definition, clear owners and pipeline checks. Catalogs or automation should solve actual needs.
Does a contract guarantee correct AI answers?
No. It reduces ambiguity and adds verifiable controls, but you must also evaluate queries, permissions, information retrieval and model responses.
Where Dova fits
A governed integration can make responsibilities and execution visible. Review Dova's documentation for mappings, workflows and monitoring, and define the business quality rules your team needs to implement.
Sources & further reading
- About auto data qualityGoogle Cloud Documentation · Accessed
Row-level thresholds, aggregate checks and explicit quality rules; no October 2026 product announcement is claimed.
- Structured model outputsOpenAI · Accessed
Structured response shape does not establish semantic truth.
- Transformaciones y reglas de calidadCloudata · Dova Docs · Accessed
Documented required-field, type, pattern, range and allowed-value checks and their limits.
- Seguridad y operación: ejecutar, recuperar y retirar recursosCloudata · Dova Docs · Accessed
Execution evidence, authorized context and independent output validation.
Practical guidance for the October 2026 edition. Sources support the technical principles; examples are illustrative, not product announcements or customer results.