Erasure

Govern › Erasure answers a person’s request to be forgotten. An admin picks the person, Olympusx AI deletes their conversation data in one step, and a receipt records what was deleted, what was kept and why. The receipt names the person only by a digest, so the platform keeps no register of the people it erased.

Who can open it

Role	What they can do
Admin	See the people with conversation data, erase them, and read the receipts.
Auditor	Read the receipts in Erasures performed. A Read-only notice says that seeing who can be erased, and erasing them, requires an administrator.
Builder, End user, Reviewer	Cannot open the page.
Platform admin	Everything, for any tenant.

Who can be erased

Olympusx AI knows a person by the reference their conversations carry. There are three kinds:

Kind	Who it is	Reference
End user	A customer of your own application.	The opaque handle your application sends: endUserRef when it calls an assistant, or the user field on a call to the gateway.
Public-link visitor	Someone who used an assistant’s public link.	A reference starting with v- that the public assistant page shows its visitor, so they can quote it in a request. Erased as an end user.
Studio account	Someone who signs in to the console.	The sign-in subject of their account.

An end-user reference must be opaque: under 200 characters, with no @. Olympusx AI refuses an email address. Never put a name, a national identifier or an account number in a reference: the reference is stored on every conversation, and a reference that is itself personal data defeats the erasure.

Caution

Erasure by person works on conversations stored with a reference. Send endUserRef or user with every call your application makes on behalf of a customer. Conversations stored without a reference follow the conversations retention window; see Data retention.

What is erased

For	Deleted
An end user or a public-link visitor	Their conversations with every assistant (assistant_threads, assistant_messages), the agent sessions on those conversations (agent_sessions, agent_session_events), the review scores recorded on them (scores), and gateway traffic captured under their reference (gateway_samples).
A Studio account	The conversations they started in the console, with the same agent sessions and scores, plus their preferences (user_preferences) and their notification settings and read state (notification_prefs, notification_reads, notification_read_state).

Deletion is outright: the rows are not hidden, and they are not recoverable from any backup Olympusx AI controls. Backups your organization takes outside Olympusx AI are yours to handle.

Tool calls held for approval in an erased conversation are closed as rejected, with the reason “the conversation this call belongs to was erased on request, so the call cannot run”. Each closure is recorded on the audit trail.

After erasing a Studio account, also remove the person in your identity provider. To stop them signing in to the console, disable or remove them on Users and roles.

Records that follow their own retention

Data	Retention
audit_log — the audit trail	Follows its own retention, under a legal obligation. The trail is hash-chained, so deleting from it is indistinguishable from tampering.
usage_ledger — metered usage	The record that a cost was incurred, and by whom. It follows its own retention so that every billed month stays complete.
agent_runs — agent runs	Operational evidence of what ran and what it cost, kept under its own retention window.
documents — knowledge documents	The tenant’s own ingested corpus, not conversation data. To correct it, re-ingest the source so the search index is updated.
security_findings, security_investigations, security_actions	Security records drawn from the audit trail, kept under the Security retention windows.
erasure_requests — the receipts	The record that an erasure was performed, and by whom. It stays as the proof of each earlier erasure.

Each of these has its own retention window, which a platform administrator sets. See Data retention.

What you see

1. The header, “Delete everything the platform holds about one person, and keep the proof that it was done.”, with the tenant picker.

2. Notices: Read-only for an auditor, The erasure was refused after a failure.

3. People with conversation data (admins): everyone the tenant’s assistants hold conversations for, most recently seen first.

   Column	What it shows
   Reference	The Studio account’s display name, when it set one, above the reference.
   Kind	End user, Public-link visitor or Studio account.
   Conversations	How many conversations they have.
   Assistants	The assistants they talked to.
   First seen, Last seen	When their first and latest conversations happened.
   Actions	Erase.

   Filter with Kind (Every kind by default) and Search by reference or name. The table shows the 200 most recently seen; when there are more it says how many, and search finds the rest. The table never shows what anyone said.

4. Conversations with no person attached, with a count, when the tenant has any.

5. Receipt, right after an erasure: Erased, then Deleted (rows per data class) and Kept, and why.

6. Erasures performed: every erasure in the tenant, with When, Subject (the kind), Digest (the first 16 characters) and Rows erased. Expand a row to read its full receipt. Search by digest finds one.

7. Erase someone not in the list (admins), for a reference that left no conversation.

What you can do

Erase a person from the list

1. Open Govern › Erasure and choose the tenant.
2. Find the person in People with conversation data, by reference or name.
3. Select Erase on their row.
4. Read the dialog Erase everything held about this person?: the person, their kind, their number of conversations, what is erased, and what is kept and why.
5. Select Erase permanently.

The erasure runs as a single transaction: either everything listed is deleted, or nothing is. The Receipt appears, and the person leaves the list.

Erase a reference that is not in the list

For a person who left no conversation here, such as a reference from your own application that never reached an assistant. Anything held under it, such as captured gateway traffic, is erased, and a receipt is kept the same way.

1. In Erase someone not in the list, choose Who is being erased: End user or Studio account.
2. Enter the End-user reference (for example cust-7f3a91) or the Sign-in subject.
3. Select Erase this person, then Erase permanently.

Confirm that a request was actioned

The reference itself is never stored. To find the receipt for a request, compute the SHA-256 digest of the reference, in lowercase hexadecimal, and search Erasures performed for it:

printf '%s' 'cust-7f3a91' | sha256sum

Use the reference exactly as your application sent it, with no trailing newline. An auditor can perform this check without seeing who else was erased.

The proof

Every erasure leaves three records:

• The receipt, kept in erasure_requests: its id, the subject’s kind, the digest of the reference, the rows deleted per data class, the data classes kept with their reasons, and the time it completed.
• An audit entry, erasure.end_user or erasure.platform_user, naming the admin who performed it. Its object is digest: followed by the digest, never the reference, and its after record carries the same counts and the receipt id.
• The audit entries for any held tool calls it closed.

Erasure has no pending or partial state. A request that fails changes nothing and says why in The erasure was refused.

Limits

Limit	Value
End-user reference	Up to 200 characters, no @
People listed on the page	200 most recently seen; search for others
Time allowed for one erasure	60 seconds; a request that runs longer changes nothing
Digest	SHA-256 of the reference, lowercase hexadecimal

Related

• Sovereignty and data
• Audit
• Data retention
• Publish and share, for public links and their visitor references
• Agents and assistants over the API, for sending endUserRef
• Users and roles