Retail journey

Your data, your rules.

Rashid, 41 · architect · Hyderabad · wants to leave the app cleanly

Rashid decides to stop using Mukodi. He wants every record gone — not buried, not aggregated. The app gives him the receipts.

Marketing claimdpdp-self-serve-erasure
Read DPDP §12 erasure Talk to us
The story · 4 scenes

Beginning to end.

Rashid, 41 · architect · Hyderabad · wants to leave the app cleanly
·Rashid decides to stop using Mukodi. He wants every record gone — not buried, not aggregated. The app gives him the receipts.
  1. Scene 01 · Withdraw the consents he no longer wants
    Rashid opens /settings → consent and switches off the four Scribe consent flags one by one. Each change is captured in the audit chain.
  2. Scene 02 · Review what Mukodi remembers
    He opens his memory ledger. Every captured fact — provenance, source turn, confidence — is listed. He deletes the ones he never wanted captured.
  3. Scene 03 · Start an account erasure
    He starts the DPDP §12 cascade with a 7-day grace window. He can stop the cascade himself, by phone-OTP, at any point during the window.
  4. Scene 04 · Receive the closure report
    On day 8, Mukodi mails him a closure report — the tables cleared, the events emitted, the hash chain link before and after. The auditor can verify the chain from outside.
Helpers on call
The stack · helpers + models

Who's actually doing the work.

Features used
DPDP §12 self-serve erasureHash-chained audit trailYour memory, your rulesProfile, sessions & delete
Honest limits

What this flow doesn't do.

  • Erasure completes within the DPDP-prescribed window after a grace period; the worker runs daily and cascades across 30+ tables.
  • Backups are retained for a regulator-aligned window before they are themselves purged; the closure report names the date of final purge.
  • Some events (audit chain rows) must survive erasure under the same DPDP regime that obliges erasure — they are pseudonymised, not deleted.
← Back to all use cases