Query Rate and Overlap Limit¶
Query-access policy — instantiates Reconstruction-Resistant Disclosure Design
Caps the volume, overlap, and adaptivity of queries a recipient can make, so that no sequence of individually-safe requests can be composed into a reconstruction.
Some reconstructions need no single revealing output — only enough overlapping ones. Query Rate and Overlap Limit is the access-side policy that starves that strategy: it constrains how many queries a recipient may issue, how much successive queries may overlap in the records they touch, and how adaptively one answer may steer the next. Its defining move, distinct from the ledger that prices disclosure, is that it shapes the request stream itself — refusing the too-similar follow-up, spacing the repeat, blocking the narrowing sequence — before any risk is even spent. Where the budget says "you have this much to spend," this policy says "you may not spend it in that pattern."
Example¶
A company's people-analytics dashboard lets managers see team engagement scores, always as group averages over at least, say, five people. A manager who wants one report's private answer can still try to reach it by differencing: request the average for "my team" (six people), then for "my team excluding the new hire" (five people) — the gap would expose the new hire. Query Rate and Overlap Limit is what blocks this, by governing the pattern of requests rather than each request's group size. It refuses two queries whose populations overlap by all-but-one, caps how many re-sliced variants of the same group a manager may run per week, and flags an adaptively narrowing sequence for review. A vetted analytics team sits in a higher tier with looser limits under agreement; a line manager gets tight ones. The single dashboard thus serves both without letting the low-trust path narrow its way down to an individual.
How it works¶
- Measure overlap between successive queries. Track each recipient's history and compare the underlying record sets; refuse or coarsen requests whose overlap is high enough to isolate individuals.
- Rate-limit repeats and near-repeats. Cap similar queries over a time window, defeating the average-away and differencing patterns that single-query checks miss.
- Detect adaptivity. Interrupt sequences where each query is tuned by the last toward a target — with review, delay, or a pre-registered fixed query set.
- Set limits by recipient tier. Let trust and accountability, not one global rule, decide how much querying latitude each channel gets.
Tuning parameters¶
- Overlap ceiling — how similar two queries' populations may be before the second is blocked; tighter defeats differencing but frustrates legitimate re-slicing.
- Rate and window — how many (near-)repeats per period; lower starves averaging attacks but slows honest exploratory analysis.
- Adaptivity handling — whether adaptive sequences are merely logged, delayed, or forced onto pre-registered plans; stricter is safer and less flexible.
- Recipient tiering — how many trust tiers and how far their limits diverge; more tiers fit access to accountability but complicate governance.
- Enforcement identity — per session, per identity, or per organization; coarser identity units are easier to game by splitting requests across accounts.
When it helps, and when it misleads¶
Its strength is that it closes the composition and differencing routes that every per-output safeguard leaves open — the attacks that live in the relationship between queries, not in any one of them. Tiering lets a single interface safely serve publics of very different trust without collapsing to the most restrictive rule for everyone.
Its failure mode is that limits keyed to identity are only as strong as identity itself: an adversary who opens many accounts or colludes across recipients can reassemble the forbidden pattern. Set too tight, the limits throttle legitimate analysis and push users toward bulk extracts that are far more dangerous. And the classic misuse is security theater — visible rate limits that look protective but sit above the threshold where differencing actually works. The discipline is to derive the overlap and rate ceilings from the reconstruction they must prevent, and to pair them with identity assurance and cumulative accounting rather than trusting them alone.[n1]
How it implements the components¶
Query Rate and Overlap Limit fills the access-control side of the archetype — the components that govern the request stream and who may work it:
composition_and_query_control— it is the query-control half: shaping volume, overlap, and adaptivity so requests cannot compose into a reconstruction.recipient_tier_model— it sets limits per trust tier, so a public user and a vetted analyst draw different querying latitude from the same interface.
It does not price or total the risk each query spends — the accounting half of composition is Privacy Budget Accounting — nor does it transform any output it does allow (Noise or Randomization Release, Small-Cell Suppression Rule).
Related¶
- Instantiates: Reconstruction-Resistant Disclosure Design — provides the access-pattern controls that stop safe queries from composing into unsafe reconstructions.
- Consumes: Privacy Budget Accounting — these limits enforce the budget that ledger accounts; the two are the enforce/account pair.
- Sibling mechanisms: Privacy Budget Accounting · Noise or Randomization Release · Small-Cell Suppression Rule · Post-Release Reconstruction Monitor · Synthetic or Perturbed Data Validation · Differencing Attack Scan
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Query Rate and Overlap Limit operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it caps the volume, overlap, and adaptivity of queries a recipient can make, so that no sequence of individually-safe requests can be composed into a reconstruction.
Independent corroboration: The frozen evidence defines Query Rate and Overlap Limit as 'Caps the volume, overlap, and adaptivity of queries a recipient can make, so that no sequence of individually-safe requests can be composed into a reconstruction', so its operative form is Control, Automation & Runtime.
Nearest alternative: Rule, Policy & Commitment — Query Rate and Overlap Limit includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Restricting adaptive overlapping queries to resist differencing and reconstruction is rooted in database privacy and computer security.
Related originating lineages:
- Statistics & Experimental Design — Statistical disclosure limitation materially shapes overlap and cumulative inference risk.
- Ethics of Technology & AI Governance — Contemporary data-governance practice supplies recipient and disclosure constraints.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
These limits are only as strong as the identity they are keyed to. If a recipient can open many accounts or collude with others, the forbidden query pattern can be split across identities and reassembled — so rate and overlap limits presume real identity assurance behind them, and pair naturally with a differencing scan that checks whether the space of allowed patterns still hides a route to one record.
[n1] A differencing situation arises when two aggregate results are published over populations that differ by a single individual: comparing them can expose that individual, even though each aggregate met its minimum-group-size rule. Limiting the overlap and repetition of queries is a standard defense, which is why this policy governs request patterns rather than single requests. ↩