Privacy and redaction

Retained, redacted, irrecoverable

Everything is retained by default: the row, its content, identifiers, links and timestamps. A redacted row keeps its identifiers, type, timestamps, links, scores and breakdowns but its content columns hold a fixed marker, and a ledger records when, why, by whom, under which policy and a hash of what was removed. Irrecoverable means no copy remains anywhere the system controls: live tables, stored snapshot archives and future exports. Rows in cognitive history are never deleted; a redacted row is the strongest erasure the system performs, and it is deliberately visible as one.

How it differs

Most systems offer deletion, which destroys provenance along with content, or nothing at all. Noema separates the two. After a redaction an operator can still see that a belief existed, how strong it was, which families supported it, what later depended on it and which replay steps touched it; what they cannot see is the words. The ledger's content hash lets a later holder of the original prove what was removed without the system retaining it. The redaction itself is an event in the mind's history, so the record that something was removed survives even a cascade.

Guarantees and their edge

Redaction is administrator-only, protected against cross-site request forgery, audited, and performed by a single database function that runs under a transaction-local flag the application never sets; it can update content columns and nothing else, and cannot delete. Stored snapshots are scrubbed and re-signed. Replays skip a redacted stimulus and label the step rather than invent content. The guarantee ends at the system's own storage: backups, exports and replicas taken before a redaction still hold the content, as does anything already sent to a model provider. Cryptographic erasure was considered and not adopted because retrieval, search, contradiction detection, the interface and replay all read these columns in clear; it remains the right tool for backups, which Noema does not manage.

Noema's history is append-only because provenance, replay and forensic reconstruction depend on it. Personal or sensitive content can nevertheless need to be removed. This page defines exactly what the system can and cannot do about that.

Definitions

The redaction path

POST /api/v1/minds/{mind}/redactions (administrators; also the mind's Redactions page) takes a kind (event, memory, message, llm_call, belief, assertion), an id, a reason, an optional policy name and a cascade flag. It runs in one transaction:

1. The row's content is hashed and a redactions ledger row is written (append-only, unique per target).
2. noema_redact() replaces the content columns. It is the only code path that may update an append-only table: it sets a transaction-local flag that the append-only trigger checks, touches nothing but content and the redaction bookkeeping, and cannot delete. The function is SECURITY DEFINER, revoked from PUBLIC, and the application never sets the flag itself.
3. A redaction event is appended to the mind's history naming the target, the policy and the hash, never the content.
4. With cascade, rows derived from the target are redacted too and linked to the primary ledger row: for an event, the episodes encoded from it, the message it carried and its reply, the model calls that worded them, the assertions made in it and the beliefs whose evidence roots at it; for each redacted row, the events that quote it (a perception, an encoding, a belief creation). Redaction events are never cascaded, so the record of redaction survives.
5. Stored snapshot archives of the mind are scrubbed of the same rows, the archive records the redacted ids, and its checksum is recomputed; archives still validate.
6. The action is written to the audit log.

What each kind replaces: events lose summary, payload and free-text metadata (structural keys such as conversation, message, cycle and belief ids are kept); memories lose content and detail; messages lose content and intent; model calls lose request and response; beliefs lose proposition and detail and their versions, evidence notes and alternatives; assertions lose proposition, context and notes. Scores, statuses, confidence breakdown numbers, families, links and timestamps are untouched, so the epistemic shape of the history remains inspectable: an operator can still see that a belief existed, how strong it was, what supported it and what later depended on it.

Why not cryptographic erasure

Envelope-encrypting payloads with a per-row or per-subject key and destroying the key on erasure was considered and not adopted in this release. Full-text search, semantic retrieval, contradiction detection, the interface and replay all read these columns in clear; per-row decryption on every read would touch every code path and index, and search over ciphertext would need either plaintext shadow columns (defeating the purpose) or a redesign of retrieval. The marker-and-hash approach achieves the same end state for the live database and stored archives with a small, auditable surface. Cryptographic erasure remains the right answer for backups, which this system does not manage: encrypt backups under keys you can retire, and treat a redaction as a signal to rotate them on your retention schedule.

Threat model

Retention

There is no automatic retention purge. Retention is an operator policy applied through the redaction path with a policy name, so every removal is attributable. A future bulk policy runner would use the same function and ledger.