coulomb/tenant-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tenant-engine/docs/data-retention-policy.md
tegwick 749461b97b
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 41s
Details
Implement PostgreSQL production store path 
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.
2026-08-19 14:43:08 +02:00

2.7 KiB
Raw Permalink Blame History

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.