The strong rivalContracts can obstruct evolution

A rigid contract can couple producers to every known consumer, preserve obsolete fields and turn a platform into a queue for metadata approval. Unknown consumers make the obligation worse. If the product team must anticipate every downstream transformation, it stops improving the source. Consumers then work around the process, creating unofficial copies that are less visible and harder to repair.

Accept the pressure for evolutionary speed. Define compatibility through observable consumer behaviour, permit genuinely additive evolution and provide a versioned path for breaking change. Time-bound support is healthier than permanent preservation. The core contract should contain stable domain commitments, while population rules, task-specific transformations and stricter decision thresholds belong in governed adapters. Producers support the promise they publish; consumers register dependencies and remain responsible for their adapters.

Contract fields are not the objective. A complete template with no operational owner is administrative theatre. Use a field only when it supports discovery, validation, enforcement, incident response or retirement. Where a clause cannot be checked by software, identify the accountable person, review event and evidence. The contract earns its cost when a defect or proposed change can find affected consumers, choose a safe response and confirm repair before the next machine decision.

Five different objectsDo not collapse discovery, shape and promise

A dataset is a bounded collection of records or events. A catalogue entry helps people or machines find and describe it. A schema constrains structure and some values. An interface specification describes how to request or receive it. A machine-use data product combines those components with supported purposes, business meaning, temporal behaviour, provenance, rights, quality, service, change and lifecycle obligations.

Each object catches a different failure. A catalogue can reveal an owner but cannot prove that the owner responds to incidents. JSON Schema can reject an integer where a string is required, but it may accept a stable string whose meaning has changed. OpenAPI can describe a successful response while the facts are too old for the decision. A quality rule can show overall completeness while a decision-critical cohort falls below a hard gate. Policy metadata can describe a restriction while an endpoint fails to enforce it.

FAIR principles improve findability, accessibility, interoperability and reuse. Those qualities are valuable, especially when machines must discover and interpret distributed assets. They do not establish permission, a production service level or fitness for a consequential decision. Treat FAIR, DCAT, PROV-O, DQV and open contract formats as components of an implementation. The product promise remains accountable to the specific domain, operating model and consumer behaviour.

Original constructThe Machine-Use Data Product Contract

The nine-clause contract is this article's synthesis. It is a product-level promise that can support several consumers without claiming universal fitness. Each clause has human-readable intent, structured fields, validation, an owner and an expiry or change trigger.

Non-compensable clauses: a product cannot average a missing entitlement, contradictory meaning or unreconstructable provenance into an overall passing score. The failing clause determines the route.

The contract should link rather than duplicate authoritative sources. Business definitions may live in a governed vocabulary, interface shape in JSON Schema or OpenAPI, provenance in a PROV-compatible record, quality observations in a DQV-compatible store, and policy decisions in an entitlement service. The product identifier and version bind those pieces. A human reader sees the whole promise; machines resolve the components they need to test.

Start with what the producer can genuinely support. A domain owner may promise a stable legal-entity identifier, effective-dated status events and a correction route. It should not promise fitness for every future agent. Consumers declare their decision, population and required thresholds. The combined evidence forms a usable contract without moving specialised obligations into the core.

Stable core, governed edgeInheritance without hidden transformation

The reusable core owns domain semantics, source provenance, common rights attributes, service behaviour and compatible evolution. A consumer adapter inherits those clauses and adds its decision-specific population, temporal horizon, entitlement, transformations, joins, quality gates and evaluation. The adapter must declare what it changes and which core promises it relies upon.

This separation prevents two forms of bloat. Producers do not have to embed every consumer's specialised threshold in the shared product. Consumers do not have to copy the core into private pipelines. If several adapters repeat the same well-supported rule, the product owner can promote it into a new core version. Until then, inheritance remains explicit and individually governed.

An undeclared adapter is a break in the contract chain. A team may join a customer table to support notes, impute missing values and place the result in a prompt. When an upstream correction arrives, nobody can identify which context was affected or replay the output. Register the adapter, transformation version, dependency and downstream use. The goal is not central approval of every line of code; it is traceable responsibility for changes that alter machine behaviour.

Exploration needs proportional terms. A low-consequence analyst may use a versioned snapshot with caveats, restricted destinations and no production availability promise. The adapter records that boundary. Requiring a full production service level would add delay without reducing the actual risk. If exploration becomes recurring or affects users, the contract must be strengthened before the use expands.

Compile before consumptionTurn terms into gates and receipts

Contract compilation resolves the product and adapter versions, validates their structure, checks required clauses and creates executable assertions. Discovery should return supported purposes and prohibited uses. Retrieval should call the entitlement service for the actual consumer, purpose and attributes. Ingestion should verify schema, code sets, temporal fields, provenance links and quality gates. A proposed change should run registered consumer tests before release.

