An Epsilon Value Alone Does Not Prove Differential Privacy

A product team wants to publish a weekly dashboard from conversations with an employee-support assistant. Names and message text are removed. An analyst adds random noise to each count and reports an epsilon value. The dashboard is called “differentially private.” Then three questions arrive: one employee generated hundreds of events, twelve earlier dashboards used the same records, and small departments can be isolated by combining filters. Nobody can show which person-level guarantee survives.

The output is noisy. That does not yet make the privacy claim true.

The practical decision is: may this output be released with a differential-privacy claim, must the query or guarantee be changed, should publication wait, or is the use incompatible with useful privacy? Epsilon is part of that decision, but it cannot answer it alone.

Differential privacy is a system claim

Differential privacy describes a property of a randomized mechanism. Informally, compare two neighboring datasets that differ in the protected contribution of one person. After the mechanism runs, the distributions of possible outputs should remain close enough that observing an output reveals only a bounded amount about whether that contribution was present.

Every noun carries an engineering choice: What counts as neighboring? Is the unit one event, account, household, or person across accounts? Which outputs cross the trusted boundary? Which mechanism runs? Which related releases and prior knowledge matter?

The March 2025 NIST SP 800-226 guidance therefore presents a guarantee as a pyramid: parameter and unit, correctness, utility and bias, query and trust models, access control, side channels, and collection exposure. A number at the top cannot repair a missing layer.

Our guide to privacy-enhancing technologies compares the wider toolkit. Here the task is narrower: turn one proposed release into an auditable decision.

What the verified sources establish

NIST says smaller epsilon usually means a stronger privacy bound and lower accuracy under otherwise comparable assumptions. It offers no context-free rule for choosing epsilon: sensitivity, purpose, population, threat, protected unit, and deployment all matter.

The UK Information Commissioner's Office says in its privacy-enhancing technologies guidance that a differentially private algorithm does not automatically produce anonymous information. Configuration, accumulated queries, retained data, purpose, fairness, and case-specific risk still matter. It distinguishes central privacy, where a trusted aggregator sees raw data, from local privacy, where participants randomize before sending.

The OpenDP programming framework represents input domains, dataset-distance metrics, deterministic transformations, randomized measurements, and maps that bound privacy loss. Adding noise after an unbounded or ill-defined transformation does not prove the composed program.

The U.S. Census Bureau's TopDown Algorithm brief shows a data-product system, not a last-minute filter: privacy loss is allocated across queries and geography, results are post-processed, and utility is evaluated. Its parameter decision record documents stakeholder feedback and accuracy tests. The published budget belongs to that census design, not every dataset.

Google's differential-privacy libraries provide mechanisms, pipelines, accounting, and auditing tools. Their lower-level building blocks assume contribution limits that callers must enforce. A reputable library reduces avoidable risk; it does not supply product policy.

Those are verified source positions. The release contract, architecture, receipt, and decision states below are ZharfAI's operational synthesis.

Start by naming the protected unit

Do not begin with epsilon. Begin with the privacy harm the release is meant to limit, then write the neighboring-dataset relation that represents it.

Suppose one employee uses the assistant from a browser, phone, and messaging integration. Event-level privacy may protect one event while leaving 499 others. Account-level privacy may protect each login while a stable identifier links all three. A user-day unit can compose into a much weaker yearly story.

NIST calls user-level protection a strong default. State both parts of the chosen relation:

1. Adjacency operation: add/remove one unit, or replace one unit's data.
2. Unit scope: one person across which identities, devices, sources, attributes, and time horizon.

A plain test is to write two situations an attacker wants to distinguish. “This employee never used the bereavement service” versus “this employee used it repeatedly” is not protected when only one page view can differ. If the situations are not neighbors, the guarantee does not directly cover that harm.

Bound contribution before adding noise

Noise is calibrated to sensitivity: how much the query can change when one protected unit changes. If one person can contribute an unlimited number of rows or an unlimited total value, sensitivity may also be unbounded. No finite amount of useful noise fixes that input contract.

Contribution bounding therefore belongs in the trusted computation before aggregation. For a weekly assistant dashboard, the policy might limit each protected user to a declared number of conversations, issue categories, or clipped score contribution during the protection horizon. The pipeline must group all identities belonging to the unit, apply the cap or subsampling deterministically or with a documented random process, and prevent duplicate ingestion from bypassing it.

Bounding changes meaning. If the system keeps five sampled sessions from a highly active user, the statistic estimates bounded participation, not every event. Record the rule and test its bias; do not call a clipped result exact.

Unstructured data is harder: a conversation may mention people other than its author. NIST notes that meaningful units for text, images, audio, and video can be difficult to define. If the team cannot map protection to the people present, it should narrow the claim or avoid release.

