feat(memory): make corrections and forgetting survive derived views, replay and import

[joshyorko]

Existing-corpus upgrade contract — September 8, 2026

This amendment is binding for #230–#235 and their Friday #20–#25 consumers. It extends the existing reconciliation/correction owner; it does not create a parallel migration framework. Future-write correctness alone does not complete these issues. Already-written Codex/Hermes memories, older conclusions/turns, transferred MemoryD records and retained imports are in scope. These are required guarantees to implement and test, not a claim that the live corpus has been repaired.

Core guarantees

Evidence and current truth are separate. Preserve the retained source's actual wording/representation, speaker/producer attribution and source time where known. Independently represent claim status (current, uncertain, corrected, withdrawn, superseded or unresolved), status reason/evidence and decision time. Reuse the evidence ledger, temporal metadata, supersession and policy seams. A correction does not rewrite what the old source said. A retained normalized summary must not be relabeled a verbatim original. Event time, claimed-valid time, import/ingestion time, reconciliation time and last independent verification are not interchangeable. Unknown values remain unknown; file mtime, migration time or an importer identity must not impersonate the missing original speaker/time.

Legacy compatibility is explicit. Publish a supported schema/record-shape and client compatibility matrix. Missing newer provenance, timestamps, lineage or classification metadata alone does not make safe, authorized old memories unusable. Retain and retrieve them with visible limitations under existing policy; do not automatically promote, delete, quarantine, relabel assistant prose as user-confirmed, or classify imports as independently verified. Unknown scope/authorization still fails closed with a reason. Malformed/unsafe content is distinct from merely incomplete legacy metadata. Map old forms through a versioned compatibility projection rather than inventing facts in place.

Retention is not recall admission. Historical/imported/other material may remain valuable evidence. Keep it searchable and eligible for bounded, relevant evidence/historical recall when permitted; separately determine whether it belongs in the current-truth pack. Known withdrawn/corrected claims cannot be presented as current. Unknown legacy currentness is uncertainty, not automatic supersession. Report withheld, omitted-for-budget, unmatched, unsupported and unknown states distinctly. Do not flood every prompt to preserve breadth or suppress an entire source class merely to simplify ranking. Historical access still respects erasure and authorization policy.

Previewable reconciliation through existing operations

1. Inventory supported pre-change shapes, scopes, stable references, bundle/source origins, existing corrections and known gaps. Work first on an isolated snapshot with a verified backup; no live scan/apply is implied by this planning issue.
2. Produce a bounded, authorized preview with affected record/reference counts and inspectable proposed field/link/status changes, recovered evidence, conflicts, unresolved cases and items deliberately left unchanged. Raw private content must not enter routine logs/public artifacts; any needed content diff is explicit, scoped and screened. Preview/cancel causes no durable DB change.
3. Bind apply to a versioned plan identity, source snapshot/DB and schema identity, permitted scope, relevant policy and expected affected revisions. Concurrent writes/corrections invalidate affected preconditions; re-preview or use a declared conflict-safe incremental plan. No silent best-effort overwrite.
4. Preserve existing handles, attribution, bundle origins and reference meaning. Add explicit versioned mappings/successor links only when necessary. No silent bulk re-keying, promotion, deletion, reclassification or timestamp refresh. fix(memory): preserve case-sensitive engineering meaning in deduplication identities #231 owns normalized-identity repair within this same path.
5. Apply transactionally in declared bounded units with durable receipts, retry idempotency and restart/resume behavior. Define partial-progress visibility and do not label a partially reconciled corpus complete. Old clients must not silently undo new status/lineage on later writes; unsupported downgrade/write combinations are explicitly blocked or read-only.
6. Provide backup/restore and reversible-plan compatibility. Rollback must not overwrite subsequent legitimate writes or revive withdrawn facts; restore to a new target and reconcile post-snapshot changes as necessary. Irreversible recovery limits are explicit, not hidden behind an 'undo' command.

Corrections across legacy and new material

Apply known, scope-authorized corrections/withdrawals through established identity, origins and evidenced derivation links across current recall, search views, cards, procedures, mirrors and export/import. Older archives, replayed events, another client's paraphrase, bundles and restore cannot make an established equivalent withdrawn claim current merely by receiving a new ID or ingestion time. Historical evidence can remain inspectable with its disposition where policy permits.

Distinguish proven match, possible equivalent, and unrelated. Unknown lineage or semantic similarity alone cannot justify silently merging/deleting records, transferring authority, or promising perfect suppression. Expose ambiguous matches for reconciliation; do not treat their recency as proof of current validity. Preserve unrelated independent evidence and namespace boundaries. Offline copies already exported cannot be remotely erased. A backup without later withdrawal records cannot know them: restore readiness must show whether reconciliation used the relevant post-backup policy and what gaps remain.

Adapter behavior and consumer rollout

#230/#232/#235 preserve supported legacy response shapes, uncertainty, temporal basis, stable references and currentness dispositions without inventing metadata or triggering migrations on startup, reconnect, capture or checkpoint. Cache/mirror compatibility and invalidation are tested, not assumed from core changes.