Not every term is reducible to software. A domain steward may need to attest that a definition still matches current practice; privacy or legal owners may decide whether a new destination is permitted; an operations owner may accept a time-bound service exception. Encode the control point, accountable role, evidence reference and expiry so the runtime can distinguish a valid human decision from an empty field.

Tests should examine meaning and behaviour, not only syntax. Sample boundary records for semantic mappings. Reconstruct effective-time cases. Evaluate missingness and coverage by declared cohort. Exercise policy decisions with multiple roles. Simulate stale data, partial delivery and revoked access. Run consumer outcome tests against a proposed diff. A test suite that only parses the contract proves that the document is well formed, not that the product promise holds.

Failure happens before the values reach the agent. A hard semantic contradiction, forbidden purpose or failed cohort gate blocks retrieval or compilation. A temporary service exception may activate an approved fallback. A warning may suffice for exploratory work inside a declared snapshot boundary. Every branch emits a receipt that records the clause, evidence and action, giving incident teams a path from machine output back to the product conditions used.

From specification to serviceOperate the contract as a shared control surface

Begin product registration with a producer and consumer walkthrough, using actual decisions and boundary records rather than a blank form. The producer explains how entities arise, how facts change and how corrections reach the interface. The consumer explains the action, population, timing and downstream transformation. Differences become explicit contract or adapter terms. The meeting should finish with named owners and evidence, not a declaration that the data look reasonable. A contract compiler can then verify that required fields, references and tests exist while the people remain accountable for their meaning.

Place contract checks at several points because no single gate observes the whole lifecycle. Registration validates identifiers, ownership and linked specifications. Discovery filters products by declared purpose and exposes exclusions. Access evaluates current entitlement. Build and deployment test adapters against representative versions and proposed diffs. Runtime checks the snapshot, event range, freshness and hard quality gates. Monitoring connects service and population signals to the active versions. Change review reruns affected consumer behaviour. Retirement closes dependencies, entitlements and retained artefacts.

Give producers evidence about consumption without exposing sensitive downstream details. They need registered consumer identifiers, supported versions, notice contacts, broad purpose and test status. Consumers need product definitions, changes, exceptions, incident status and repair evidence. Risk, privacy and operations teams need the clauses relevant to their controls. A single unrestricted catalogue record is unlikely to suit all audiences. Resolve views from the same contract while enforcing who may inspect policy, lineage, examples and operational telemetry.

Make exceptions first-class and temporary. A service owner may accept delayed history for a bounded period, or a consumer may proceed with a documented cohort exclusion during repair. Record the affected clause, scope, rationale, approver, compensating control, start, expiry and invalidation event. The runtime receipt references the exception. Expired exceptions fail closed or activate the declared fallback. Permanent caveats hidden in prose indicate that the core promise or consumer adapter needs redesign.

Test the recovery path before relying on it. Preserve an earlier compatible version when rollback is promised, and confirm that its data and policy remain available. Exercise consumer migration with representative outputs, including records at semantic and temporal boundaries. Verify that notices reach machine owners rather than only distribution lists. During an incident, state which product versions and event ranges are affected, which clause failed, whether retrieval is blocked and how corrections will be issued. A generic data quality alert gives an agent operator too little to decide safely.

Review the contract's value through failures prevented and repairs completed, not metadata volume. Useful signals include changes stopped before release, hidden dependencies registered, incidents traced to affected outputs, expired exceptions closed and consumers migrated before retirement. These are operating observations rather than a maturity score. They show whether the promise changes behaviour. If every field is populated but consumers continue to bypass the product, the organisation should simplify the contract, improve its interfaces and remove incentives for unofficial access.

Beyond query successCompatibility is a typed behavioural diff

A useful diff classifies structural, semantic, population, temporal, policy and service change. Structural change covers fields, types, nullability, code sets and interfaces. Semantic change covers definitions, entities, relationships and units. Population change covers collection channels, exclusions and cohort composition. Temporal change covers clocks, delay, corrections and history. Policy change covers purpose, entitlement, retention and destination. Service change covers availability, latency, volume, cost, support and incident behaviour.

The customer-status example is structurally stable and semantically breaking. The producer must issue a new contract version, show the definition and entity change, run registered consumer tests, provide a migration or retained old field, and keep the prior version for the support window. If a collections agent depends on legal-entity status, the change remains quarantined until its behaviour is proven or its adapter is migrated. Keeping the endpoint alive does not make the change compatible.

An additive field can also break behaviour. Suppose a ranking adapter treats absence as unknown but zero as negative. A producer adds a nullable risk indicator; the consumer's deserialiser accepts it, yet its generic feature loop includes the new field and changes ordering. The diff should flag changed input surface and run the consumer outcome test. Compatibility depends on declared behaviour, not on the comforting label additive.

