Security
Data lifecycle and deletion
Deleting a document removes it from serving, not just from a list. The delete clears the warm copy the serving box is answering from before it removes the durable one, then writes a receipt naming every place it reached. This page is that story end to end, including the boundaries.
What we hold
Loading a document produces four things, and every one of them is covered by a delete.
| Copy | What it is |
|---|---|
| The file | Exactly what you uploaded, in the document store. |
| The extracted text | What we read out of the file, which is what the memory is built from. |
| Section descriptions | Short written summaries of the document's sections, used to route a question to the right documents. |
| The cartridge | The compiled model memory: the document's key/value cache, captured once. It is not the text, not an embedding and not a summary, and the model weights are never modified to produce it. Onboarding is read once, no training. |
The cartridge is stored in a pickle-free container, so loading one cannot execute code, and every blob is stamped with a SHA-256 that is re-verified on every load. A tampered or corrupted blob fails at the transport boundary and never reaches the model.
What a delete removes, and by when
This is the erasure timeline the API publishes, generated from the same constants the infrastructure is configured with, so the statement cannot drift from the lifecycle rules actually in force. Any signed-in user can fetch it:
curl -s https://api.engramdynamics.org/platform/erasure-timeline \
-H "Authorization: Bearer <your key>"| Tier | Where | When it goes | Worst case |
|---|---|---|---|
| Database rows | Platform database | Immediately, in the delete call. The document and document-base records, and every job and import run attached to them. | 0 days |
| The file | Document store and the worker's mirror | Removed immediately. The bucket keeps versions, so the deleted copy sits in the recycle bin and is then expired and unrecoverable. | 30 days |
| Extracted text | Document store and the worker's mirror | Removed immediately, on the same recycle-bin window. | 30 days |
| Section descriptions | Document store and the worker's mirror | The deleted document's entries go immediately. Deleting a whole document base removes the file outright, on the same window. | 30 days |
| Retrieval index | API memory | Dropped in the delete call. The document cannot be retrieved by the next query. | 0 days |
| Cartridge | Cartridge store | Deleted immediately, unless another of your document bases still uses the same content, in which case it is kept and the receipt says so. The deleted copy sits in the recycle bin and is then expired. | 30 days |
| Warm serving copy | Serving box caches and its local mirror | Purged in the delete call, before the durable copy is removed, so a delete can never leave a warm copy answering questions. A box that was offline at the time purges when it returns. | 7 days |
| Operational logs | CloudWatch | Expired on a rolling window. They record that a request happened, ids, filenames and timings, never the contents of a document. | 14 days |
| Deletion receipt | Platform database | Kept on purpose. It is the proof the deletion happened, so it outlives the data it describes. Ids and counts only, never document content. | Kept |
The order matters and it is deliberate: the warm serving copy is purged before the durable blob is removed. Done the other way round, a failure would leave a warm copy serving a document whose blob is already gone from every listing, which nothing could then find to clean up.
Deleting
Delete one document, or a whole document base:
curl -s -X DELETE https://api.engramdynamics.org/corpora/<base id>/documents/<document id> \
-H "Authorization: Bearer <your key>"
curl -s -X DELETE https://api.engramdynamics.org/corpora/<base id> \
-H "Authorization: Bearer <your key>"Both answer 204. A build in flight does not hold the delete open: the document goes and the receipt records that a build was running. A delete is never blocked by a billing state either, so leaving with your data and removing it are always available, including on a cancelled workspace.
The receipt
Every delete writes an append-only receipt you can read back, tier by tier, each with its own outcome rather than one blanket success.
curl -s https://api.engramdynamics.org/audit/deletions \
-H "Authorization: Bearer <your key>"Each tier reports ok, failed or skipped, and anything that is not ok carries the reason. A tier that quietly did nothing, because no cartridge was ever built or the file was already gone, reads as skipped with the reason rather than as a success we did not earn. The cartridge tier always accounts for all three outcomes: what was deleted, what was already missing, and what was retained because another live document base of yours still uses the same content. A reviewer can see that a retained id was intentional, not missed.
The receipt's tier names are the same names as the timeline above, so the two read against each other line for line. See Audit log for the full event catalogue.
Replacing a document
An update is held to the same guarantee as a delete. When a document changes and its memory is rebuilt, the new memory is written in place of the old one and the warm copy the serving box was answering from is purged as soon as the rebuild succeeds. The next question gets the new version, so a rebuilt document never keeps answering from the text it used to have.
An unchanged file costs no rebuild at all: re-saving a document whose words did not move is recognised as the same document and is never re-read. Documents and formats covers what counts as a change.
The boundaries, stated plainly
A reviewer will find these anyway, so here they are.
- A request already answering completes. A question that has already loaded a document's memory finishes with it, even if a delete or a rebuild lands mid-answer. That window is one answer, not a lingering exposure. The guarantee is that no new question serves the deleted document.
- The recycle bin is real. Deleting an object in a versioned bucket makes it noncurrent rather than erasing the bytes, and the lifecycle rule expires it on the window in the table. Nothing serves it in the meantime. A hard immediate wipe needs bucket-owner action.
- Backups predate the delete. A database snapshot taken before a deletion still contains those rows. The receipt proves the deletion happened; it does not reach into a prior backup.
- Nothing expires on a timer. There is no automatic TTL on your documents or their memory. A cartridge lives until an explicit, recorded deletion removes it, because auto-expiry on a timer would be a data-loss trap.
Policies and the agreement
The published policies are the Privacy Policy and the Terms of Service. The operative contract, including the deletion commitment and the processing terms, is the Service Agreement and the Data Processing Agreement your workspace accepts in the product: see Terms and DPA acceptance, which also serves both documents' full text over the API.
For a security review we maintain a written data lifecycle statement, a threat model for the serving connector and cartridge store, and a bill of materials for the shipped package. Ask us and we will send them.
Next
Audit log is where deletion receipts live alongside every other recorded action, and Exports turns them into a file for a reviewer.