Data Retention Policy

Effective: v1.4 general availability. Last updated: 2026-07-28.

This policy defines the maximum normal retention for Aletheia production data. Shorter deletion applies when a user deletes a run or purges account data.

Data class	Normal retention	Enforcement
Encrypted local binary vault	Controlled by the user	Files remain on the user's device until the user explicitly deletes the binary or purges local/account data from the signed desktop
Ephemeral local plaintext analysis copy	Local worker lifetime only	Owner-only session storage is removed after worker termination; startup and maximum-age cleanup cover abnormal termination
Derived evidence and proof bytes	30 days from run creation	Migration-backed expiry, indexed bounded deletion and a single-writer retention worker
Orphan derived artifacts	Until the last referencing run expires or is deleted	Collected during run deletion/retention transactions
API keys	Until revoked or account data is purged	Hashes only; full keys are shown once
Account and tenancy state	Account lifetime	Anonymized when account data is purged
Local device identity and enrollment authority	Device/account lifetime	Local native keys and cloud device rows are deleted during desktop account purge; a browser purge deletes cloud rows but cannot erase an offline desktop key
Purge fence	Indefinite operational integrity record	Internal random tenant UUID and purge time only; prevents stale replicas recreating deleted evidence
Billing and payment audit records	Applicable legal, tax, fraud and dispute period	Restricted documented exception; card data remains with Stripe
Product analytics	Production provider retention, capped by launch configuration	User can opt out in Settings; no binary or conversation content
Error diagnostics and service logs	No more than 30 days in normal production operation	Provider configuration and launch audit; security incidents may require a documented legal hold
Encrypted database backups	30 days	Automated expiry; restore procedure reapplies later purge tombstones before traffic

Retention worker behavior

The production worker uses a Postgres advisory lock so only one replica deletes expired data at a time. Deletion is tenant-scoped and batch-bounded. Saturation, backlog, failures and deletion counts are operational metrics. A worker failure must alert operators; it must not silently extend retention without an incident record.

Exceptions and holds

Retention can be extended only for a documented legal obligation, active fraud or abuse investigation, payment dispute, or security incident. The record must name the data, owner, reason, approval, review date and deletion condition. Customer binaries are not eligible for a routine retention extension.

Backup restoration

Backups are not an active-data source. Before a restored database serves traffic, operators must apply migrations, replay the deletion registry through the restore point, run retention, and verify tenant isolation. Failure to prove that sequence blocks restoration promotion.

Ownership and review

The production owner reviews retention metrics weekly during RC/soak and at least monthly after GA. This policy and its technical controls are reviewed after material architecture changes and at least annually.