Freshness failure illustrates another boundary. An API may remain fast and available while effective business facts exceed the age permitted by the decision. The service-level clause and temporal clause must be checked separately. The product can return a machine-readable stale condition, withhold the affected range or activate a bounded fallback. Latency success cannot offset invalid effective time.

Policy compatibility requires an enforcement test. Discovery may legitimately expose that a restricted attribute exists, while retrieval must evaluate the consumer, purpose, role and destination. Copying an entitlement statement into catalogue metadata is insufficient. Attempt permitted and forbidden requests, record the policy version and propagate restrictions into derived stores. A change that broadens availability without the required decision is a breaking policy change even if no schema moves.

Quality compatibility uses consumer slices and hard gates. A domain product may publish general measures, but an adapter identifies the cohort and field that control its action. If overall completeness remains above a service objective while that cohort drops below its gate, the consumer test fails. An average cannot finance unsupported treatment of the affected group. Repair the source, narrow the population or keep the change quarantined.

Version rules should be comprehensible and enforced. Backwards-compatible corrections can move within a supported version when they preserve defined behaviour. Breaking changes receive a distinct version, typed diff, notice and migration path. Emergency corrections still need a recorded reason and impact analysis. The contract should name the fallback and rollback rather than assuming the producer can restore a state it has not preserved.

Unknown consumers are a product risk shared across domains. Registration should be easy and valuable, returning notices, evidence and incident support. Platform logs can identify repeated reads, service accounts and prompt configurations that bypass the registry. Do not promise protection to an unregistered consumer, but investigate hidden use before a destructive change. A retirement plan without dependency evidence may remove an input whose only trace sits inside an agent's prompt template.

Contract to runtimeIssue evidence for each consumption

Compilation produces a receipt for each batch, event range or retrieval session. It records the product and contract version; consumer, decision and declared purpose; entitlement result and policy version; schema, semantic and temporal checks; snapshot or event range; provenance; quality evidence and accepted exceptions; adapter transformations; downstream context use; incident route; correction status and expiry.

The receipt answers two incident questions quickly: what conditions supported this output, and which outputs used the defective condition? If a source correction changes a historical status, provenance identifies affected snapshots, adapter versions and downstream traces. The product team can notify registered consumers; consumers can decide whether to replay, correct records, contact affected users or document why no change is needed.

A receipt is not a dump of every record. Use identifiers, hashes, version references and controlled evidence appropriate to the sensitivity. The contract defines retention and authorised access. Preserve enough to reproduce the decision path without creating an uncontrolled secondary dataset. Where a human approved an exception, record the role, evidence and expiry rather than an unexplained override flag.

Link telemetry to contract clauses. Availability and latency support the service promise; schema results support structural terms; cohort measures support quality terms; policy decisions support rights; lineage supports provenance. A monitoring dashboard that cannot identify the relevant product and contract version leaves operators guessing. The same linkage helps retire obsolete telemetry when the product closes.

Ownership under pressureIncidents, dependencies and retirement

Product ownership becomes visible when the promise fails. The contract names the operational owner, support hours, severity route, consumer notice mechanism, correction semantics and repair evidence. A producer should be able to distinguish source error, delayed update, semantic disagreement, unauthorised retrieval and consumer-adapter defect. Consumers remain responsible for their own transformations, but the shared receipt prevents an argument based only on system boundaries.

Feedback should enter through a controlled defect and correction path. A consumer supplies the product version, affected range, clause and evidence. The producer assesses whether the issue is local, systemic or a definition dispute. Corrections preserve effective and supersession time where history matters. Release evidence identifies which tests passed and which consumers were notified. Usage counts may guide support, but popularity does not make an unsupported meaning valid.

Maintain a dependency register that includes consumer identity, adapter, purpose, contact, version, expected notice and fallback. Compare it with access logs, event subscriptions, scheduled jobs and configuration stores. The gap between observed and registered use is itself a risk signal. A hidden agent that accesses data only through a prompt-configured tool can disappear from conventional lineage. Find it before a breaking change or retirement.

Deprecation begins with a proposed end state, dependency evidence and support window. Consumers need a replacement, migration test, fallback and a way to contest an incomplete inventory. At closure, block new use, revoke entitlements, retire adapters, address retained data, preserve required audit evidence and issue a closure record. Archival access must retain the former contract so historical decisions remain interpretable.

Reject or retire a product when no accountable owner can support its meaning, provenance, rights, service or change obligations. A popular endpoint with no repair capacity is an unmanaged dependency. Keeping it discoverable transfers uncertainty into every machine consumer. Retirement may require a staged migration, but the final decision should be explicit rather than an indefinite warning attached to unreliable data.

Interactive instrumentData Product Contract Compiler

Describe the core, consumer, enforcement and proposed change. The Compiler returns one of five routes with the missing clause and next control. It does not calculate a product score.

