Computable Data Contracts for DPROD: ODRL as the Obligation Layer

1. The Problem: Obligations Without Computation

Data platforms already have a discovery layer (DCAT, schema registries) and a provenance layer (PROV-O). What they lack is an obligation layer: a machine-evaluable record of what publishers commit to and whether those commitments were met. In current industry practice, "data contracts" are usually YAML or JSON documents — commitments without normative evaluation semantics.

AI and automated data-product workloads make the absence of this layer expensive. A model trained on data advertised as "99.5% complete" degrades silently when completeness drops; a governance service cannot answer which contract governed this dataset at training time or was the quality commitment met by graph query, only by audit reconstruction. ODRL is structurally equipped for these questions, provided contracts are represented as evaluable policies rather than prose.

2. Why ODRL, and the Document-Centric Alternative

ODRL's relevant properties are well aligned with a data-platform obligation layer: a formal constraint model, RDF composability with DCAT, PROV-O, and DQV, and the profile mechanism as a governed extension path. We treat this as established for the workshop audience. The question is whether the model holds under production data-platform use, and how it compares with the standard being adopted by non-semantic teams.

The Open Data Contract Standard (ODCS) is the most visible non-semantic alternative: JSON/YAML contracts covering schema, quality rules, service levels, and ownership. It integrates well with operational tooling such as dbt and data catalogs, but it has three structural limits that motivate the ODRL approach. First, it does not specify evaluation semantics: quality rules are represented as JSON objects, but compliance cannot be determined from the standard alone. Second, ODCS documents are not RDF resources and cannot be joined with lineage graphs, vocabularies, or policy ontologies without a transformation layer. Third, without a formal profile mechanism, the standard has diverged into community v2 and ACRYL v3 variants with non-identical schemas. A data-platform governance stack built on ODCS inherits these limits; an ODRL profile can avoid them.

3. dprod-contracts: A Working Deployment

The dprod-contracts specification (EKGF/OMG track, v0.7) defines four classes (DataOffer, DataContract, State, RuntimeReference) and a compact property set, all minted in the shared dprod: namespace rather than a separate contracts namespace. A DataOffer is a publisher's standing commitment; a DataContract is formed when a consumer accepts that offer via dprod:acceptsOffer. Each duty carries an independent dprod:state (Pending → Active → Fulfilled | Violated), so a price-accuracy violation need not cascade to an availability duty on the same contract.

A firm-specific deployment layers a thin profile on top: three ODRL actions (deliver, maintain, notify), two additional dprod:State instances (Retired, Cancelled), and a termination notice property — six vocabulary terms with no modification to the base profile. The full corpus of offers, contracts, and quality constraints validates under a single pyshacl invocation against both the base shapes and the overlay.

Three design choices are worth naming for this audience.

Action vocabulary is profiled, not proposed as core ODRL. deliver, maintain, and notify are firm-specific vocabulary carried forward from the predecessor DCON ontology during the migration to dprod-contracts. They are minted in the profile and related to broader ODRL actions with odrl:includedIn (odrl:distribute, odrl:use, odrl:inform), giving generic ODRL processors a coarser standards-compatible view. The workshop question is not whether these actions belong in ODRL, but whether odrl:includedIn is the right mechanism for exposing domain action vocabularies to generic processors.

Commitment-only offers. The ODRL Information Model requires an Offer to contain at least one Permission. In data-platform practice, many publishers can commit to delivery and quality obligations but cannot grant access rights; those rights are governed by entitlement systems outside the contract layer. The dprod-contracts shapes therefore treat odrl:permission as optional on DataOffer and DataContract, while the overlay surfaces its absence as a SHACL Warning rather than a Violation. A commitment-only offer is explicit about its scope: an ODRL processor receiving it should infer that the offer itself grants no rights. The deviation from the normative Information Model is deliberate and documented as a profile override.

DQV bridge. Quality duties (action jpmv:maintain) use an odrl:Constraint whose odrl:leftOperand is linked to a dqv:Metric with dqv:isMeasurementOf. This gives the constraint evaluator a computable route from the obligation ("maintain ≥ 99.5% accuracy") to DQV's measurement vocabulary without introducing contract-specific measurement properties. Column-level scoping is expressed with dprod:partOf on the constraint target's dcat:Distribution and dprod:path for the field path, reusing the transitive asset hierarchy rather than odrl:AssetCollection, which the profile rejects.

4. Four Open Questions for the Working Group

dprod-contracts shows that ODRL is sufficient for expressing data-platform obligations at production scale. The remaining gaps are operational: primitives needed to evaluate, observe, and compose those obligations across systems.

1. State transition automation. ODRL has no state machine. dprod:State supplies the state vocabulary, but the transition from Active to Violated when a monitoring system observes a breach is outside the model. What is missing is a binding between ODRL policy evaluation and an observation protocol; PROV Activity is the natural candidate. Without such a binding, every deployment writes a bespoke transition agent and automation is non-portable across profiles.

2. Temporal operands. ODRL constraints are usually evaluated at a point in time, but data-platform service levels are often window-computed: availability over a rolling 30 days, P99 latency over the past hour, completeness over the current business day. RFC 5545 RRULE can govern when a duty recurs; it does not define the evaluation window for that duty's constraints. A minimal vocabulary for time-scoped operands — for example, an evaluation-window property on odrl:Constraint or odrl:LeftOperand — would close the gap between common data-platform SLAs and constraints that can be evaluated portably.

3. Fulfillment and provenance binding. No standard property links a PROV Activity — a delivery event, quality-measurement run, or notification event — to the ODRL Duty it fulfills. This binding is central to AI-ready governance: without it, a governance service cannot certify by query that "this model was trained on data whose contract was in force and whose quality duties were in Fulfilled state at training time." An ODRL-side property such as odrl:fulfilledBy, or a lightweight symmetric PROV extension, would make this a SPARQL question rather than an audit-trail reconstruction.

4. A standard evaluation protocol. ODRL has no standard evaluation interface: no common context-submission format, no common compliance-result structure, and no wire protocol. Each deployment invents its own evaluation service. A minimal request/response schema — context in, compliance determination plus violation report out — would let ODRL governance services compose across platform boundaries, which is precisely what AI pipelines operating over distributed data require.

5. Conclusion

The dprod-contracts profile, with a six-term firm-specific overlay, shows that ODRL's existing model is sufficient to express delivery, quality, and notification obligations against DCAT distributions, link those obligations to DQV metrics, and validate the resulting graph with open-source tooling. The remaining work is not vocabulary. State transition automation, temporal constraint evaluation, provenance-bound fulfillment, and a standard evaluation protocol sit at the intersection of ODRL, PROV-O, DQV, DCAT/DPROD, and platform engineering. We submit these as concrete questions for the working group, and encourage the ODRL, DCAT, PROV, and DPROD communities to treat this stack as shared infrastructure rather than adjacent efforts.