Your data: deletion and retention

Guide · Users and administrators · Applies to 5.0.192

What Eldric erases when an account, a tenant or a conversation is deleted, what it keeps and for how long. The page also lists what a deletion does not reach, so you can answer a data-protection request accurately.

Deleting your own account

Send DELETE /api/v1/users/me with your password in the body ({"password": "…"}). An account without a password, for example one that signs in through single sign-on, must have signed in within the last five minutes instead. The web chat has no button for this yet.

• Your API key and every session stop working before the answer arrives.
• The answer gives the erasure job and restorable_until: your data first goes into a trash for 30 days, from which an administrator can restore it. After that it is erased for good.
• The last administrator of a tenant, and the last superadmin, cannot delete themselves (409 last_admin). Make someone else an administrator first.

Deleting a user or a tenant

A user: an administrator sends DELETE /api/v1/identity/users/<id>. This starts the same erasure as a user's own deletion, including the 30-day trash; the job id comes back in the X-Eldric-Erasure-Job header.

A tenant takes two steps, and only an administrator who belongs to no tenant (or a superadmin) may take them:

1. POST /api/v1/tenants/<id>/delete-request answers with a confirmation token, valid once for ten minutes, and lists the users who will be erased.
2. DELETE /api/v1/tenants/<id>?including_users=true with the header X-Eldric-Confirm-Token. Every account in the tenant gets its own erasure job, and the tenant is suspended and later ended. Without including_users=true the request is refused while the tenant still has users.

Watching and undoing: GET /api/v1/admin/privacy/erasures lists the erasure jobs with the state of every part of the cluster they reached. While a job is in the trash, POST /api/v1/admin/privacy/erasures/<id>/restore brings the data back and …/purge erases it at once. A tenant administrator sees the jobs of their own tenant.

The trash period is 30 days. ELDRIC_PRIVACY_TRASH_DAYS in the controllers' environment changes it (0 to 3650).

What is erased

Every part of Eldric that keeps data about a user takes part in the erasure, on every node:

• The account, its key and its roles.
• Conversations, including the chat history kept by the edge, the user's entries in the chat search index, settings, theme, active project and the devices registered for notifications.
• The user's personal memory and the profile Eldric learned from their conversations.
• Episodes the user recorded. On other users' episodes, the user's applications and outcomes become deleted-user.
• The user's personal messaging accounts, with their stored messages and credentials.
• Agent sessions the user owns, swarms they own with their runs and goals, their experiment assignments and events, their science source requests and the skills Eldric learned for them.
• Documents the user uploaded to a knowledge base from 5.0.189 on, and their saved artifacts.
• The telephone sign-in record.
• In projects and workgroups the user's membership and ownership become deleted-user; the project itself stays with the tenant.

Usage records stay for billing, but at the end of the trash period the user in them becomes deleted-user. After that, the erasure record itself keeps the user's id but no longer their name.

Deleting a tenant erases all of the above for each of its users, plus what belongs to the tenant: its storage, memory, knowledge bases, messaging accounts, projects, workgroups and prompts.

What a deletion does not reach

• The access log and the audit log. They record who did what (user or key id, tenant, client IP address, time and result, never content or keys) and are kept for two years. A deletion does not shorten that.
• Memory filed for the whole tenant rather than for the user stays with the tenant.
• Knowledge-base documents uploaded before 5.0.189 do not record who uploaded them, so they go only when the tenant is deleted.
• The dream training corpus, if an administrator switched it on for the tenant (it is off by default): a user's lines are removed only when the tenant is deleted. Otherwise they expire after 90 days.
• Things that belong to the tenant stay: shared messaging accounts, projects and workgroups, experiments, devices and science sources.
• Backups taken before the deletion still contain the data until they expire; see Backups.
• A node that runs an older release may not know how to erase its part. The erasure job then marks that part as unsupported and still completes. Update every node before you rely on a deletion.

Deleting a conversation

Deleting a conversation removes it for good, on the node that stores it. What Eldric learned from it depends on one setting:

• Facts the user stated in the conversation are kept, but from 5.0.192 they no longer point back to it. This happens on every node.
• Memories Eldric distilled from the conversation are forgotten only on a node where an administrator has set ELDRIC_FORGET_DERIVED_ON_DELETE=1. The setting is off by default. When it is off they are kept, and because the link to the conversation is gone, switching the setting on later cannot remove them.

The answer to the deletion says which of the two happened (derived_memories: forgotten, kept or failed), and how many stated facts were kept.

How long Eldric keeps records

Record	Kept for	Changed with
Deleted accounts (trash)	30 days	ELDRIC_PRIVACY_TRASH_DAYS
Backups on the controllers	30 days, see Backups	PUT /api/v1/backup/retention
Audit log	2 years; older archives are replaced by a signed checkpoint so the chain stays verifiable	ELDRIC_AUDIT_RETENTION_DAYS
Access log	2 years	ELDRIC_ACCESS_AUDIT_RETENTION_DAYS
Usage records	7 years	ELDRIC_METERING_RETENTION_DAYS
Dream training corpus (off by default)	90 days	the dream settings

Environment variables are read by the Eldric service at start, on the controllers. An audit archive is removed only when the node can sign the checkpoint, which needs the cluster secret; without it nothing is removed.

The access log is readable by superadministrators and administrators without a tenant in full, and by a tenant administrator for their own tenant: GET /api/v1/audit/access.

Backups

• From 5.0.185, backups on the controllers older than 30 days are deleted automatically, every day, whether or not a backup schedule is set. The newest successful backup of each store, and any backup a newer one depends on, are always kept.
• Administrators read and change the period at GET|PUT /api/v1/backup/retention (1 to 3650 days). POST /api/v1/backup/retention/run shows what would be deleted, without deleting it.
• Copies on remote destinations (S3, scp) are not deleted by Eldric. Expire them on the destination.
• Restoring a backup does not bring back data that was erased after the backup was taken: Eldric applies those erasures again after the restore.