Can we prove it?
Forget a customer without rewriting history. Crypto-shred destroys the subject’s encryption key — the data becomes unrecoverable, but the audit chain proving the erasure remains.
GDPR Article 17 says the personal data has to be gone. Your regulator says the record of the erasure has to still be there. Most stacks pick one or the other. Here, you get both from a single procedure call — and a cryptographic receipt an auditor can verify without ever seeing the original data.
subject:42, before and after. On the left, a live subject — encrypted node payloads, a live subject key in the KeyProvider, a hash-chained audit log. On the right, after db.destroySubjectKey: the ciphertexts are still on disk, but the key that could decrypt them is gone. The chain is untouched — and now carries one extra link: the erasure receipt.
The ciphertext bytes are still on disk — the store has no way to reach in and rewrite them, and doing so would break every hash after that point. But the key that turned those bytes into meaning is void. What remains is a receipt saying “subject:42 was shredded at 14:32:18Z” — hash-chained to the last live head. The regulator can verify the erasure. Nobody can decrypt what was erased.
Export. Destroy. Prove.
A right-to-be-forgotten request is a workflow, not an incantation. First you owe the subject a copy of what you held on them (Article 20). Then you destroy the key (Article 17). Then you hand your regulator a receipt they can verify without seeing the data. Three procedure calls — each with a signature this page has verified against the running engine.
Answer the portability request first.
Before you destroy anything, give the subject their data. db.subjectExport walks the whole subject: the node, its edges, and the full property history. One row per artifact.
Shred the key. Content becomes unrecoverable.
The KeyProvider entry for subject:42 is destroyed. The ciphertexts on disk are unchanged — and untouched. Without the key there is no way to turn them back into meaning.
Hand the auditor a receipt.
db.proveErasure replays the erasure receipt and re-verifies the chain. chainStatus is either verified or it names the event that broke.
Two articles. Two primitives. One procedure call each.
The reason most legal teams cannot answer “what would it take to erase this subject?” is that Article 17 and Article 20 are usually two separate integrations — and the audit trail is a third. Here they map one-to-one onto engine procedures, and the receipt is the audit trail.
“Give me my data.”
The subject has the right to a copy of the personal data you hold on them, in a structured, commonly used, machine-readable format. In InvariantDB that’s one procedure walking the subject’s node, edges, and complete property history — one row per artifact, ready to serialize.
db.subjectExport(“subject:42”)“Forget me.”
The subject has the right to have their personal data erased. Crypto-shredding satisfies this without rewriting a single stored byte: destroy the key, the ciphertext becomes unrecoverable, and the erasure itself becomes a hash-chained event you can prove happened.
db.destroySubjectKey(“subject:42”)The audit chain is where the two articles reconcile. Article 17 wants the data gone. Regulators, courts, and internal audit want the record of what happened preserved. The chain preserves the fact of the erasure — not the data. The receipt tells you a subject was shredded, when, by whom, and how it hashes into the ledger. It doesn’t tell you what was in the data. It can’t — nobody can.
The data is gone. The proof it was there stays.
Crypto-shred is not just a delete-with-extra-steps. It preserves the fact that a subject existed, the fact that they were erased, and a cryptographic receipt that any auditor can re-verify — without ever needing to see the data itself.
The last live head is anchored. Before shredding, the audit chain has a head hash — call it event-8871. anchorHistorySeq and anchorHistoryHash in the receipt point straight at it.
The receipt is a chain link. The shred event itself gets hashed into the chain. ownChainHash is the hash of the receipt row — the audit chain now extends by exactly one link, pointing back at the anchor.
An auditor can re-verify offline. chainStatus = verified means the receipt’s anchorHistoryHash matches what’s in the log at anchorHistorySeq, and ownChainHash is what the row hashes to. If anything upstream was tampered with, chainStatus tells you what broke.
anchorHistoryHash. Re-hash the receipt row → matches ownChainHash. Article 17 satisfied; audit satisfied; the underlying content stays unrecoverable.See the GDPR compliance surface.
Article 17. Article 20. The audit chain and DPA in one place. What ships in the box, what you have to configure, what your regulator sees.