forget_subject
Erase all data about a subject per GDPR Article 17, including linked references, and return a deletion receipt. Preview with dry run; use exact mode to avoid deleting colliding subjects.
Instructions
Right-to-erasure by SUBJECT (GDPR Art.17 / DSR): delete every memory about subject AND scrub its id from
survivors' links/supersession pointers, so it can't resurface via recall or consolidation. basis records the
legal/operational reason. Returns a receipt (erased count, ids, scrubbed_links, tombstones, request_id,
coverage, residue_in_store) you can keep as evidence.
RUN IT WITH dry_run=True FIRST. This cascades through inherited lineage, so it commonly erases more than the
records that name the subject: the preview returns {would_erase, direct, inherited, sample, also_carrying}
and changes nothing. inherited is the count you cannot predict, and also_carrying names the OTHER subjects
whose data goes down with this request — one erasure is quietly several more often than not.
If the call raises AmbiguousSubject, the subject you passed canonicalizes to the same key as a DIFFERENT
source in the store (e.g. two people under one host: crm.example.com/alice and crm.example.com/bob), so
erasing would delete a third party's records. Read the message, confirm which subject is meant, and then
choose: exact=True erases only the records whose RAW source string is this subject (plus their lineage)
and LEAVES the colliding subject alone — prefer it, it completes the DSAR without touching anyone else.
allow_ambiguous=True erases every colliding subject together, so pass it only if you really mean that.
This surface used to offer allow_ambiguous alone and this text named it as THE answer, which pointed the
caller at the over-deleting half of the choice; measured, that erased a third party's record where
exact=True kept it. Collisions are not rare: canonicalisation is host/collection level, so
'employee/1001' and 'employee/1002' share a canonical form.
authorized_by (the authorising principal's public key) and authorization (their signature over
erasure_challenge(subject, request_id)) are recorded in the tombstone's auth field — the Art.30 record
of WHO authorised the deletion. Neither was on this surface, so every MCP erasure was unattributed.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | ||
| exact | No | ||
| dry_run | No | ||
| subject | Yes | ||
| request_id | No | ||
| authorization | No | ||
| authorized_by | No | ||
| allow_ambiguous | No |