Data Integrity

The storage layer: is the stored state correct, isolated, and recoverable, independent of who the actor is?

In scope. Persistence correctness, schema and migration safety (backfills, non-nullable adds, rename safety), transaction atomicity, per-record tenant isolation (query-scoped tenant_id filters, row-level security), backup / restore viability, data-quality invariants (duplicates, orphans, referential constraints), retention and deletion mechanics on the storage side.

Not in scope. User-facing rights over their data (access requests, erasure requests) — those are privacy-consent. Injection-driven corruption — that's injection-and-input-trust. Unauthorized cross-tenant reads — that's access-control (even when it surfaces as isolation failure, the decision layer is where the gate failed).

Distinct because. The defect is "the bytes in the database are structurally wrong" or "can't be recovered." A legitimate admin running a bad migration hits data-integrity. The beneficiary of a fix is anyone who reads the data, not specifically the user whose privacy is at stake.

Conceptual sub-structure. Schema/migration, tenant isolation, persistence correctness, retention, backup/restore.