Privacy and erasure
Answer a request to be forgotten: find everything held about a person, erase it across every store, and keep the receipt.
"Delete everything you know about this person." Memtro can answer that, across every store it keeps, and hand you a receipt saying what went.
Dashboard → Organisation → Privacy is for admins and for anyone granted Search and erase a person's data — a data protection officer is often not an admin. The same work is available over the API, so a privacy inbox or help desk can drive it.
Find out what is held
Type a name, an email address, or several separated by commas. Nothing is deleted at this stage: you get back the entities the identifier resolves to — with their aliases and addresses — and a count for every store, with a sample of the actual records so you can confirm it is the right person. That answers a subject access request (Art. 15) on its own.
Searching matches whole words, so Kim does not reach Kimberley, and an identifier shorter than three characters is refused: it would match an enormous amount of unrelated text, and an erasure cannot be undone.
Every name the person is known by is searched, not just the one you typed. Memtro collects aliases as it learns — a login, the local part of an email address, a first name on its own — and all of them identify the same person. The preview lists each identifier with how many facts it reaches by itself, because one broad alias can account for almost the whole total: erasing someone whose aliases include their first name alone will take every record that mentions anyone of that name. When that happens the page says so in as many words. Untick the entity an unhelpful alias belongs to, or search a more specific identifier.
Aliases shorter than three characters are left out of the search and named on the page. That is not a mistake in what you typed: ad, taken from ad@mclark.co, is a perfectly good alias and a terrible search term. A record that refers to the person only by such a name will not be found.
What an erasure reaches
| Store | What goes |
|---|---|
| Entities | The person or company itself: names, aliases, addresses, identifiers and its embedding |
| Relationships | Every link to and from those entities |
| Facts | Remembered statements about them, with their embeddings — including ones that only mention them in passing |
| Recorded values | The amounts, dates and counts held against those entities |
| Kept exchanges | The transcripts and tool results Memtro keeps so a better extractor can read them again |
| Conversations | Chats that mention them, deleted whole: title, messages and the stored model replies |
| Suggested questions | Generated prompts that named them |
| Imported items | Raw ChatGPT or Claude exports mentioning them |
| Cached tool results | Connector responses held briefly for speed |
| Job output | What scheduled jobs wrote about them |
| Request logs | Their own API requests — only when the subject is a member (these record who asked, which model answered and how many tokens, never content) |
| Commitments | Promises they made or were named in, and the graph entity mirroring each |
A conversation goes whole rather than becoming a redacted shell: a chat that discusses someone is itself about them. Facts that mention the person while being mostly about something else go too — which is why the preview shows you the records before you confirm.
Embeddings are columns on the rows that are deleted, so they go with them; there is no separate vector store to sweep. The in-process embedding cache is cleared as part of the erasure, and no other process holds one for longer than a run, or fifteen minutes.
Proof
The deletes and a verification pass run in one transaction: after deleting, the same searches run again, before the commit, and what they find is written onto the receipt. A receipt that says nothing remains was checked, not assumed. If any step fails, nothing is deleted and no receipt is written.
Each receipt records the identifiers the request was made with, the count removed from every store, the ids of the entities and facts that went, who carried it out and when, and the verification result. It holds no erased content — the ids refer to rows that no longer exist. Download it as JSON from the Privacy tab to hand to whoever asked, or to a regulator.
What is deliberately not deleted
- A scheduled job whose prompt names the person. Deleting it would silently stop work nobody asked to stop, so it is listed for you to decide on.
- The person's own account, if they are a colleague. Their conversations, imports and request logs are erased; removing the member, their seat and their membership is done on the Members tab.
What erasure cannot reach
- The systems Memtro reads. Erasing here deletes nothing from your CRM, mailbox, ledger or help desk. If the person is still there, the next hourly sync will record them again — delete them at the source first, then erase here.
- A model provider's own logs. Requests already sent to Anthropic, OpenAI or Google are subject to that provider's retention, not Memtro's.
- Backups. Database backups taken before the erasure still hold the data until they age out.
- Fingerprints. Memtro keeps a hash of each processed exchange so it does not learn the same thing twice. A hash holds no content and cannot be searched by name, so these stay.
A leaver is a different question
An erasure answers a request from a person. A colleague leaving is not that request, and answering it with an erasure throws away working knowledge the organisation paid for and still needs.
Personal memory belongs to the organisation the person was in, so when their membership goes their memory would otherwise be stranded — unreadable by them, because they are no longer a member, and unreadable by the organisation, because it is marked as theirs. Orphaned, invisible and kept indefinitely, which is the worst of both outcomes.
So removal asks, and there are only three honest answers: hand it to a team, keep it as organisation memory, or erase it. Each is carried out in its own transaction with a receipt, which sits with the erasure receipts because an auditor asks the same question of both — what did you hold about this person, what did you do with it, and who decided. An offboarding done by mistake can be put back from its receipt.
The things a leaver owned that keep acting — their connections and the OAuth tokens in them, their API keys, their scheduled jobs and their provider keys — are deliberately left alone and counted on the receipt as flagged. A screen that tidies the memory and leaves a departed employee's mailbox syncing has done the less important half. See Billing, seats and leaving.
Data retention
Erasure is about one person. Retention is about everything else that accumulates: the trace of each reply, the runs of each job, the request log, the events a sync writes. An administrator sets it per data type on Organisation → Privacy & Retention, under Data retention, and the nightly sweep applies it:
| Data | Default | What the sweep removes |
|---|---|---|
| Request logs | 180 days (never below 90, which is the longest usage window) | Rows older than the window, for this organisation. |
| Chat runs | Kept | Finished runs older than the window; a run in progress is never touched. |
| Job runs | Kept | Finished runs older than the window, always keeping the most recent run of every job. |
| Chat progress | Kept | The progress trace and tool parts stored with each reply older than the window; the reply's text stays. |
| Sync events | Kept | Events a connector sync wrote older than the window, unless a commitment, contradiction or term still rests on them, or they are history a later memory replaced. |
| Kept exchanges | 90 days | The transcript of each exchange memory was learned from, kept so a better extractor can read it again. What was learned from it stays; only the conversation goes. This is the one place Memtro holds raw conversation outside the chat it happened in. |
Each window is 30, 90, 180 or 365 days, or kept, and applies from the next nightly run. What a sweep removed is recorded with the run.
Over the API
Authenticate with Authorization: Bearer sk-memtro-…; the key's holder needs the erasure permission, or to be an admin. Erasure is not exposed as a tool the model can call: nothing the model decides should be able to delete your records.
What is held about a person, deleting nothing:
curl "https://platform.memtro.com/api/privacy/erasures?subject=jane@acme.com" \
-H "Authorization: Bearer sk-memtro-..."
Erase it. Without "confirm": "ERASE" the request deletes nothing and comes back 422 with what it would delete, so a client can show that to a person first:
curl -X POST https://platform.memtro.com/api/privacy/erasures \
-H "Authorization: Bearer sk-memtro-..." \
-H "Content-Type: application/json" \
-d '{"subject":"Jane Smith, jane@acme.com","confirm":"ERASE"}'
The reply is the receipt. Pass "entities": ["<id>", …] to erase only some of what the identifier matched — useful when a common name turns up two different people. GET /api/privacy/erasures lists every receipt for the organisation; GET /api/privacy/erasures/<id> fetches one.
{
"document": "Memtro erasure receipt",
"regulation": "UK GDPR / EU GDPR Article 17 (right to erasure)",
"erasure_id": "…",
"subject": { "searched_for": "Jane Smith, jane@acme.com", "identifiers_used": ["Jane Smith", "jane@acme.com", "j.smith"], "was_a_member": false },
"deleted": { "entities": 1, "relationships": 8, "attributes": 3, "memories": 12, "episodes": 9, "chats": 4, "chat_messages": 44, "chat_runs": 15, "tool_cache": 6, "job_runs": 8, "imports": 0, "chat_suggestions": 0, "request_logs": 0 },
"deleted_total": 98,
"verification": { "method": "The same searches were run again inside the same transaction, after the deletes and before the commit.", "still_matching": { "memories": 0, "chats": 0 }, "complete": true }
}
Also worth reading
- Memory — what is held, and where each fact came from.
- Time travel — the history an erasure is the one thing that removes.
- Teams and permissions — granting the erasure permission to somebody who is not an admin.
- Security — where the data sits, and how it is held.