> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maximem.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Erasing a Person
> Deleting everything Synap holds about one person, what that makes permanently unreadable including in backups, and the one thing it deliberately leaves behind. Covers the preview step, the confirmation, and how to request it.
**There is no undo.** Erasure destroys the encrypted form of every protected value it covers. Once it has run, those values cannot be recovered by us, by you, or from a backup taken a minute earlier. That is the point of it, and it is why the operation is deliberately two steps.
## What erasure is for
A person asks you to delete everything you hold about them. You need to be able to say yes, and mean it, including for copies that exist in backups you cannot go back and rewrite.
Ordinary deletion cannot promise that. A backup taken yesterday still holds yesterday's rows, and no delete statement reaches it. Erasure solves it a different way: the values Synap holds for a protected field type are unreadable without a key, and erasing a person destroys the part that makes their values readable. Every copy, everywhere, including in backups, becomes meaningless bytes at the same moment.
## How to request it
Erasure is not a self-service button. Email **[privacy@maximem.ai](mailto:privacy@maximem.ai)** with the instance and the `user_id` or `customer_id` to erase, and the reason. Synap runs it, and it appears in your own **Activity** tab the same day with the name of the person who ran it.
It is a support-operated action for one reason: a preview that says four things and an erasure that removes nine hundred is a conversation nobody should have to have. The two-step flow below is what prevents that, and it is run by a named person against a number you have both agreed on.
***
## The two steps
The preview counts exactly what would go, using the same conditions the erasure itself runs. It is not a confirmation dialog with an estimate in it; the number cannot turn out to be wrong.
It reports:
* How many protected values would be destroyed, broken down by field type
* How many memory records would be deleted
* How many values would be **kept**, because they are shared with other people
* A plain-language summary of all of the above
It reports counts only. It never lists the values, because assembling a list of one person's sensitive data in order to delete it is the shape of problem this whole feature exists to avoid.
The erasure carries the number the preview showed. If the real total has moved since you looked, because new data arrived, the erasure stops rather than deleting a different amount than the one that was agreed.
An audit entry is written **before** anything is deleted. An erasure that succeeded with no record of who ordered it would be worse than one that failed.
***
## What becomes unreadable
Every protected value held for that person is destroyed. Afterwards:
* Their memories keep their sentences and their placeholders, so the record of what happened is still readable.
* Every placeholder belonging to them stops resolving. Your application receives the placeholder rather than a value, and so do we.
* A reveal on one of those placeholders returns nothing, for anyone, including Synap staff.
* Backups taken before the erasure contain the same unreadable form. There is nothing in them to recover.
Their memory records are deleted as part of the same operation.
If you also need the underlying memory content itself removed everywhere it has been indexed, say so in the same request. Erasure is specifically about making the protected values unrecoverable; removing content from every store goes through the standard deletion path described in [Security and Trust](/resources/security-trust#deletion-guarantees).
***
## What is deliberately kept
Some values are shared by construction. Two people give you the same phone number. One company address appears in a thousand memories. Deleting a shared value while erasing one person would silently break every other person's memories that reference it, and that failure looks like the product forgetting rather than like a deletion.
So Synap erases the values held under that person's own scope, and leaves values that are shared more widely. The preview counts them and says so plainly, in the form: *"N value(s) will be kept, because they are shared with other people. Deleting them would break other people's memories."*
Whether a given shared value should also go has a real answer, and it is different per client. If it should, say so in your request and it is handled as a separate decision.
***
## Erasing an entire client
Removing a whole account is one operation, not a scan. Every value that account owns becomes unreadable immediately, with nothing to search for and nothing to re-encrypt, including in backups already taken.
The memory text itself is left readable as sentences, with the placeholders still in place. There is no key anywhere that turns those placeholders back into values.
***
## What this does not cover
* **Data ingested before you approved a policy is plain text.** It was never protected, so there is no key whose removal makes it unreadable. Erasure cannot reach back and change that. If you need old data cleaned up, that is a re-processing job; ask us and we will scope it.
* **Field types you never protected are plain text**, for the same reason. Erasure protects what was protected.
* **A person you cannot name cannot be erased.** The operation works from a `user_id` or a `customer_id`. If your application does not pass a stable id, there is nothing to match on.
***
## The paper trail
Every erasure writes one entry to your **Activity** tab, before it runs, recording who ordered it, what reason they gave, how many things it covered, and when. Your own staff and Synap's appear in the same list with a column saying which is which.
Entries are kept for one year and can be exported as a CSV file for an audit. A Synap staff member operating an impersonated session cannot run an erasure at all: impersonation exists so we can see what you see, and destroying data has to be done in a named person's own name.
## Next steps
What a placeholder is, and what stops resolving after an erasure.
Deletion guarantees, encryption, and the limits we state plainly.
What gets protected in the first place, and how you decide.
Common questions from engineering and from security reviewers.