Draw the trust and release boundary

Central and local privacy solve different trust problems. In a central design, the curator receives raw data and protects outputs. Access control, encryption, retention, incident response, and a clean release boundary remain necessary; the guarantee does not protect data exposed inside a compromised curator.

In a local design, each participant randomizes before collection. This reduces trust in the aggregator but usually needs more noise for the same analytical goal. Local trades information and device complexity for a smaller central trust assumption; it is not automatically better.

List every recipient outside the boundary, including analysts, vendors, model providers, logs, and previews. A chart may be private while its exact pre-noise value appears in a trace. Side channels and related exact releases can disclose what the final table hides.

Access control limits who touches raw state; differential privacy limits what an approved release reveals. Neither substitutes for the other.

Make composition an atomic budget ledger

The same population is queried repeatedly. Dashboards refresh, analysts retry jobs, dimensions multiply, and models train for many steps. Composition rules bound accumulated loss. In the simplest pure-epsilon view, bounds add; other accountants may be tighter only when assumptions and parameters match.

Create one ledger at the protected-unit and dataset lineage boundary. A reservation should identify:

release_id + purpose + owner
protected unit + adjacency + horizon
dataset lineage and population
query or training configuration digest
mechanism + original privacy parameters
contribution and value bounds
budget requested + accountant/version
prior compatible releases considered
recipient boundary + expiry
utility result + approval + artifact digest

Reserve budget atomically before computation and commit it when information crosses the boundary. A timeout that showed a partial result may have spent privacy. Retrying until a random answer looks right is repeated release, not quality assurance.

One ledger must cover products that share people and lineage. An expired URL does not erase a release. Do not combine parameters from different privacy definitions without a valid conversion and the originals.

Choose parameters through a decision, not a magic table

There is no universal epsilon that converts any dataset into “safe” output. Under the same neighboring relation and mechanism, a lower epsilon constrains output distributions more tightly; across different units, horizons, delta values, query models, and trust boundaries, two epsilon values may describe materially different protections.

Parameter approval connects four questions:

• What inference about one protected unit is the organization trying to bound?
• What total loss is acceptable across the declared lifecycle, considering the data's sensitivity and recipients?
• What accuracy does the named decision require, including for small or affected groups?
• What alternative—coarser statistics, fewer releases, access-controlled analysis, secure computation, or no release—better serves the purpose?

For approximate differential privacy, report epsilon and delta together. Delta is not a percentage of people who “lose privacy.” Because conversions depend on the chosen delta, preserve the original parameters and accountant method.

Treat budget as scarce authority. If useful output requires an unacceptable guarantee, publish less detail or do not publish.

Test utility against the decision the data will drive

A private output that cannot support its intended use has no reason to be released. Design utility tests with public, synthetic, or governed validation data, then evaluate released results without repeatedly revealing exact sensitive answers.

Inspect intervals, partition-selection effects, bias, rank stability, threshold crossings, meaningful slices, and resulting decisions—not only average error. Clipping and non-negative post-processing can introduce systematic bias. Small groups may carry far larger relative error than a global total.

Predeclare acceptance tests. Ask whether a noisy count distinguishes a sustained capacity problem from ordinary variation, not whether every point matches. If users need to investigate one person or a rare incident, aggregate differential privacy is probably the wrong interface; ICO specifically notes this utility problem.

The Census example exposed trade-offs through demonstration products and measured accuracy across uses. Copy that decision discipline, not its parameter values.

Work one assistant dashboard through the gate

The team proposed weekly counts by department, issue, language, office, and channel. Some departments have four people, twelve exact previews already exist, and arbitrary filters are planned.

The privacy review changes the product:

1. It defines the protected unit as one employee across linked accounts for one declared annual horizon, not one message.
2. It limits each employee's contribution per reporting period and clips satisfaction values to a documented range before aggregation.
3. It uses an approved public list of broad issue categories and minimum population eligibility, rather than revealing that a new category exists because one person used it.
4. It replaces arbitrary filters with a fixed query registry and less frequent releases.
5. It places the raw store, identity linkage, and bounding stage inside a small trusted curator boundary. The public service receives only approved measurements.
6. It registers the twelve earlier previews. If their recipients were outside the chosen trusted boundary, their information must enter the risk assessment; relabeling them “tests” does not erase them.
7. It allocates lifecycle budget across the few decisions the dashboard supports and tests error and bias by department size and language. Rare-case investigation stays in a restricted workflow.

The result may be a quarterly organization-wide trend instead of a weekly department microscope. That is an honest match between the guarantee and a useful decision.

