Data Retention & Deletion Policy
Last reviewed: 2026-07-12. Status: current. Periods are the canonical values from ../inputs/decisions.md §2; change them there first.
Retention schedule
| Data class | Retention period | Deletion trigger |
|---|---|---|
| Verification & need-analysis records (cases, ISIR values, extracted fields, reconciliation results, uploaded documents) | 3 years after the end of the award year, then eligible for secure destruction | Time-based (award year ends June 30 of its second calendar year) |
Audit trail (review_actions, agent_runs) | Retained with the case record (same 3-year floor) | Same as the case record |
Communications (comms: email / SMS / voice transcripts) | Retained with the case record (same 3-year floor) | Same as the case record |
| Operational logs (Sentry events, structured error lines) | 90 days (rolling) | Time-based |
| All institution data, on contract termination | Returned or securely destroyed within 30 days of contract end | Contract end (TODO-PAT: confirm window + return-vs-destroy election) |
The 3-year verification floor is the federal Title IV requirement at 34 CFR 668.24(e) and is encoded in lib/retention.ts. The per-case purge-eligible date (retentionUntil()) is computed and printed on the verification audit package, so both the institution and Eli can see exactly when a record becomes destruction- eligible.
Deletion mechanics (current state, stated honestly)
There is no automated production case-data deletion job today. Destruction is a documented manual procedure: once a case crosses its purge-eligible date (or a contract ends), the records are deleted from Supabase (Postgres rows + any object-storage documents) under the qualified individual's authorization. A general production retention/deletion job is on the roadmap (see ../inputs/decisions.md §6).
A separate bearer-protected daily route deletes PII-free broad and beta2 product-experience telemetry from the shared experience_events table after 90 days. It does not delete or prove deletion of cases, documents, audit records, communications, operational/security logs, Subprocessor copies, or backups. Its deployed schedule, alerts, execution evidence, and provider-backup expiry still require verification.
When records are destroyed:
- Postgres rows for the case and its children are removed.
- Associated documents in Supabase object storage are deleted.
- The destruction action is itself logged.
Deletion on request
For a student or institutional deletion request that is consistent with the Title IV retention obligation, Eli supports targeted deletion of a case and its associated PII. Requests that conflict with the 3-year federal retention floor (records ED requires the institution to keep) are handled per the institution's direction, since the institution is the records custodian of record.
What "secure destruction" means here
Logical deletion from Supabase (Postgres + object storage). The underlying infrastructure providers (Supabase, Vercel) handle media sanitization and backup expiry per their own controls; their backup-retention windows are documented in the HECVAT sub-processor section.
Consistency note
These periods must match architecture-diagram.md (which shows the data stores and must not imply indefinite logs), incident-response.md (which references log retention), and rbac-model.md. If any disagree, this file and ../inputs/decisions.md §2 are authoritative.