Third House — Data Retention Schedule

Effective date: [DATE] Version: [1.0]

Part of the Privacy Notice. It states how long each category of data is kept, why, and what happens on deletion.

CURRENT STATUS, STATED PLAINLY: none of this is enforced by code. There is no retention job, no deletion flow, and no scheduled purge. Every period below is a proposed policy, not a description of current behaviour. Today, data is kept indefinitely. Closing that gap is a build task and is listed in §7.

---

1. Principles

1. Keep what the service needs, for as long as it needs it.
2. Keep what the law requires, for as long as it requires.
3. Delete the rest.
4. Deletion severs identity; it does not rewrite financial history. Money records are append-only by design. On deletion the identity link is broken and the row is anonymised, so the books stay intact and the person does not.

---

2. Retention by category

2.1 Account and identity

Data	Table	Retention	Why
Account record	auth.users	Life of account + 30 days	Grace period for accidental deletion
Profile	profiles	Life of account + 30 days	As above
Astrologer profile	astrologer_profiles	Life of account + [7] years after last payout	Tax and payout records

2.2 Birth data and charts

Data	Table	Retention	Why
Birth Data	birth_data	Life of account; deleted on account deletion	Sensitive; no reason to outlive the account
Cached charts	natal_charts	Life of the birth data; cascades on delete	Derived; recomputable
Chart inside a delivered Report	report_orders.provider_raw	With the Report — see §2.4	A Report cannot be explained without the chart it was written from
Birth details on a Report order	report_orders.subject_birth_data	With the order — see §2.4	Details typed in for a Report, or a copy of a saved chart deleted after its Report was ordered, so the Report can still be written or put right

Note on the last two rows. Deleting Birth Data does not retroactively empty a Report. One already delivered embeds the chart it argued from, and one still being written keeps a copy of the birth details it was ordered with. Either way it is the customer's document. The Privacy Notice should say so plainly so deletion is not oversold.

2.3 Conversations with Mercury

Data	Table	Retention	Why
Conversations	ai_conversations	Life of account, or until you delete the thread	Your history
Messages	ai_messages	Life of account, or until you delete the thread	Your history
Mercury's memory	mercury_memories	Until you delete the note or turn it off and delete it, delete the conversation it came from, or close your account. At most 60 notes; the oldest go first	Continuity between conversations (paid plans)
Daily usage counters	ai_usage_daily	[13] months	Entitlement caps and abuse patterns

2.4 Reports

Data	Table	Retention	Why
Order record	report_orders	[7] years	Purchase record; tax
PDF	Storage bucket reports	Life of account + [30] days, or until you delete it	It is your document
Generation attempts	report_generation_attempts	[24] months	Debugging; dispute evidence

2.5 Sessions with astrologers

Data	Table	Retention	Why
Session record	sessions	[7] years	Financial record
Transcript	session_messages	[24] months, then deleted	Disputes, chargebacks, safety investigations
Session events (append-only)	session_events	[7] years	Billing audit trail; chargeback evidence
Reviews	reviews	Published until removed; anonymised on consumer deletion	The astrologer's record does not vanish because a reviewer left

On the transcript period. Card-network chargeback windows run to roughly 540 days, so a transcript must outlive any dispute that could arrive. [24] months covers that with margin. Shorter is better for privacy; going under ~18 months risks destroying our own evidence.

2.6 Money

Append-only. Never edited, never deleted. Anonymised on account deletion.

Data	Table	Retention	Why
Balance ledger	balance_ledger	[7] years minimum	Bookkeeping; tax
Top-ups	topups	[7] years	As above
Astrologer earnings	astrologer_earnings	[7] years	Contractor payment records
Payouts	payouts	[7] years	As above
Subscription mirror	subscriptions	Life of account + [7] years	Billing history
Webhook events	webhook_events	[24] months	Idempotency and payment forensics

Corrections are compensating entries, never edits. A row that looks wrong stays and is answered by another row.

2.7 Safety, moderation, and analytics

Data	Table	Retention	Why
Moderation flags	moderation_flags	[3] years from resolution	Repeat-behaviour patterns
Analytics events	analytics_events	[25] months, user link dropped at [13] months	Product analysis
Auth/security logs	Supabase	[12] months	Intrusion investigation
Application logs	Vercel	[30] days	Operations. Never contain Birth Data.

2.8 Support

Data	Retention	Why
Support correspondence	[3] years	Context and dispute history

---

3. What deletion does, field by field

On a verified deletion request:

Action	Applies to
Hard delete	Birth data, cached charts, Mercury conversations and messages, report PDFs, avatar
Redact	Session message bodies replaced with a tombstone; sender identity severed
Anonymise	Ledger rows, earnings, payouts, session records, reviews — identity link removed, financial substance kept
Retain until closed	Anything under an open dispute, chargeback, or legal hold
Retain	Records we must keep by law, in anonymised form

Legal hold overrides everything here. If we are required to preserve data for litigation or a lawful request, retention is suspended until released.

---

4. Astrologer-held data

Astrologers receive consumer charts for booked sessions. They are contractually required to retain no longer than [12] months, keep it secure, and delete on request (Astrologer Agreement §6).

---

5. Backups

Database backups are retained [30] days on a rolling basis. Deleted data may persist in a backup until it ages out. Backups are not used to restore individual deleted records; a restore for disaster recovery re-applies completed deletions.

---

6. Review

Reviewed at least annually, and whenever a new data category, provider, or regulation applies. Owner: [ROLE].

---

7. Build gaps — nothing here is automated

Every item below must exist before this schedule describes reality rather than intention.

Gap	What is needed
No retention enforcement at all	Scheduled jobs that purge each category on its period. Nothing expires today.
No deletion flow	A verified account-deletion path performing the §3 matrix.
No export flow	Portable export for access requests.
transcript_retention is inert	Read nowhere. Implement the tiers or drop the column.
No legal-hold mechanism	No way to suspend deletion for a specific account.
No identity verification for requests	No documented procedure for verifying a requester.
No deletion audit log	Proving a deletion was performed needs a record of it — which must itself avoid re-identifying the person.