Erasure

The Erasure tab on Data Governance permanently deletes one data subject’s data across every store — for a GDPR Article 17 “right to erasure” request, an account deletion, or a data subject access request (DSAR). It cannot be undone.

At a glance


Where	Data Governance in the left nav (Admin group) → Erasure tab
Who can use it	Company admins only — members and viewers get `403`
Key API routes	`POST`/`GET` `/retention/erasure`, `GET /retention/erasure/{id}`
Scope	Company-wide, with optional per-agent narrowing
Runs	Asynchronously on a dedicated cleanup queue, tracked to a terminal status

Erasure shares the same delete cascade as retention’s nightly purge, so what an erasure removes and what retention ages out never drift apart.

Run a subject erasure

Identify the subject

On the Erasure tab, describe who to erase using any combination of three selectors:

Selector	Use it when	Field(s)
Metadata match	A person maps to a value carried in the traces (the common case), e.g. `user_id = u_123`	Metadata key + Metadata value (both required together)
Session IDs	You already know the exact traces to remove	Session IDs (one per line or comma-separated)
Conversation IDs	You want every session in specific conversations	Conversation IDs (one per line or comma-separated)

You can combine them — Neens unions the resolved sessions. The selector cannot be empty: a request with no metadata match and no ids is rejected, so an erasure can never fan out into “erase everything.” Optionally Limit to agent to narrow the search to one agent.

Record a reason

Enter a Reason — a legal basis or ticket reference, for example DSAR SUP-1043. It’s stored on the erasure register and the audit log. You’re warned if you leave it blank; we strongly recommend always recording one for evidence.

Confirm and submit

Erase subject data… opens a confirmation dialog spelling out that this permanently deletes the subject’s data across all stores and cannot be undone. Confirming calls POST /retention/erasure, which creates a tracked request and runs the cascade asynchronously on a dedicated cleanup queue — so a large erasure never blocks live scoring.

⚠️

Erasure is irreversible. It hard-deletes the subject — there is no restore, and the deleted data is not recoverable. Double-check the selector (especially a broad metadata match) before confirming.

curl -X POST https://your-neens-host/retention/erasure \
  -H "Authorization: Bearer <admin session>" \
  -H "Content-Type: application/json" \
  -d '{
    "subject_key": "user_id",
    "subject_value": "u_123",
    "reason": "DSAR SUP-1043"
  }'

What gets deleted

An erasure resolves the selector to a concrete set of sessions, then hard-deletes them everywhere:

Operational store — the sessions and their spans and tool calls, plus every derived record keyed to them: scores, enrichment outputs, session labels, cluster memberships, root causes, topic assignments, dataset items, annotations, and ground-truth labels.
Analytics store — the same sessions, spans, tool calls, scores, and enrichment outputs.

The operational delete is the authoritative, transactional one; the analytics-store erase is best-effort so a hiccup there can’t strand a completed operational delete (a subsequent retention pass is a backstop).

“Is everything really gone?” One rollup, the hourly session-stats table, holds only aggregate counts and quantiles — no PII, no trace content. It is not touched by an erasure and ages out naturally with its own retention window. Individual subject data (anything identifying) is removed by the cascade above.

Read the erasure register

Every erasure produces durable compliance evidence directly on the Erasure tab:

Erasure register — lists every request, newest first (GET /retention/erasure). Each row shows the subject, reason, sessions affected, and status (pending → running → completed / failed). The status polls to a terminal state on its own.
Deletion manifest — expand a row (or GET /retention/erasure/{id}) to see the normalized selector, the resolved session IDs, and a per-store, per-table count of exactly what was deleted.
Audit log — every erasure request also lands an immutable entry in the audit log, independent of the register, so the who / when / why is preserved even if a register row were ever disputed.

Permissions

Erasure requires the company admin role (roles order viewer < member < admin). Members and viewers can’t open Data Governance, and the API returns 403 for the erasure endpoints. A company’s data lives in its own physically isolated storage — an erasure can never reach another tenant.

Data retention — the scheduled purge that shares this same delete cascade.
PII redaction — scrubbing sensitive values before they’re ever stored, so there’s less to erase later.
Audit log — the immutable record of erasure requests.
Members & roles — the admin role that grants access.

PII redaction FAQ