The Right to Be Forgotten Meets the Knowledge Graph

Deleting a row from a database is a solved problem. Deleting a fact that has been summarised, embedded, reflected on, and re-derived across a graph is not — and that is the shape of a deletion request in 2026.

The request that breaks naive deletion

A data subject asks you to delete everything about them. In a flat vector store the operation is crude but tractable: find the chunks, drop them. In a knowledge graph the entity node is the easy part. The hard part is everything derived from it — summaries that mention the person, reflections an agent generated, edges whose weight depended on their contribution, embeddings fitted on their triples, and the key–value cache that still holds the raw text mid-inference.

This is not a hypothetical gap. Work on execution-state unlearning shows that today's "forget" usually deletes plaintext and leaves the derived artifacts intact. The record disappears from the graph and survives in everything the graph taught the model.

Parameter–memory backflow

A subtler trap is that deleting memory and deleting parameters are not independent. A 2026 result on agent unlearning names the failure parameter–memory backflow: even after you drop a memory and unlearn the parameters, retrieval can reactivate parametric remnants, while memory artifacts can reintroduce content you thought was gone. The two stores recontaminate each other in a closed loop.

The practical consequence is that forgetting must be synchronised: memory first, then parameters, in one atomic operation, with neither path left able to revive the other.

Model memory as a dependency graph, then delete the closure

If remembering is derivation, forgetting is dependency closure. Model agent memory as a directed graph G = (V, E) where the vertices are raw memories, derived summaries, reflections, and graph entities, and the edges are derivation relations — this summary was built from those episodes, this edge was induced by that fact.

To forget a target, you must delete everything whose derivation depends on it, not just the node itself.

// The true deletion set: every derived artifact downstream of one memory.
MATCH (target:Memory {subject: $subject})
MATCH (target)<-[:DERIVED_FROM*1..]-(derived)
RETURN DISTINCT derived

Two mechanisms make this safe. A reference counter r(v) tracks how many live artifacts still depend on a node, so you only drop it when the count reaches zero. A persistent blocklist B sits at the retrieval boundary — an O(1) membership check on every fetch — so an artifact that escaped deletion cannot be pulled back into context. Deletion at the boundary, not just in the store, is what makes the guarantee hold under retrieval.

Erasure is not refusal

The most common failure is to confuse forgetting with refusal. In the first benchmark built from knowledge-graph triples, models scored a perfect 1.000 on "unlearning" while actually just 71.5% of the time — the knowledge was still there, only the polite path to it was blocked. Probe with a paraphrase and the model answers.