Forget & Deletion

forget tombstones a scope of semantic memory so it stops appearing in recall and is purged from the semantic projection. It’s the right-to-be-forgotten / correction path. Approval-gated for agent (API-key) callers: returns 202 with a pending approval that an owner approves; session owners execute immediately.

string

required

One of: company, knowledge_base, document, episode, entity, claim, source.

string

required

Identifier for the scope (e.g. a document id, entity name, or the company id).

string

Optional KB id.

string

Optional reason recorded on the tombstone.

curl -X POST https://api.usenaive.ai/v1/brain/forget \
  -H "Authorization: Bearer nv_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "scope": "entity", "scope_ref": "Acme Corp", "reason": "customer erasure request" }'

{ "forgotten": true, "scope": "entity", "scope_ref": "Acme Corp" }

{ "status": "pending_approval", "approval": { "id": "appr-uuid", "action_type": "brain.forget" } }

How deletion stays provable

A tombstone is written first, so reads immediately filter the scope even before the async projection purge completes (the semantic read path falls back to the tombstone-filtered Postgres spine while a delete is in flight).
The projection worker then purges the scope from the GBrain engine and records a deletion proof.
Company/KB/document deletes additionally return a DeletionReceipt (provider_confirmed vs verified) — see overview.

Overview

Endpoints

Forget & Deletion

How deletion stays provable

​How deletion stays provable

How deletion stays provable