Differential-privacy budgets belong in data-product contracts

Differential-privacy budgets belong in data-product contracts. If a product claims to release useful aggregates while limiting what any output reveals about an individual, epsilon and delta cannot remain parameters hidden inside a notebook. They must be part of the interface negotiated between the producer, the consumers, and the platform that composes repeated use.

The contract begins with adjacency: what does it mean for the underlying dataset to differ by one protected unit? One row, one person, one household, and one organization imply different promises. Sensitivity and noise are downstream of that choice. A technically correct Gaussian mechanism does not rescue a product whose protected population was never defined. The contract must name the unit, eligible population, purpose, dataset version, and transformations covered by the guarantee.

It must also name the accounting boundary. Sequential queries accumulate privacy loss; queries over genuinely disjoint partitions can compose differently. Rényi DP, zCDP, moments accounting, and PRV accounting offer ways to calculate that accumulation, but the operational question remains: which releases share a ledger? If two teams consume the same underlying population through separate endpoints, separate dashboards do not create separate privacy realities. The contract needs a stable budget identity that follows the data across products and derived outputs.

This turns a mathematical promise into lifecycle governance. A versioned contract should declare the maximum privacy envelope, accounting method, reset or expiry policy, supported query classes, minimum cohort rules, and what happens when the budget is unavailable. The runtime must meter and stop the spend; the data-product contract tells it what resource exists and who may allocate it.

Utility belongs in the same agreement. Lower epsilon generally buys stronger privacy by adding more noise, and high sensitivity makes the trade harsher. A producer should publish the error characteristics, suppressed slices, and intended decision boundary rather than present a noisy number as ordinary truth. Consumers can then test whether the product remains fit for forecasting, allocation, or exploration. Data quality is already a distribution contract; differential privacy adds an intentional distribution shift whose acceptable effect must be stated.

Lineage closes the loop. Every released aggregate should point to the contract version, mechanism, accountant, source snapshot, and privacy spend that authorized it. Derived products inherit those obligations. Resetting a counter while retaining outputs does not restore privacy, so retention and deletion rules must cover cached extracts and downstream copies. This is why data rights belong in lineage, not in detached legal prose.

Contract changes need migration rules too. Increasing epsilon, redefining adjacency, or changing the accountant alters the promise even when the schema stays fixed. Consumers should receive a compatibility notice, existing releases should retain their original contract identity, and the producer should explain whether historical and new outputs can be combined safely.

There is one precise concession: a single research release over a frozen dataset can document its differential-privacy parameters in a release record rather than operate a full product contract. The stronger machinery becomes necessary when the data is refreshed, queries recur, consumers multiply, or outputs feed automated decisions. Most enterprise data products live in that recurring regime.

Data contracts are the API layer of a data platform. A privacy budget changes what the API may reveal over time, so it is not implementation trivia. I want the protected unit, composition scope, privacy envelope, utility floor, lineage, and exhaustion behaviour reviewed together. Only then does an epsilon value become a durable product promise rather than a mathematically impressive footnote.