Local synthetic demonstration

Remove key access.
Keep the erasure record.

Destroying a subject key removes access to the private object through the current wrapped-key custody. The original proof survives. A separate receipt records the key destruction.

Legal hold takes precedence. This demo checks it when preparing erasure and again at confirmation, before destroying the key.

Development signer means integrity under a published dev key and no independently trusted time.

Try subject erasure

Create a fresh synthetic subject. Its private object is empty; no private content is displayed.

Evidence that survives

Private data availabilityNo record yet

Create a synthetic record to begin.

Original decision receiptAwaiting a record

Verification checks the original envelope, chain link, inclusion proof and development signature.

Key destruction receiptNo erasure requested

Erasure remains pending until its separate control receipt is sealed at the next minute boundary.

Green means the shared verifier passed under the published development key pin. Development signer means integrity under a published dev key and no independently trusted time.

What key destruction means here

The application removes the active wrapped subject key, ending access to the private object through that custody. Ciphertext, envelope hashes, chain links and sealed roots stay intact. New decisions cannot reuse the erased subject.

A two-step confirmation

Prepare the request, then confirm the displayed phrase before it expires. An active legal hold blocks either step. This is a two-step interaction; a separate second-person approval is Roadmap.

Derivatives are inventoried, and disposed of or reported, before the receipt seals

Destroying a key does not remove plaintext from an embedding, snippet, summary, cache or exported pack held elsewhere. Every such artifact is registered when it is created, and the erasure engine purges or re-keys each registered one before the shred receipt seals. An artifact readable only under the subject key goes with the key, in the same transaction. For an artifact held elsewhere, this application records the holder report of a purge or a re-key; it did not perform the deletion and does not claim it. Search access revocation and index catch-up must be qualified separately before a search service launches.

The current table is retained, and historical copies are separate again

The record rows stay. Their sealed public fields, envelope hashes and chain positions are unchanged and still served byte for byte, and the stored ciphertext is still there and is no longer readable. Backups, database history, process memory, exported copies and other key copies are governed separately, and nothing done here reaches them. Iceberg snapshots and physical compaction are Roadmap and require their own retention and cleanup policy.

This demonstration does not establish physical disk erasure or destruction of every key copy. Its receipt records the local key-custody action; it cannot prove every derivative or historical copy was removed. Legal hold and the handling of retained copies must be reviewed for the intended workflow.

Understand offline verification