Erase a subject (Article 17)

Erasing a subject in ScaiLog is a cryptographic operation, not a search-and- delete. ScaiLog stored every one of the subject's PI fields encrypted under a per-subject data-encryption key (DEK); erasure destroys that key. With the key gone, the ciphertext is unrecoverable wherever it was ever written — no need to find and overwrite each row. This needs the dpo capability and is irreversible.

Run the erasure#

The CLI prompts for confirmation unless you pass --confirm. It reports how many entries were tombstoned, the receipt id, and the absolute_after date.

bash
scailog erase usr_8842 --confirm
# => erased — 1 entries tombstoned, receipt 01J…, absolute_after 2026-…Z

The equivalent API call requires confirm: true in the body:

http
POST /v1/erase
Authorization: Bearer <dpo-capable key>
Content-Type: application/json

{ "tenant": "default", "subject": "usr_8842", "confirm": true, "mode": "tombstone" }

Cryptographic erasure: the DEK is destroyed#

The core of erasure is destroying the subject's DEK. Because PI was only ever persisted encrypted under that DEK, destroying it makes every encrypted PI field for that subject permanently undecryptable — fleet-wide, including any copies in downstream SQLite files, because none of them hold the key. This is why ScaiLog can promise erasure in Phase 1 without a distributed delete job. After erasure, a DSAR for the subject returns subject_erased: true and empty pi_values.

Tombstone mode vs delete mode#

Erasure has two modes. Default is tombstone; choose with --mode.

tombstone (default) keeps the log entries for audit and integrity but marks them erased. The encrypted PI is already unreadable (its DEK is gone), and any plaintext keep-action PI is additionally scrubbed, since crypto- shredding only covers encrypted fields.
delete removes the subject's entries outright. The receipt reports the count under entries_deleted instead of entries_tombstoned.

bash
scailog erase usr_8842 --confirm --mode delete

The signed erasure receipt#

Every erasure produces an Ed25519-signed receipt — your evidence that the Article 17 request was executed. The receipt records:

Field	Meaning
`receipt_id`	ULID for this receipt
`type`	`"erasure"`
`tenant`, `subject`	who was erased
`requested_by`	the key id that ran it
`requested_at`	when the request was received
`key_destroyed_at`	when the DEK was destroyed
`entries_tombstoned` / `entries_deleted`	count, per mode
`erasure_mode`	`tombstone` or `delete`
`absolute_after`	`key_destroyed_at` + the configured keymap-backup retention (default 7 days) — after this, even key backups are gone
`signature`	Ed25519 signature block with `key_id` + public key

Fetch a stored receipt again at GET /v1/receipts/{receipt_id}, and verify any receipt offline the same way as a DSAR report:

bash
scailog report-key verify receipt.json

Idempotency and late-arriving PI#

Erasure is idempotent: re-erasing an already-erased subject returns the original receipt unchanged rather than minting a new zero-count one, so retries and duplicate requests are safe.

ScaiLog also protects against PI that arrives after erasure. If a new log entry comes in naming an erased subject, ScaiLog refuses to mint a fresh DEK for them; the PI field is redacted server-side to [REDACTED:<pi_type>] and recorded with the action redact_erased, so the entry is stored PI-free instead of silently resurrecting the subject's data.