Exactly five outcomesWhat compilation permits

Publish as a reusable machine-use data product

Use when the core clauses are stable, accountable and tested for the declared reusable purposes. Publish the supported boundary, contract version, interface, notices and runtime receipt requirements. New decisions still require qualification.

Publish the core with a governed decision adapter

Use when the domain promise is reusable but population, time, transformation, entitlement or evidence differs for one consumer. Register inheritance, additional tests, owner and expiry. An exploratory snapshot can use this route with an explicit caveat and no implied production service level.

Repair semantics, provenance, quality or service terms

Use when meaning is incomplete, lineage breaks, a cohort gate fails, freshness is invalid, entitlement is not enforced or the owner lacks operational capacity. Repair the responsible clause and rerun the consumer evidence before machine use.

Quarantine the change until consumer compatibility is proven

Use when a semantic, additive, temporal, policy or service diff could change registered or hidden consumer behaviour. Hold release, identify dependencies, run outcome tests and provide migration, fallback or rollback.

Reject or retire the unsupported data product

Use when the purpose is prohibited, no accountable owner can support the promise, provenance cannot be reconstructed, the service has failed without a safe route or lifecycle evidence requires closure. Remove access through a managed transition and preserve required historical interpretation.

Compiler testsPositive, negative and boundary cases

Reusable machine-use case: discovery resolves a current contract, retrieval enforces the purpose, clause tests validate the snapshot, the governed adapter adds no hidden change, provenance reaches downstream context and notices reach registered consumers. Publish the core and issue receipts.

Decision-specific case: the customer domain product is stable, but one risk review requires a narrower population, stricter freshness and a purpose-specific entitlement. Publish the core with an adapter rather than burdening every consumer with those rules.

Schema-stable semantic break: customer status changes from legal entity to active product while remaining a string. The typed diff marks semantics, registered decision tests fail and the proposed version stays quarantined.

Additive breaking change: a nullable field enters a generic ranking loop and changes the interpretation of absence and zero. Structural validation succeeds; behaviour evidence does not. Quarantine until the consumer ignores, maps or deliberately adopts it.

Freshness failure: the API responds inside its latency objective while effective facts exceed the decision age limit. Repair temporal and service terms, expose the stale condition and test the fallback before reuse.

Entitlement mismatch: a consumer may discover the product but cannot retrieve a restricted attribute for the stated purpose. Repair the rights enforcement or remove the attribute from the adapter. Discoverability is not authority.

Cohort-quality failure: overall completeness passes while one decision-critical cohort lacks the required field. The hard gate fails. Repair collection, narrow the eligible population or choose another source.

Undeclared adapter: a private join and imputation feed a prompt outside product lineage. Repair provenance and register the transformation so incidents and corrections can reach downstream outputs.

Unknown consumer: an agent dependency appears only in prompt configuration. Quarantine a breaking release while access evidence identifies its owner, decision, version and migration route.

Exploratory boundary: a low-consequence analysis uses a versioned snapshot, permitted destination and visible caveat. A governed exploratory adapter is proportionate; a production availability commitment is unnecessary until use expands.

Unsupported product: the endpoint has no owner, correction path, dependency evidence or safe retirement plan. Continuing service preserves hidden risk. Reject new consumption and retire through a traced migration.

Evidence boundaryStandards are components, not certification

FAIR and DCAT support interoperable discovery and reuse. PROV-O supports provenance representation, and DQV supports descriptions of quality measurements and policies. JSON Schema and OpenAPI support structural and interface validation. Dataset documentation research supports explicit motivation, composition, collection, processing, use and maintenance for different audiences. None of these sources certifies the nine-clause product for a particular machine decision.

The Open Data Products Standards Family is a current Linux Foundation project. Its site identifies ODPS 4.1, released in October 2025, as the latest production specification and describes product metadata including access, quality, service, licence and related concepts. The Open Data Contract Standard site identifies ODCS 3.1.0, approved in December 2025, as its current version. Both are evolving implementation options. The Machine-Use Data Product Contract, governed adapter, behavioural diff, runtime receipt and Compiler are this article's synthesis.

ISO data-quality standards provide characteristics, terminology and management context; quality still depends on use. Production-ML research supports caution about undeclared consumers, configuration and changing dependencies. NIST sources support contextual governance, third-party risk, monitoring and accountability. EU AI Act obligations depend on the applicable system classification, role, provision and timing. A contract can organise evidence and controls, but it does not itself establish legal compliance.

Keep metadata, structural schema, semantic contract, service level, policy enforcement, decision fitness and legal compliance distinct. Link them so failures reach the right owner. A product is credible when its consumers can predict change, refuse unsupported use, trace runtime evidence and complete repair or retirement. The catalogue badge is only the beginning.