Privacy Budget Accounting¶
Privacy-loss accounting register — instantiates Reconstruction-Resistant Disclosure Design
Keeps a running ledger of how much reconstruction risk every query, view, and version has already spent against an explicit budget, and refuses releases once the budget would be overdrawn.
A single release can be safe while a hundred of them are not. Privacy Budget Accounting is the ledger that makes that cumulative truth visible and enforceable: it assigns every query, table, dashboard view, and re-release a cost in reconstruction risk, sums those costs as they compose, and measures the running total against a pre-set budget — a ceiling on how much an observer is ever allowed to learn about the protected inputs. Its defining move, distinct from any single transformation, is treating disclosure as a depletable resource: the fifth overlapping query is refused not because it is unsafe alone but because the account is already spent. Where a transformation decides how an output is made safe, this budget decides how much protection is owed and tracks whether the total keeps its promise.
Example¶
An advertising platform lets thousands of marketers query how many people saw an ad and later converted — always as aggregate counts, never individuals. Any one report is harmless, but a marketer who slices the same audience a dozen ways can triangulate toward single users. Privacy Budget Accounting governs the whole interface: each report is priced in privacy loss, every advertiser and every audience carries a budget, and the running tally is checked before each answer. A marketer who has already spent an audience's budget on ten narrow queries gets the eleventh refused, or served only at coarser resolution. The platform sets one number — the total privacy loss any audience may ever incur — and the ledger guarantees that number is honored no matter how the queries are sliced, combined, or repeated across releases and versions. Aggregate measurement APIs of this kind are built on exactly this budgeted accounting.
How it works¶
- Price every disclosure. Assign each release a risk cost in a common unit (e.g., an epsilon increment), so heterogeneous outputs — a table here, a query there, a new version next month — become summable.
- Compose, don't just list. Cumulative risk from overlapping or sequential disclosures is combined with composition rules, because risks that share subjects add up faster than they appear to.
- Check before answering. Compare the running total to the budget; refuse, defer, or down-resolve any release that would overdraw.
- Scope to the unit that matters. Track budgets per individual, per subpopulation, per recipient, or per time window — a single global number can hide a subgroup being drained.
Tuning parameters¶
- Total budget size — the ceiling itself: smaller means stronger lifetime protection and fewer answers; larger buys utility at rising cumulative risk.
- Accounting scope — per person, per cohort, per recipient, per epoch; finer scoping stops a hotspot from being drained but multiplies bookkeeping.
- Composition rule — simple summation versus tighter advanced composition; the tighter rule permits more queries for the same real risk but is harder to reason about.
- Refresh policy — whether the budget ever resets (a new epoch of fresh data) and how fast; replenishment restores utility but reopens cumulative exposure when data overlaps.
- Overdraw behavior — hard refuse, degrade-to-coarser, or queue-for-review when the budget is hit.
When it helps, and when it misleads¶
Its strength is that it defeats the salami route — reconstruction assembled from many individually-innocuous releases — which no single-output check can see. By making risk a tracked balance, it lets an organization make a firm, auditable promise about the worst an observer can ever learn, across the entire stream of disclosures rather than one at a time.
Its failure mode is that the accounting is only as sound as its cost model and its composition rule: misprice a query type or ignore a channel and the ledger balances while the real risk overruns. Budgets scoped too coarsely let a targeted subgroup be depleted under a comfortable global total. And it invites the run-backwards misuse of quietly enlarging the budget whenever it starts refusing useful queries — spending the promise to keep the dashboards full. The discipline is to fix the budget from the protection requirement before demand is known, and to treat an exhausted budget as a real stop rather than a paperwork obstacle.[1]
How it implements the components¶
Privacy Budget Accounting fills the budget-and-composition side of the archetype — the components that quantify how much is owed and track it across the whole disclosure stream:
reconstruction_risk_budget— it owns and operationalizes the budget: the explicit ceiling on cumulative inference risk, expressed in a trackable unit and enforced release by release.composition_and_query_control— it sums risk as queries, views, and versions compose and gates further release on the running total: the accounting half of query control.
It does not itself transform outputs (Noise or Randomization Release, Small-Cell Suppression Rule), and the *enforcement half of query control — rate and overlap limits on the request stream — is Query Rate and Overlap Limit. This ledger prices and totals; that gate throttles.*
Related¶
- Instantiates: Reconstruction-Resistant Disclosure Design — provides the cumulative-risk ledger that enforces a lifetime protection ceiling across all releases.
- Sibling mechanisms: Query Rate and Overlap Limit · Noise or Randomization Release · Small-Cell Suppression Rule · Post-Release Reconstruction Monitor · Synthetic or Perturbed Data Validation · Coarsening and Generalization Policy
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The mechanism composes cumulative disclosure risk and automatically refuses, defers, or coarsens a release that would overdraw the budget.
Nearest alternative: Record, Log & Register — The running ledger preserves history, but the state-dependent pre-release enforcement is the operative mechanism.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Privacy Budget Accounting is most plausibly rooted in the computer_science tradition because its characteristic form depends on algorithms, data structures, formal interfaces, and software-system practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Related originating lineages:
- Statistics & Experimental Design — The statistics_experimental_design tradition materially shaped Privacy Budget Accounting through its own practice of probability, calibrated inference, experimental design, and uncertainty analysis.
- Ethics of Technology & AI Governance — The tech_ethics_ai_governance tradition materially shaped Privacy Budget Accounting through its own practice of technology-specific privacy, accountability, and misuse governance.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
A budget is only as trustworthy as the price it puts on each release. If per-query risk costs are guessed rather than derived, the ledger can balance perfectly while real reconstruction risk overruns — the accounting inherits every error in the cost model. The ledger also only records and refuses; holding the request stream within the accounted limits is the job of Query Rate and Overlap Limit.
References¶
[1] Dwork, C., & Roth, A. The Algorithmic Foundations of Differential Privacy. Foundations and Trends in Theoretical Computer Science 9(3–4), 211–407 (2014). Shows how target cumulative-privacy parameters determine per-mechanism privacy allowances under composition. registry ↩