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

Deletion requests

Under the DPDP Act, Data Principals may have a right to erasure of personal data (subject to the Act, rules, and lawful retention). Operationally, honouring erasure is more than deleting one row: identity verification, multi-system action, and documentation.

Erasure models this as a Rights case with verification, execution jobs, and honest outcomes. v1 fulfillment type: DELETE only.

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 cases start

Path	How it works
Public intake	Subject starts OTP flow; case 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; map-backed systems need Data Map DELETE entities).
Durable job rights.delete is enqueued.
Worker claims the job and runs against each enabled System.
Activity and Evidence record outcomes.

Without a worker, jobs stay pending. Without connected Systems and maps, Erasure cannot invent deletes.

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 recorded

Product setup required

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

Guides: Handle a deletion request.

Not yet productized as full rights types

ACCESS and CORRECT request types are not first-class product types today. Do not market them as live.

What to do next

Evidence · What Erasure does not solve

Deletion requests (DPDP)