Testing whether counts and summaries respect hidden-record visibility

Goal

Check whether derived responses follow the product’s visibility rules for protected records. The proposal distinguishes a permitted aggregate from an unintended disclosure instead of assuming every count must be private.

Prerequisites

Create an isolated synthetic dataset with public and restricted records. Define which counts, facets, badges, summaries, and existence signals each test principal is permitted to observe.

Steps

1. Collect the declared aggregate through an authorized account and confirm the fixture’s composition. Use deterministic synthetic categories so changes can be attributed to a known record.

2. Query the same feature as a less-privileged account. Compare its output with the policy-defined visible dataset, not with the unrestricted account’s response by default.

3. Add one restricted synthetic record while keeping public records unchanged. Repeat the lower-privilege query and evaluate whether any changed count or category is allowed by the aggregate policy.

4. Repeat for alternate presentations actually supported by the application, such as a search facet or navigation badge. Name each presentation so a fix in one handler does not conceal another result.

5. After repair, check that authorized aggregates remain correct and that public record changes still update permitted summaries. Avoid a blanket constant response that merely hides a functional regression.

Expected result

The regression should identify which derived value changes with protected data and whether that change violates an explicitly stated disclosure policy.

Limits and test basis

This is a deterministic application-level comparison, not a statistical privacy guarantee. Timing, approximate aggregates, and intentionally public totals require different expectations and additional evaluation. This is an original proposed method; no execution or empirical result is claimed.