# Tenant registry retention and deletion policy

Status: implemented policy for the current data model; reviewed 2026-08-18.

This policy is the authoritative `deletionPolicyRef` for tenant-engine. It
separates business-record retention from PostgreSQL backup retention; a backup
window never silently decides when an authoritative tenant fact may be erased.

## Primary records

Tenant records are canonical registry facts. `retire` is reversible and is not
deletion. Tenants, plan assignments, grant/revocation history, domain events
and guardrail changes are retained without an automatic expiry while the
registry remains authoritative. There is deliberately no hard-delete API.

Contact email and display name are the only mutable person-attributable fields.
An authorized erasure request is an attended maintenance change: remove or
replace those fields while preserving the tenant id, identifier, lifecycle,
version and audit trail needed to explain prior authorization decisions. Until
that operator procedure has run, tenant-engine makes no claim that retirement
erases personal data.

Idempotency receipts currently have no automated primary-store expiry. They
therefore share the indefinite primary retention above. Introducing an expiry
requires a forward-only migration plus proof that the maximum client retry
window is shorter; it must not be inferred from the backup window.

## Copies outside the primary database

- `platform-pg` physical backups and WAL have a 30-day retention window shared
  across all databases on the cluster. After a primary-row redaction or future
  deletion, physical copies can remain recoverable for at most that declared
  window, subject to a successful and verified backup-policy deployment.
- The per-consumer encrypted logical export is retained for 30 days. Its
  declaration is `rapp-postgres/consumers/tenant-engine.yaml`.
- Scratch restores are operator-created evidence environments and must follow
  the platform scratch-restore policy; they are not production read replicas.
- The stopped SQLite PVC retained during cutover is a rollback copy. It must be
  access-restricted, named in the cutover record, and destroyed only after the
  PostgreSQL soak and rollback decision. It is not a second live source of
  truth.

## Assurance position

Publishing this policy does not raise tenant-engine above R0 by itself. The
service has policy-driven backup-copy windows, but no automated primary-row
expiry or verified personal-field erasure workflow. `tenancy.yaml` therefore
keeps current R0 and target R2. A customer-facing “deleted data is gone” claim
is prohibited; any future claim must disclose the effective erasure horizon
and be backed by dated deletion plus backup-expiry evidence.