Define a report’s privacy unit before counting rows

Ask what change the stated guarantee covers

A fictional AI reporting team receives a proposal labeled differentially private. Its review request says “protect each contributor,” while the accompanying inventory counts rows. A contributor can appear more than once. The missing contract is what contribution the claim actually covers.

This worksheet reviews one proposed aggregate-report mechanism claim over one fixed, independently admitted data scope. It selects no algorithm, noise distribution, library or privacy parameter. It creates no dataset and calculates no privacy loss. The useful output is a complete scope record for independent review, not a published statistic or a privacy certificate.

The request-data guide still controls permitted inputs and recipients. The representation-disclosure guide still controls a different export question. Neither supplies the neighboring-data definition needed here.

Bind the unit to an explicit neighboring-data relation

NIST SP 800-226, March 2025, ties the unit of privacy to the definition of neighboring datasets. It distinguishes event/row-level from user-level protection. Its unbounded relation adds or removes one person’s data; bounded replacement is different. A person contributing multiple events can exceed a one-event change.

For the original paper example below, explicitly select an add/remove relation. The entity is a person within the declared report scope. Do not substitute a replacement rule, a row identifier, an account label or a calendar window without reviewing the resulting definition.

The relation belongs in the reviewed claim, alongside the intended protected entity and actual mechanism assumptions. An attractive parameter value cannot identify those missing fields. We derive no group-privacy conversion and make no claim that a row-level mechanism provides zero protection for a person; the narrower point is that the advertised whole-contribution scope is not established automatically.

Walk a small contribution ledger on paper

Removing one P-A row changes one row. Removing P-A’s complete contribution changes three. Those are different paper changes, even though both descriptions mention P-A. A worksheet documenting only the first change has not documented the second as its chosen neighbor relation.

The counts are invented bookkeeping, not observed users, generated records, a dataset or a recommended contribution cap. No actual protected values exist for this exercise, and no mechanism was run on either hypothetical input.

Renaming row identifiers or replacing a displayed name does not fill the missing contribution definition. Require a trusted association explaining which contributions belong together. That evidence need not expose identities in an ordinary report or justify collecting new personal attributes.

Treat a contribution bound as part of the mechanism contract

The publication’s contribution discussion explains that bounding a user’s events changes sensitivity and the required noise. A cap cannot be detached from the applicable mechanism analysis.

Our original admission policy therefore records the complete grouping rule, declared bound, covered scope and treatment of excess contributions together. Their actual values are unknown here. Do not choose a cap from the toy ledger, silently discard excess rows, or attach an unchanged assurance label after modifying preprocessing.

If the contribution inventory is incomplete, mark it unresolved. If a change exceeds the admitted scope, hold the proposal rather than claim the old review still applies. This worksheet provides no grouping implementation, clipping procedure, sensitivity proof or parameter-selection recipe.

Also retain the original mechanism and accounting description. Two records carrying the same parameter label but different units or assumptions are not interchangeable review packets. The team must obtain an applicable independent assessment rather than calculate an unsupported equivalence here.

Keep an original privacy-unit admission sheet

The useful positive conditionally admits only a complete person-unit review profile when every field is independently established. The reviewer can then evaluate that actual scoped claim. No private report, empirical privacy result or authorization to disclose data is supplied by this paper exercise.

Actual contribution mapping, bound enforcement, mechanism, accounting, implementation, full release workflow and current rights are unimplemented or unknown. Any missing prerequisite blocks a real positive. A manager’s “DP enabled” checkbox cannot replace this evidence.

Walk eight inert scope decisions

Limit the assurance and preserve other controls

NIST’s deployment discussion keeps raw-data security and access control separate. A scoped statistical claim does not secure every collected or retained copy. Existing copy-lifecycle obligations therefore remain independently relevant.

No data, rows, grouping, clipping, noise, privacy parameters, accountant, model, query, attack, plot, runtime fixture or API operation was constructed or executed. Ordinary editorial file handling is separate. This guide offers no anonymity, legal classification, compliance determination or protection against every disclosure.

Boundary remains prelaunch with planned request-path checks, not a shipped differential-privacy engine or assessor. Its existing synthetic policy evidence concerns different behavior.