Erasure you can prove
How Fred deletes a conversation — completely, provably, and on the team's own terms. RGPD-ready data erasure, by design — for DSI/RSSI, architects, and users.
What deletion means
Deleting a conversation should mean it is gone — not hidden, not "scheduled", not left behind in some store nobody remembers. In an AI platform a single conversation is scattered across many places: the transcript, the model's working memory, uploaded files and their search embeddings, and the usage statistics. Fred treats erasure as a first-class operation over all of them, and hands back proof that it happened.
That same operation carries the platform's most useful trade-off. A team can keep a deleted conversation for a bounded retention window — hidden from people, but available to the team to measure how its AI agents performed on real work — after which erasure is guaranteed. The retention window is the evaluation window.
ERASED
Every erasure returns a per-store receipt. Complete, or it isn't done.
One delete, every store
A single erase_session operation fans out across every store the platform owns and
returns an auditable receipt — store by store, what was removed and whether it worked. Usage
statistics are anonymised, not deleted: aggregate counts survive, but the link
to a person is severed. The receipt's overall status is complete only if every store
succeeded.
Ordering is a correctness rule: checkpoint before transcript; the ownership anchor deleted last, so a partial failure stays retryable.
The commitments
Delete means delete
One action erases a conversation across every store and returns an auditable receipt — store by store, what was removed and whether it worked. No shadow copies, no "mostly deleted".
The retention window is the evaluation window
A team owner sets how long deleted conversations are kept, so the team can evaluate its agents on real usage — bounded by a platform ceiling the team can only tighten. Privacy's storage-limitation on one side, AI-Act monitoring on the other, owned by the team.
Immediate by default; deferral is a deliberate choice
With no window set, delete erases now. Deferral only happens when a team opts in — the ceiling is never a silent default that quietly keeps everyone's conversations around.
Never a half-state
A conversation that was hidden but never actually erased is treated as a defect, not a milestone. Erasure is retry-safe by construction: if any part fails, nothing is stranded and the work finishes on the next attempt.
The worker acts as the platform, authenticated
When erasure happens later, a background worker performs it — with no human present. It authenticates as the platform's own identity and is authorised to erase; it is never an unchecked backdoor, and it never impersonates a user.
Pseudonymous by default
Conversation stores hold an opaque identity token, never an email. Who someone is lives in the identity provider; what they said lives — briefly, accountably — in Fred.
Two ways to delete
Erase now
The full erasure runs on the spot, as you. The conversation is gone and you get the receipt.
Hide now, erase at expiry
The conversation is hidden immediately and provably erased when the team's window ends — tracked as a task you can watch.
How it converges
For architecture and RSSI review, the guarantee rests on a few invariants:
Every erasure is an observable task
Erasure is asynchronous — planned for a future date, or running right now across several stores.
None of that is invisible. Fred is built on a single async-task model (Temporal for
durability, the fred-core task library for state), so any surface can always answer
what is scheduled, what is in flight, and what finished — and admins get an erasure schedule
that reads the same way anywhere.
Evaluate agents on real conversations — without compromising the right to be forgotten.