A deletion request, and the copies nobody listed
A customer exercises a deletion right. The source row is deleted and the request is marked complete. Weeks later their support text is returned by the in-product assistant, and their name appears in a monthly aggregate that is regenerated on demand.
What you would do first
Answer before revealing anything. The value of the exercise is entirely in committing to a diagnosis you can be wrong about.
- 1Establish the blast radius from lineage before deleting anything else, including derived artefacts that are not tables: indexes, extracts, evaluation sets, model training data.
- 2Distinguish what must be erased from what may be retained in a form that no longer identifies the person, because those have different remedies.
- 3Check which derivatives are rebuilt from raw and which hold their own copy — the first are fixed by rebuilding, the second have to be addressed directly.
- 4Find the artefacts outside the lineage graph, which is where the retrieval index and the notebook extract usually live.
What is actually going on
The trap
The fix that looks right. Read it even if you got the answer — especially then.
Delete the raw partitions containing the customer's records. The most sensitive copy is gone, so is the only evidence of what was collected and where it propagated, every downstream dataset still holds the derived values, and the periods those partitions covered can no longer be reproduced for anyone.