QAEDA-TST-004 · design constraint

Minimize data and separate identity

What is the minimum information the system must collect, retain, link, and reveal to perform the legitimate safety function?

Pass condition

What a defensible proposal should be able to show.

The design limits raw-history retention, separates identity from inquiry where feasible, constrains secondary use, defines deletion, and prefers aggregate, local, ephemeral, or attribute-only processing when those patterns can achieve the objective.

Warning signs

Signals that the proposal is drifting.

  • Full identity is required when only an eligibility attribute is needed.
  • Raw prompts, searches, or browsing histories are retained indefinitely for unspecified future safety uses.
  • Data collected for one safety purpose can silently flow into advertising, employment, insurance, policing, immigration, or political profiling.
  • Deletion depends only on policy promises while the architecture keeps unnecessary copies.

Evidence to demand

What should exist before confidence rises.

  • A data-flow map showing collection, linkage, retention, access, and deletion.
  • Justification for each persistent identifier and retained field.
  • Technical evidence for isolation, aggregation, local processing, or anonymous credentials where claimed.
  • A secondary-use policy enforceable through technical or institutional controls.
Failure mode

A safety database can become a general-purpose behavioral dossier even when the original objective was narrow and legitimate.

Decision discipline

No single passing test licenses the intervention.

Apply the full sequence. A defined harm does not excuse a weak nexus; a narrow mechanism does not excuse secret secondary use; an appeal process does not prove efficacy.