Build a release path with one unavoidable gate

A defensible architecture makes the unsafe shortcut difficult:

raw store + identity map
        ↓ restricted access
validated domain and lineage
        ↓
contribution/value bounding
        ↓
approved query registry or training plan
        ↓
vetted DP measurement
        ↔ atomic budget accountant
        ↓
utility, bias and attack-oriented tests
        ↓
release gateway + signed receipt
        ↓
public artifact or bounded recipient

The gateway rejects unregistered queries, incompatible budget, missing bounds, unsupported versions, failed utility, changed recipients, or absent receipts. Debug mode must not bypass noise. Exact intermediates stay out of general logs, and mechanism randomness and seeds stay protected.

Prefer tested end-to-end libraries over hand-built noise. Pin library and accountant versions, monitor known issues, and re-evaluate after numerical, dependency, or pipeline changes.

Empirical auditing can find counterexamples and bugs. As NIST cautions, finding none does not prove the guarantee. Tests supplement analysis, review, and controls.

Issue a release receipt, not a privacy badge

The receipt lets a reviewer understand the claim without reconstructing code. State the purpose, unit, adjacency, horizon, lineage, trust model, mechanism, original parameters, accountant, bounds, cumulative scope, utility, bias, related releases, recipients, approval, and expiry.

Use precise language: “This table used mechanism X, user-level add/remove adjacency, population Y, horizon Z, these parameters, and these prior releases.” Avoid “zero risk” or “the dataset is anonymous.” Differential privacy limits one defined inference channel; it does not legitimize excessive collection, insecure storage, or a harmful product.

Keep the receipt beside the release and in the audit-evidence trail. Apply the synthetic-data governance guide to derived products: “synthetic” is not itself a privacy proof.

Decide release, modify, defer, or reject

The table also applies to training. A model trained with a valid private algorithm can carry its guarantee into post-processed outputs under the relevant assumptions. A normally trained model with a noisy reporting layer cannot be relabeled private. Cross-organization analysis may instead need the secure-computation patterns in our privacy-preserving data collaboration guide.

Failure modes that look reassuring

• No neighboring relation: nobody can say whose participation is protected.
• Event sold as person privacy: correlated events reconstruct behavior.
• Unenforced bounds: inputs exceed the mechanism's sensitivity assumption.
• Separate product ledgers: several releases spend against the same people unseen.
• Preview until pleasant: repeated outputs are inspected and one is selected.
• Private partition leakage: a group's appearance reveals participation.
• Exact related totals: auxiliary releases narrow the protected possibilities.
• Epsilon shopping: delta, unit, horizon, mechanism, and threat are omitted.
• Average utility only: small groups receive decision-reversing error.
• Library as certification: a correct primitive sits in an incorrect pipeline.
• Synthetic as anonymous: no valid training or release guarantee exists.
• Raw traces: debugging discloses what the final mechanism protects.

In each failure, one attractive artifact stands in for the whole release system.

Measure the operation and know when to reopen it

Monitor both mechanism and decision:

• budget state by protected population and horizon;
• previews or releases missing a ledger entry;
• users and values affected by contribution bounds;
• error, interval coverage, bias, and decision reversals by slice;
• rejected sparse partitions or incompatible composition;
• raw access outside the curator boundary;
• accountant, library, and configuration versions;
• findings, withdrawal time, and changed assumptions.

Reopen approval when an assumption changes. A new dimension changes sensitivity; a new vendor changes the trust boundary; merged identities change the unit; an exact disclosure changes inference; a library fix may invalidate prior receipts.

The final question is not “What epsilon did we use?” Ask what is protected, across which releases and assumptions, and whether the output serves its decision. If the receipt answers and the gate enforces that, epsilon has meaning. Otherwise it is only a number attached to noise.

Source notes — reviewed 3 September 2026

• NIST, SP 800-226: final March 2025 guidance on the full guarantee, including unit, composition, utility, implementation, trust, and auditing limits.
• UK Information Commissioner's Office, Privacy-enhancing technologies: regulator guidance on central/local models, budgets, utility, accumulated queries, and anonymity claims.
• OpenDP, Programming Framework: current stable documentation for domains, transformations, measurements, maps, and composition.
• U.S. Census Bureau, How the TopDown Algorithm Works: March 2023 brief on allocation, post-processing, and data-product design.
• U.S. Census Bureau, 2020 Census parameter decision: June 9, 2021 record of parameters, feedback, accuracy, and trade-offs; not a reusable epsilon recommendation.
• Google, Differential Privacy libraries: current implementation documentation for mechanisms, pipelines, accounting, auditing, contribution bounds, and numerical limitations; not an officially supported Google product.