data-retention

Data retention and erasure

An erasure request is not "delete everything matching this person". Some records must be kept, and deleting them is itself a violation. The job is to produce a scope certificate: exactly what is destroyed, exactly what is kept, and why.

This skill encodes a defensible default posture for a demo system. It is not legal advice. A real deployment must have its retention schedule reviewed by counsel, and the reasons in the exclusion list should cite that schedule rather than this file.

---

1. The shape of the answer

Never produce a list of deletions alone. Always produce both halves:

Half	Meaning
Records	Everything that will be destroyed, per system, with a real count
Exclusions	Everything deliberately retained, per system, each with a stated reason

An exclusion without a reason is not an exclusion — it is an omission. The contract rejects one with an empty reason for exactly that purpose.

---

2. Find the person before you delete them

Enumerate on a shadow copy first. Follow the foreign keys; do not guess at table names.

-- What actually references users?
SELECT tc.table_name, kcu.column_name, rc.delete_rule
  FROM information_schema.table_constraints tc
  JOIN information_schema.key_column_usage kcu USING (constraint_name)
  JOIN information_schema.referential_constraints rc USING (constraint_name)
  JOIN information_schema.constraint_column_usage ccu USING (constraint_name)
 WHERE tc.constraint_type = 'FOREIGN KEY' AND ccu.table_name = 'users';

delete_rule matters enormously:

• CASCADE — rows vanish with the parent. They must appear in your record list, or the certificate understates the blast radius.
• RESTRICT / NO ACTION — the delete will fail until you handle them. Find out now.
• SET NULL — the row survives, de-linked. Decide whether that counts as erasure.

Count every one of them before proposing anything.

---

3. Typical retention obligations