Proof of Forgetting makes a GDPR Article 17 erasure checkable

Proof of Forgetting is live in Dekimu Hub. An erasure under GDPR Article 17 now ends in three signed records: a destruction receipt, a non-inclusion proof against a signed roster of the subjects the workspace still holds, and a model-disposition receipt that states what happened to the subject's data in any model trained on it. The destruction receipt verifies at verify.dekimu.com, and the wire specification for the format is being published in the anchors-spec repository at github.com/dekimuhq/anchors-spec today.

Three records, one claim

The destruction receipt, forget.destruction.v1, is an Ed25519 signature over the subject's hashed key id, the id of the key authority that performed the destruction, the time, and two roster roots: the one in which the subject was present and the one in which it is absent. Verification recomputes the signed view, so a tampered field invalidates the signature. The subject appears only as a hash, never as a raw identifier, and the destroyed key never appears at all.

The non-inclusion proof comes from the roster: a sorted Merkle tree of active subjects whose leaves commit consecutive pairs of neighbouring values. Proving a subject is absent is one ordinary inclusion proof plus a check that the subject falls strictly between the pair, so adjacency is intrinsic to the leaf and no leaf index has to be trusted. The signed root carries the leaf count and the previous root, which is what stops a roster from being quietly truncated or rolled back.

The model-disposition receipt, forget.model-disposition.v1, binds to the destruction claim and records one of four dispositions for the subject's data in trained models: not trained, retrained, unlearned, or held but excluded from training by a documented filter. Retrained and unlearned are only accepted with training-set roots before and after removal, so the claim with the most weight carries the most evidence.

Erasure by key destruction, not by a delete query

Each subject's personal data is encrypted under its own random 256-bit key with AES-256-GCM. The bulky ciphertext may live anywhere, in backups, replicas or logs. Only the small per-subject key sits in a retention-tight registry, wrapped under a workspace master key that is never destroyed and never appears in a receipt. Erasure deletes that one registry row. The key is gone, and the ciphertext, wherever copies live, is permanently unreconstructable. One operational invariant is load-bearing and printed on the package: the registry must be the single, non-resurrectable copy of the wrapped key, so it is excluded from long-window backups. The ciphertext may be backed up freely; it is dead once the key row is gone.

What it proves and what it does not

The pair proves three things an auditor can check for themselves: an erasure event occurred at a specific time under a named key authority; the subject is absent from the current signed roster; and the roster was not truncated or rolled back. It does not prove that every ciphertext copy was physically located and deleted, because crypto-shred makes copies unreadable rather than hunting them down. It does not cover data the workspace never held or data that left through a third party. And it is only as strong as the backup discipline around the key registry. Checking the receipt without the non-inclusion proof would treat a logged deletion as a demonstrated one, which is why Hub emits both.

A receipt on its own says a deletion was logged. A receipt plus a proof of absence is something an auditor can check without taking anyone's word for it.

The cryptography is deliberately boring: AES-256-GCM, Ed25519 and a sorted Merkle tree, nothing novel. The composition is under external security review, which is pending. Proof of Forgetting is a compliance-management capability, not legal advice; it evidences erasure for the data a Hub workspace manages, and legal review of your own Article 17 process is recommended.

Open source at Dekimu

Everything Dekimu publishes as open source now lives on one page, dekimu.com/open-source: the Anchored Receipts specification (anchors-spec, CC0) and the append-only anchors-trusted-issuers-chain, the dekimu-mcp server and the agents.txt package on npm, regulation-as-code (legal obligations as typed predicates over an evidence corpus), and claude-memory (decaying file-based memory for Claude Code). All of it is MIT, Apache-2.0 or CC0; all of it interoperates with Dekimu Hub as the reference implementation; and verify.dekimu.com is the public verifier for the receipts Hub issues.