How Erasure runs erasure requests as verified cases and jobs across real systems.

Deletion requests

Honouring erasure is more than deleting one row. Erasure models a Rights case with verification, execution jobs, and honest outcomes.

Lifecycle

OPEN (+ verification)
   │ start (needs VERIFIED + readiness)
   ▼
IN_PROGRESS ── worker runs Systems ──► COMPLETED
   │                                    or FAILED
   └── cancel ──────────────────────► CANCELLED

Verification (UNVERIFIED / VERIFIED / FAILED) is tracked separately from case status.

How subjects and operators start cases

Path	How it works
Public intake	Subject starts OTP flow; case is created only after OTP succeeds (VERIFIED)
Operator	Console creates a case; operator may mark verified (trust-the-operator, not OTP proof)

Execution

Start requires VERIFIED + start readiness (enabled systems; SQL systems need Data Map DELETE entities).
A durable job is enqueued (rights.delete).
A worker claims the job and runs against each enabled System.
Timeline and Evidence record what happened.

Without a worker, jobs stay pending.

Honesty about outcomes

Outcome	Meaning
Completed	Fulfilment path finished successfully for enabled systems
Failed	Permanent or exhausted failure—see timeline
Partial	Some systems OK, some not—shown honestly where product records it

Erasure does not invent deletes for systems you never connected.

Product setup required

Connect Systems.
Build Data Maps for SQL.
Resolve operational readiness.
Run the case.
Export evidence.

Guides: Handle a deletion request · Connect PostgreSQL.

What to do next

Evidence · Operational checklist

Deletion requests (DPDP)