ADD-only extraction in v3 may surface stale/contradictory facts for time-sensitive attributes

[NDNM1408]

Component

Core / Python SDK

Description

Summary
After upgrading OSS to v3, the extraction pipeline is single-pass ADD-only — add() no longer emits UPDATE / DELETE events. For facts representing a mutable state (e.g. current employer, current city, relationship status), this means contradictory memories accumulate over time instead of the newer fact superseding the older one.

Scenario
3 months ago, user says: "I work at Company A" → memory stored: Works at Company A.
Today, user says: "I now work at Company B" → memory stored: Works at Company B.
Both memories coexist. On a later query like "Where does the user work?", retrieval (semantic + BM25 + entity matching) can return Company A as a top-ranked candidate because the scoring signals don't incorporate recency.

[PratikRai0101]

hey @kartik-mem0, thanks for pointing me to that research paper!

since my previous CRUD approach was the wrong fit for what you're building and as i realized mem0 is moving toward an append only graph memory architecture, deleting historical data doesn't make sense.

so went back to solve this stale facts issue using your append only philosophy.
I have oppened a draft PR. This PR introduces a soft supersede mechanism instead of erasures:
when UPDATE or DELETE fires, we add the new memory but don't touch the old one. we just flip metadata flags: "is_active": false and "superseded

review the approach and tell me if it fits right or are there any required changes.

[hegu-1]

This is a useful concrete example of a broader failure mode I keep running into with long-term agent memory: memory systems improve recall, but they often do not preserve enough provenance to decide whether a fact is current, stale, superseded, user-owned, or agent-inferred.

For mutable attributes like employer, city, relationship status, shipping address, current project, etc., I think the missing primitive is not only recency weighting. It is a small provenance/supersession layer:

• source-tag each memory update (user said, agent inferred, imported, system policy)
• record the observation time separately from processing time
• represent UPDATE as a supersession edge, not just another ADD
• distinguish durable identity facts from mutable state
• expose why a memory was selected, not just that it matched semantically

Otherwise the system can retrieve a true historical fact and still behave incorrectly because it cannot tell that the fact has been superseded.

I wrote a related architecture note around this broader class of problems here:
https://github.com/hegu-1/coevolution-kernel

The framing is: "long-term memory without provenance becomes silent drift." This issue feels like a very concrete instance of that.

[trivediakshay2012]

@NDNM1408 - your scenario in #4956 maps cleanly to a problem space I've been working on (a memory layer with explicit supersession as a first-class write, not retrieval-time recency hacks). I don't want to derail this thread with a pitch - would you be open to a quick offline chat? Twitter, LinkedIn, or email all work. Happy to share what we've built and get your technical read.

-Akshay (aurra.us)

[hegu-1]

@trivediakshay2012 Thanks Akshay — yes, happy to chat.

I took a look at Aurra. The "memory with receipts" / audit-trail framing is very close to the distinction I care about here: explicit supersession as a first-class write, rather than trying to patch stale memory at retrieval time with recency heuristics.

I’d be especially interested in how you model supersession edges, source attribution, and whether promotion from contextual memory to durable/core memory requires human ratification.

Email works best for me: liiyyuanil0401@gmail.com

Looking forward to comparing notes.