Forgetting with proof

Deletion is a tombstone

Delete erases the content, its tags, source and text hash but keeps the row and the chained entry — so deletion itself is provable.

What happens on DELETE

• text becomes the empty string and terms becomes []; term_count becomes 0.
• tags becomes [], source and text_sha256 are cleared (since 2026-11-02: a kept hash let short text such as an e-mail address be guessed back).
• The database runs with secure_delete and the write-ahead log is checkpointed and truncated, so the erased bytes leave the files on disk; the response says erased_from_disk.
• status becomes deleted and deleted_at is set.
• The view returned by GET reports text: null — the erased content is never re-exposed.
• A chained forget entry is appended.
• The row survives so that *the fact that a memory existed and was deleted* remains provable.

Why not a row delete

A hard delete destroys the evidence that would let anyone check whether a deletion was legitimate. It also makes “was this fact ever stored?” unanswerable, which is exactly the question an incident review asks. The tombstone keeps the proof and drops the content.

If your threat model requires cryptographic erasure of the content, store the text encrypted with a per-memory key and destroy the key on delete; AETHER-33 does not do that today, and should not be described as if it did.

Expiry versus deletion

ttl_seconds sets expires_at. An expired memory is excluded from recall but is not tombstoned: it is still addressable by id and still has its text. This distinction matters — expiry is a visibility rule, deletion is an erasure. They are audited separately.

What the tombstone still holds

The row keeps its memory_id, space, status, timestamps and its chained log entry. Since 2026-11-02 it no longer keeps text_sha256, tags or source, and each log entry's payload_sha256 covers a random value that is never stored, so the audit log cannot be used to confirm a guess of the erased text either. Copies outside AETHER-33 (backups, exports, the agent's own context) are yours to erase; this is engineering support for erasure requests, not legal advice.