tegwick
749461b97b
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 41s
Add the PostgreSQL backend, migration and stopped-write transfer tools, lease-aware deployment manifests, tenancy declarations, and shared conformance coverage. Persist grouping mutations in durable stores and separate process liveness from database readiness.
50 lines
2.7 KiB
Markdown
50 lines
2.7 KiB
Markdown
# 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.
|