AI Memory Merges Resolve Duplicate and Clashing Facts

I merge AI memories to keep answers current - not just to cut duplicate records. My rule: check the source, scope and validity dates before choosing which fact to use. A record imported on 2 November 2026 may still describe an older fact.

I use 3 checks to guide each merge:

• Compare like with like. Separate facts, events and preferences; merge only genuine duplicates.
• Keep the history. Record sources, dates, versions and reasons for changes. Leave unresolved conflicts open for review.
• Control what gets used or removed. Release approved records for retrieval, require human approval for high-impact deletions, and test retrieval and rollback.

Newer does not always mean correct. I keep source authority, privacy rules and a traceable history at the centre of every decision.

Record Sources, Dates and Versions

Define the Memory Record Fields

After classifying records, store enough metadata to merge them safely. Give each record a claim ID, version ID, content, entity and attribute. Keep source references, passage IDs and permitted raw evidence, such as excerpts or calculations - not just generated summaries.

Include confidence, evidence status, sensitivity, scope, owner and a retention or expiry date. Use IDs to link each record to parent, superseded or disputed versions.

Keep evidence status separate from confidence. Labels such as supported, partially supported, inferred, uncertain, insufficient and conflicting describe how a claim relates to its evidence. A confidence score alone cannot tell you that.

Separate Validity Dates from Storage Dates

Use separate fields for validity start and end, observation/reporting time, and creation and update times. A late import must not make an older fact current. Leave unknown validity dates unset. Store timezone-aware timestamps internally and display clear UK dates.

Example: 2 November 2026.

Historical queries need two views: what was valid at the requested time, and what the system knew then. To keep those timestamps useful, every merge must leave a traceable version trail.

Keep a Traceable Version History

Maintain an append-only change trail within retention and deletion rules. Record the previous and replacement version IDs, the reason for the change, the policy version and the responsible agent or person. Include rejected findings and transformations.

Mark replaced versions superseded or inactive rather than deleting them immediately. Keep evidence links so the system can verify changes, answer historical queries, roll back changes and justify later duplicate removal or conflict resolution.

You Can Learn AI Agent Memory Layers | Graph RAG, Vector DB, SQLite, Hermes, Waku

Set Rules for Duplicates and Conflicts

Once source and version metadata are in place, apply merge rules in this order: normalise, rank, then classify the discrepancy.

Normalise and Classify Records Before Merging

Normalise records before comparing them. Match identity, scope, validity period and source - not wording. Count repeated imports as a single origin, and use supporting evidence only for the fields it supports.

Rank Sources to Resolve Conflicts

Set source priority for each attribute. Once authority and scope match, prefer the most recent valid timestamp for that attribute. Wording, arrival order or recency alone must never decide precedence. If the rules don't produce a clear winner, send the conflict for human review.

Distinguish Changes from Corrections

A change means the earlier fact was valid at the time. Close its validity interval and start the replacement at the documented transition date.

A correction means the earlier assertion was wrong. Link the replacement and record the reason. Every merge outcome must update the version trail.

Keep scope-specific exceptions separate. Move unresolved contradictions to a review queue and leave them there for the next retention decision.

Manage Review, Retention and Retrieval

::: @figure {Safe AI Memory Merge Workflow} :::

Set Approval Rules for Review and Deletion

Once source priority is set, approval gates control when a merge can replace older records.

Allow automatic low-risk deduplication only when checks pass and logs are saved. Use threshold-based approval for medium-risk merges. High-risk deletions need human sign-off. Critical cases need dual authorisation, identity checks, an audit trail and a rollback plan.

Give reviewers the competing sources, proposed action and affected records. Keep older records until approval is confirmed. Quarantine unknown outcomes for human review.

Build the Memory Merge Workflow

With approval rules in place, use a fixed workflow to keep unvetted records out of retrieval.

Collect records and classify each source. Then extract structured facts and normalise them. Compare validity intervals, apply precedence rules and propose either a merge or quarantine. Get the required approval, save versions and audit trail entries, then release the approved record for retrieval. Use version checks to stop concurrent writes from overwriting records.

When an external action has an uncertain outcome, check its status before changing memory:

• Confirmed completion: require a receipt or completion record.
• Failure with no effect: retry the action or overwrite the old record.
• Still in progress: allow more time.
• Unknown outcome: quarantine it.

Test Retrieval and Track Errors

After a merge, retrieval must follow approval status, version history and the query date.

Limit ordinary retrieval to approved records for the relevant date. Use a separate authorised path for historical queries. Flag unresolved conflicts for review, and check high-impact or fast-changing facts again against their authoritative source.

Test for stale recall, incorrect overwrites, lost source history, repeated ingestion, concurrent updates and rollback failures. Track these failure modes over time.

Conclusion: Safe Memory Merge Checklist

Before deployment, put auditable controls in place: merge only genuine duplicates, resolve conflicts using source authority and validity dates, retain version history, and require human approval before high-impact deletions.

Check Readiness Before Deployment

• Confirm the schema records source IDs, version links, and separate timestamps for validity and storage.
• Check merge-request idempotency keys, approval gates and the policy version that governs each decision.
• Assign a Data Owner or Privacy Lead to removal decisions. Check retention deadlines, lawful basis and legal holds. No approval overrides data protection requirements.
• Store tamper-resistant decision logs outside agent control. Record the approver’s identity, policy version, rationale and exact memory version changed.
• Set acceptance criteria for retrieval quality, conflict handling, recovery and rollback.
• Verify the requesting agent’s authority immediately before any high-impact memory change or deletion.

Specify Memory Policy and Implementation Ownership

Turn the checklist into implementation requirements. The implementation brief should cover memory policies, source-aware conflict rules, retention limits and human-review requirements. Hokstad Consulting can help define the memory policy and implementation brief. Assign decision ownership and acceptance tests before implementation begins.

FAQs