Corrections must change future retrieval

A correction path should be available from the interface where the memory appears. The user needs to identify the wrong value, provide or select the replacement, and see which source or authority is required for that type of record.

Do not edit history silently. Mark the old record superseded or invalid, create the corrected record, link the two and record who made the change. Future current-state retrieval excludes the old value, while historical review can still explain why it appeared in earlier tasks.

Deletion is different from correction. Privacy or retention rules may require removal of the record, source content and derived indexes. Track derived artefacts such as embeddings, caches and summaries so deletion can reach them. A tombstone may retain a minimal non-sensitive identifier to prevent accidental re-ingestion, provided the retention policy permits it.

Source changes need propagation. If a document is replaced or its access narrows, identify memories derived from it. They may need revalidation, restricted scope or invalidation. A source link that no longer resolves should reduce trust and create maintenance work rather than remain an invisible dead reference.

Allow users to challenge inferred preferences without proving a replacement. Removing an inference can be the correct result. The system should not immediately recreate it from the same old evidence, so keep a scoped suppression record or update the extraction policy.

Corrections also need to clear caches and active-session context where practical. Updating the durable store while an agent continues with a cached old value creates a confusing delay. Return a correction version that clients can compare before consequential work.