Tombstone a node (never a physical delete of the node row). Idempotent.This is the erasure verb: forget must make the node’s
content unrecoverable through the flagship read paths (POST /v1/search and
/v1/retrieve’s default hybrid path both read memory_chunks). So besides
tombstoning the node (deleted_at/deleted_by, auditable, structurally
undeletable for a 30-day window), it also erases the node’s memory_chunks,
which is where the retrievable/searchable text lives. Erasing the content
(not merely soft-hiding it) is the correct semantics for a PII/erasure verb
and does not depend on shared read paths threading a tombstone predicate.The node row itself stays as a tombstone (structure + audit) for 30 days, so
POST /v1/graph/nodes/{id}/undelete restores its graph position but not its
content (content erasure is intentional). After the window the tombstone is
physically purged. Graph-read, recall, retrieve, the dashboard knowledge
graph and brain training all filter the tombstone, so a forgotten node stops
surfacing everywhere, not only here. A node not owned by the effective
subject is 404; re-deleting an already-tombstoned node is a no-op success.
This route requires the memory:forget scope. A key carrying write also qualifies.A missing or invalid credential returns 401 authentication_error. A valid credential without the scope returns 403 permission_denied, and the problem body names the exact scope required.
Forget erases content and tombstones structure. The node’s stored chunks are destroyed, which is what removes it from search and retrieval. The node row itself survives as a tombstone for 30 days for audit and undelete, then is physically purged.
Undelete restores position, never content. That asymmetry is deliberate: this is an erasure verb.
memory:forget is a narrower grant than graph:write. A key minted to edit the graph cannot destroy content. A write key holds both.