Privacy Aggregation Floor
Attach qualified cohort-floor and statistical disclosure assurance to a host aggregate or release candidate.
Bundle → Layer → Finding → Questions Filled
6 bundles · 12 layers · 12 findings · 48 questions
Binding and authority Which host, purpose and audience the assurance concerns.
Attachment identity
Context for attachment identity within the host attachment.
Attachment identity
Design rule: pin the host revision and attachment separately from cohort, source and release identifiers. An assertion about one release is not transferable to another.
- Which host revision and attachment identifier does this assurance describe? identity
- Which candidate release, cohort definition and source revisions are linked? relationship
- When was this attachment effective and when was its evidence observed? temporal
- What changed when the host or cohort definition was superseded? lifecycle
Purpose and audience
Context for purpose and audience within the host attachment.
Purpose and audience
Design rule: evaluate only within the host-authorized processing context. Assurance is evidence for the release authority and never an access grant.
- Which authority permits computation for the stated purpose and audience? authority
- Which role maintains the floor profile and which role approves release assurance? ownership
- What protected details may each reviewer or recipient inspect? access
- How is an unsupported purpose or exception request handled? exception
Cohort and floor Define what is counted and why a particular floor applies.
Population and counting unit
Context for population and counting unit within the host attachment.
Population and counting unit
Design rule: distinguish records from protected contributors and bind the selection semantics before evaluating any floor. Do not persist membership lists in this mixin.
- What population unit and membership predicate define this cohort? definition
- How are repeated records, weights and multiple contributions treated in the support count? measurement
- Which geographic, temporal and categorical intersections define the evaluated cells? spatial
- Which related cohorts or external information can narrow the protected group? privacy
Applicable floor profile
Context for applicable floor profile within the host attachment.
Applicable floor profile
A count floor is a selected release constraint, not proof of k-anonymity or legal anonymity. Design rule: no default numeric floor; unknown profile or untrusted support yields unresolved assurance.
- Which floor rule and comparison apply to this cell and release context? constraint
- What evidence and approval justify this floor and its next review? authority
- Does trustworthy support satisfy the bound under the pinned rule? validation
- Is a k-anonymity claim being made beyond the cohort count constraint? classification
Computation and disclosure control Bind aggregate lineage and controls to the candidate output.
Aggregate lineage
Context for aggregate lineage within the host attachment.
Aggregate lineage
Design rule: keep source, method, internal exact result and proposed outward value distinct. Computation evidence does not itself authorize disclosure.
- Which statistic, denominator and unit does this output represent? measurement
- Which source revision, approved method and execution produced the aggregate? provenance
- Is the candidate value exact, suppressed, rounded, perturbed or otherwise unavailable? state
- Which raw counts, parameters or intermediate results require restricted storage? security
Suppression and perturbation
Context for suppression and perturbation within the host attachment.
Suppression and perturbation
Disclosure controls must be assessed over connected outputs. Design rule: review totals, denominators and secondary suppression; generic perturbation is not labelled DP.
- Which suppression, coarsening, rounding or perturbation transformations were applied? process
- Can totals, margins, percentages or companion tables reconstruct a suppressed value? validation
- Can the presence or absence of a cell disclose a private threshold decision? privacy
- What consistency and utility limitations do the transformed results carry? quality
Optional formal privacy assurance Record a qualified DP claim and the accounting evidence on which it depends.
Differential privacy claim
Context for differential privacy claim within the host attachment.
Differential privacy claim
Noise is insufficient evidence of DP. Design rule: mark this section not-applicable with rationale when no DP claim exists; otherwise require a reviewed guarantee covering the whole observable mechanism.
- Which privacy definition, adjacency and protected unit does the DP claim use? definition
- Which parameters, contribution bounds and sensitivity support the mechanism? constraint
- What review establishes the implemented mechanism matches the stated guarantee? evidence
- Does the guarantee cover selection, tuning, diagnostics and all outward observations? security
Cumulative privacy accounting
Context for cumulative privacy accounting within the host attachment.
Cumulative privacy accounting
Design rule: composition follows the protected unit and declared mechanism across overlapping releases. A date change, retraction or new dataset label does not restore spent privacy loss.
- Which previous and planned releases share the protected units or source lineage? composition
- What cumulative bound and authorized limit does the accountant report? measurement
- How are concurrent evaluations, retries and uncertain disclosures reconciled? event
- What evidence prevents withdrawal or a new reporting period from resetting privacy accounting? retention
Release-set review Combine risk, utility and evidence before returning a qualified assurance result.
Joint disclosure risk
Context for joint disclosure risk within the host attachment.
Joint disclosure risk
Design rule: evaluate the whole requested release set against known previous outputs and plausible auxiliary information. Individually passing cells do not imply a safe combination.
- Which singling-out, linkage and inference scenarios are relevant to the intended audience? privacy
- Which earlier tables, revised periods and alternate projections were considered together? relationship
- What evidence addresses differencing, dominance and homogeneous sensitive attributes? validation
- What new information or change makes the disclosure assessment stale? temporal
Utility and population impact
Context for utility and population impact within the host attachment.
Utility and population impact
Privacy controls alter the usefulness of statistics. Design rule: review fitness for the stated task and harm to poorly represented groups without treating utility as authority to waive protection.
- What error, bias and missing-cell effects matter for this intended analysis? quality
- How does protection affect small or rarely represented groups? measurement
- Which utility criteria were accepted and which uses remain unsupported? decision
- How are suppression, uncertainty and method revisions conveyed without exposing protected data? interoperability
Assurance outcome and continuity Record an evidence-bound outcome and maintain it across host release changes.
Assurance decision
Context for assurance decision within the host attachment.
Assurance decision
Design rule: bind a decision to the exact candidate digest, profile, audience and ledger revision. Passing assurance is necessary only within the adopting profile and never a publication command.
- What assurance outcome follows from all applicable floor, control, risk and utility checks? decision
- Who approved the evidence-bound outcome and under which delegated authority? authority
- Which candidate, audience and accounting revision must still match at the release handoff? constraint
- What does the host receive when a required check fails or remains unresolved? exception
Revision and retirement
Context for revision and retirement within the host attachment.
Revision and retirement
Design rule: keep the mixin assurance lifecycle separate from host publication. Retraction cannot undo a disclosure and evidence retention is scoped by lawful policy, not unlimited history.
- What authorized host receipt confirms what was actually disclosed and when? event
- Which change invalidates or supersedes this assurance revision? lifecycle
- Which evidence and sensitive intermediates must be retained, restricted or disposed of? retention
- How can another system resolve revisions and interpret a withdrawn or corrected release? interoperability
Classifiers Filled
- Family
- World Models
- Category
- Cross-cutting context
- Entry kind
- mixin
- Navigation path
- NAV.XCT.PRV
- Domain
- XCT.PRV
- Industry
- Cross-industry
- Tags
- privacyaggregationfloorxct.prv
- Also called
- S5
What it is Filled
A reusable host-attached capability for defining the protected population unit, applicable aggregation floor, protection evidence and release-assurance result. It owns subject-specific floor evaluation and privacy aggregation assurance. Host dataset, series, access policy, enforcement and audit systems retain their own identities and operations. All local functions below are proposed contracts, not implemented software.
In scope
- Host and cohort bindings, protected counting units, versioned floor profiles and aggregate lineage
- Suppression and perturbation evidence, optional differential privacy claims and cumulative accounting references
- Joint release review, purpose-specific utility, assurance expiration, revision and restricted evidence projections
Out of scope
- Person registers, source microdata custody, general statistical product or series lifecycle
- General ownership, legal basis, consent, access grants, projection enforcement and audit-log execution
- A universal safe k value, legal anonymity certification, production DP implementation or proof of standards conformance
- Publishing or transmitting source data or aggregates; actual release and disposition execution belong to authorized host systems
Why it exists Filled
Attach qualified cohort-floor and statistical disclosure assurance to a host aggregate or release candidate.
Distinguishing features Derived, awaiting review
- Unlike WM-XCT-003 Projection / Disclosure Policy: The incoming registry REFERENCE leaves threshold calculation and privacy aggregation assurance here. Projection policy selects the audience and representation; this mixin supplies qualified assurance evidence and cannot grant access or execute that policy.
- Unlike WM-XCT-001 Ownership / Stewardship and WM-XCT-002 Access Contract / Consent: Reference effective-dated authority and permitted purpose. Neither attaching a floor nor passing it creates ownership, consent or a lawful processing basis.
- Unlike WM-XCT-004 Access Audit: Local assurance records link audit receipts. Audit-trail storage, tamper controls and general access-event semantics stay with the audit system.
- Unlike Host dataset, aggregate and statistical series: The mixin has an attachment identifier and revisions but no independent population or series master. Authorized internal computation can examine small counts; the outward observable result must follow the selected profile and assurance gate.
- Unlike Legacy S5 specification and unreviewed supplement: Retain cohort, floor, computation and review leads. Reject claims that a count floor proves k-anonymity, every noise addition has a DP budget, budgets reset each period, or no internal measure may exist below a floor. No source data ownership transfer or agent publication authority follows from this model.
Note: Derived from boundary notes against neighbouring models.
What robots and AI may and may not do Derived, awaiting review
Must not
- Passing a floor cannot establish k-anonymity, DP, legal anonymity or release authority.
- Retain only lawful minimal tombstones and accounting continuity; deletion or withdrawal never refunds disclosed privacy loss.
- Deny access to unpublished assurance evidence unless a current purpose and role binding permits it.
- Exceptions require an external authority reference, explicit scope, reason and expiry; they cannot silently weaken a claimed mathematical guarantee or create publication permission.
May
- Bind an assurance attachment: Proposed local operation, not implemented: Bind host, cohort, purpose and evidence revisions without altering the host.
- Evaluate the applicable floor: Proposed local operation, not implemented: Calculate threshold satisfaction from trusted count evidence and the selected rule.
- Assess disclosure control evidence: Proposed local operation, not implemented: Check completeness and consistency of transformation and joint-output evidence.
- Assess formal privacy accounting: Proposed local operation, not implemented: Compare an authenticated accountant receipt to the declared DP claim and release set.
- Record release assurance: Proposed local operation, not implemented: Combine the required checks under the pinned profile and reviewer authority.
- Supersede assurance evidence: Proposed local operation, not implemented: Invalidate stale assurance and link host release or disposition receipts.
Note: Derived from functions, policies, CRUD and access rules; prohibitions were not authored for agents as such.
Moral aspects Derived, awaiting review
- Bind review to candidate, method and evidence digests and external receipts; a digest establishes byte integrity, not privacy, authority or truth.
- Retain only lawful minimal tombstones and accounting continuity; deletion or withdrawal never refunds disclosed privacy loss.
- Privacy method reviewer
- Review suppression, joint disclosure risks and any formal privacy guarantee.
- Source-grounded proposed host-attached mixin for aggregation-floor evaluation and privacy assurance.
- formal privacy
- No universal legal anonymity decision, jurisdictional authorization, threshold or privacy parameter is supplied.
- Adversarial scenarios are design checks, not executed privacy attacks or measured leakage results.
Note: Sentences mentioning harm, privacy, consent or similar, collected from the specification.
Owners Filled
Steward
Name the adopting Dimension, accountable statistics steward and authoritative host namespace.
Roles
- Statistics steward
- Maintain floor profile and approved purpose within delegated authority.
- Protected computation custodian
- Supply controlled count, method and source-revision evidence through approved interfaces.
- Privacy method reviewer
- Review suppression, joint disclosure risks and any formal privacy guarantee.
- Release assurance reviewer
- Bind the assurance outcome to the exact candidate and audience; refer actual release to the authorized host.
- Evidence custodian
- Maintain restricted revisions, audit links and lawful disposal receipts.
- Statistical consumer
- Use only released projections with their limitations; do not interpret suppression as zero.
Links to other meta-models Filled
references
- WM-XCT-001 - Proposed binding: Reference the source steward and authority context; this mixin neither transfers ownership nor operates a stewardship registry.
- WM-XCT-002 - Proposed binding: Reference permitted processing and recipient access; a floor check cannot create consent or execute access contracts.
- WM-XCT-003 - Proposed binding: Reference the selected audience and outward projection. The incoming ledger edge is preserved: threshold calculation and privacy aggregation assurance stay here, while projection policy and enforcement remain external.
- WM-XCT-004 - Proposed binding: Reference audit receipts for assurance operations; do not duplicate audit-trail execution or storage semantics.
- Host dataset and statistical series - Proposed binding: Resolve source, measure, release and correction identities in host masters. Attachment lifecycle concerns only privacy assurance.
aligned
- PROV-O - Conceptual derivation, attribution and revision links only; executable RDF mapping and conformance are deferred.
- RFC 3339 - Evidence timestamps use section 5.6 syntax; reporting periods and accounting scope are separately modelled.
neighbor
- WM-XCT-003 Projection / Disclosure Policy - The incoming registry REFERENCE leaves threshold calculation and privacy aggregation assurance here. Projection policy selects the audience and representation; this mixin supplies qualified assurance evidence and cannot grant access or execute that policy.
- WM-XCT-001 Ownership / Stewardship and WM-XCT-002 Access Contract / Consent - Reference effective-dated authority and permitted purpose. Neither attaching a floor nor passing it creates ownership, consent or a lawful processing basis.
- WM-XCT-004 Access Audit - Local assurance records link audit receipts. Audit-trail storage, tamper controls and general access-event semantics stay with the audit system.
- Host dataset, aggregate and statistical series - The mixin has an attachment identifier and revisions but no independent population or series master. Authorized internal computation can examine small counts; the outward observable result must follow the selected profile and assurance gate.
- Legacy S5 specification and unreviewed supplement - Retain cohort, floor, computation and review leads. Reject claims that a count floor proves k-anonymity, every noise addition has a DP budget, budgets reset each period, or no internal measure may exist below a floor. No source data ownership transfer or agent publication authority follows from this model.
What else AI and robots need to interact with it Incomplete
Identity and identifiers required Filled
- Authoritative master-system identifier with a separate immutable revision
- Governed global identifier or IRI
- Dimension-assigned UUID or ULID
Direct properties not applicable Not applicable
Not applicable
Institutional or informational subject: no invented physical properties.
Recognition optional Missing, in the backlog
Not described yet. This gap is in the card backlog.
Capabilities and actions required Filled
- Bind an assurance attachment: Proposed local operation, not implemented: Bind host, cohort, purpose and evidence revisions without altering the host.
- Evaluate the applicable floor: Proposed local operation, not implemented: Calculate threshold satisfaction from trusted count evidence and the selected rule.
- Assess disclosure control evidence: Proposed local operation, not implemented: Check completeness and consistency of transformation and joint-output evidence.
- Assess formal privacy accounting: Proposed local operation, not implemented: Compare an authenticated accountant receipt to the declared DP claim and release set.
- Record release assurance: Proposed local operation, not implemented: Combine the required checks under the pinned profile and reviewer authority.
- Supersede assurance evidence: Proposed local operation, not implemented: Invalidate stale assurance and link host release or disposition receipts.
Hazards and failure modes optional Missing, in the backlog
Not described yet. This gap is in the card backlog.
Standards and interfaces required Derived, awaiting review
- PROV-O: The PROV Ontology
Context of use required Filled
- NIST guidance and UK regulator/statistical examples ground concepts without imposing one jurisdiction on every adopter.
- The ICO source says it is under review; qualified current-law and sector review remains required.
Sources Filled
- De-Identifying Government Datasets: Techniques and Governance - National Institute of Standards and Technology
- Guidelines for Evaluating Differential Privacy Guarantees - National Institute of Standards and Technology
- How do we ensure anonymisation is effective? - Information Commissioner's Office
- Protecting personal data in Census 2021 results - Office for National Statistics
- Comparison of post-tabular statistical disclosure control methods - Office for National Statistics
- PROV-O: The PROV Ontology - World Wide Web Consortium
- Date and Time on the Internet: Timestamps - Internet Engineering Task Force
Open questions
- Restore independent external review before any canonical or publishable-draft promotion.
- Verify direct source access, current versions, selected claim support, licensing and jurisdictional applicability outside the sandbox.
- Develop profile schemas and fixtures for repeated records, equality at the floor, suppressed margins, homogeneous groups, threshold side channels, overlapping periods, concurrent reservations, unknown disclosures and stale approvals.
- Pin and test external accountant, access, release, audit and retention interfaces; assess SDMX and PROV-O exchange mappings without implying conformance from conceptual alignment.
- No executable instance schemas, floor engine, DP accountant, mechanism proof, concurrency adapter or conformance fixtures are supplied.
- No universal legal anonymity decision, jurisdictional authorization, threshold or privacy parameter is supplied.
- SDMX exchange binding from the legacy lead is deferred; no version or conformance claim is admitted.
- Adversarial scenarios are design checks, not executed privacy attacks or measured leakage results.
Machine files
Provenance
world-models research · reviewable-draft
Built from: models/wm-xct-005-privacy-aggregation-floor/spec.yaml