Friday #20 owns the integrated upgrade acceptance; #21 inspection/recall, #22 handoffs, #23 supervised consolidation, #24 transfer/restore and #25 correction/privacy each exercise old as well as new records. Consumers prove configured store identity, exact loaded provider/schema versions, reviewed preview/apply receipt and rollback readiness. They must not reset namespaces, switch to an empty DB, bulk reimport, enable auto-Dreamer, or replace live state to make tests green.

Mandatory pre-change upgrade journey

Use sanitized legacy fixtures produced by supported pre-change code/schema where possible, with declared manually constructed variants for actual known shapes. Include historical Codex/Hermes records, imported assistant prose, transferred bundle origins, missing/partial timestamps and lineage, other records, stale/current contradictions, existing withdrawals, same-named subjects across scopes and #231 collapsed identities with and without recoverable retained originals.

• Inventory and baseline both useful permitted recall and policy exclusions before the upgrade.
• Preview -> cancel: identical durable contents, references/origins and dispositions.
• Preview -> concurrent edit -> apply: stale/conflicting plan is rejected without silent overwrite.
• Preview -> apply -> retry/restart: stable references, truthful mappings/receipts, no duplicate evidence or false freshness/authority.
• Correct/withdraw old and new claims; reimport old archive, replay events, contribute a paraphrase, import/re-export a bundle, run consolidation/card rebuild: known matches stay non-current and unresolved equivalence is visible.
• Recall/search/as-of/current packs retain useful legacy breadth and other evidence within budgets; source statements and present status are distinguishable, including unknowns.
• Restore pre-change and post-change backups to new targets; reconcile later corrections where available, report missing suppression history and preserve subsequent writes.
• Report recoverable, unresolved, conflicted, unchanged and policy-withheld counts, provenance fidelity, useful legacy recall retention and unsupported shapes. No completion claim from pristine newly created records alone.

---

Outcome

A user can correct or stop recalling a claim and understand exactly what was changed, what remains retained as history, and where an old version could still exist. Later consolidation, replay or import must not silently reintroduce a known-withdrawn claim into current recall.

Priority: P1 design + adversarial acceptance. This is an identified cross-surface risk to verify, NOT a claim that every listed path is currently exploitable.

Existing foundations to preserve

At 25d617b5f08593c76d336f90b8ffd1e78f77afbd, MemoryD already has /v1/forget, archive/supersession metadata, temporal recall, the evidence ledger, derived cards, procedures, backup/restore and selective bundles. The Hermes adapter tracks only owned mirror record IDs and deliberately does not acquire deletion ownership from a dedup hit (#229). Bundle import is transactional, plan-bound and has no semantic merge (#226).

Do not replace these with a second deletion engine. Start by mapping actual dependencies and proving each gap against current source.

Required semantic distinctions

• Correction/supersession: prior evidence may remain inspectable historically but cannot masquerade as today's accepted truth.
• Archive/do-not-recall: excludes current use; does not promise physical erasure.
• Erasure request: explicitly enumerate source evidence, derived records/cards/procedures, local exports/caches and backup limitations. Do not label archive as erasure.
• Undo is allowed only for a reversible operation with a retained, authorized prior version; never fake recovery of erased bytes.

Scope

1. Preview affected record/source/derived references and counts without exposing unrelated content. Apply binds exact scope/revision; concurrent edits require fresh review.
2. Invalidate/rebuild derived current views through existing lineage; verify suppression in ordinary recall, search, cards, exports, procedures and adapter-local mirrors.
3. Define a minimal versioned withdrawal/suppression receipt or tombstone only where the current model lacks it. It must carry enough identity to reject known replay without storing the supposedly erased text.
4. Replayed observations, older archive imports and bundles must honor known destination withdrawal policy. Do not auto-overwrite conflicts or infer equivalence from fuzzy text.
5. Keep content/source identity distinct from freshness: re-import or source-ID attachment alone does not reverify a claim.
6. Report unsupported lineage/ambiguous semantic equivalents as residual risk, not proof of global forgetting.

Honest limits

An offline bundle already copied elsewhere cannot be remotely erased by the source. A backup predating a deletion cannot know about it without a newer suppression record supplied separately. Document these realities and require an explicit restore reconciliation receipt; no universal distributed-delete promise or hidden sync daemon.

Acceptance fixtures

• Fact A -> user correction B -> current recall yields B; authorized as-of inspection shows A with correct historical labels.
• Repeat A as assistant prose, re-import its old source, rerun Dreamer, and rebuild a card: no silent promotion back to current truth.
• Known withdrawn bundle origin imported again: suppressed or explicit conflict; no timestamp winner.
• Restore to a NEW isolated DB plus supplied post-backup suppression policy; distinguish unreconciled restores.
• Shared source used by two scopes: one correction/forget cannot delete another user's authorized independent record.
• Concurrent mirror replace/add, lost acknowledgement, missing mapping: no broad substring deletion or ownership adoption.
• Preview/cancel makes zero durable change; errors/receipts/logs contain only safe bounded identifiers.

Relations: #228/#233 lineage and contribution semantics, #193 scope-checked handles, #186 archive imports, #158 procedures. Memory management stays explicit and never grants an assistant arbitrary purge authority.