Faithfulness check before memory write , interested in contributing a pluggable verification hook

[DataAlchmesit]

Component

Python SDK

Description

I've been building a local faithfulness-checking library (MiniEval - (https://github.com/DataAlchmesit/MiniEval-pro), MIT licensed, 'pip install minieval-pro' and ran into a failure mode I think is worth raising here.

The problem: When an NLI-style faithfulness model checks a candidate fact against its source, it has no notion of whose fact it is. Given a source like "my brother is a lawyer" and a candidate "the user is a lawyer," a faithfulness model can score that as ~99% entailed. The professions match, so it entails, even though the fact is misattributed. I've tested this specifically and built two guards against it (possessive/reported-speech detection, and a relatedness check for cases where an unrelated pair gets forced into a false "contradiction" by the NLI model).

I looked through mem0/memory/main.py to understand where this would actually apply, and found the extraction happens in '_add_to_vector_store', a single LLM call parses extracted_memories from the conversation (around the "V3 PHASED BATCH PIPELINE" section), which then go through hashing/dedup and batch insert. That gap between "extraction parsed" and "batch persist" looks like the natural place a verification step could sit, but I want to ask rather than assume:

Is there already a supported way to hook into or intercept the extraction result before it's persisted , a callback, a config option, an extension point I'm missing?
If not, would a maintainer be open to discussing what a minimal, opt-in verification hook might look like? I'd rather design it with your input than build something against a private method (_add_to_vector_store) that could break on your next refactor.

To be clear about scope: I'm not proposing MiniEval become a dependency or that Mem0 adopt any particular faithfulness model. I'm asking whether an extension point for this class of check (verify before persist) is something you'd want, and if so, what shape it should take on your side.

Happy to share the specific test cases I've built (including ones where my own approach still fails, documented honestly) if useful context for the discussion.

AI Assistance

No AI involved, this is a need I hit myself

[modelpath-dev]

I will take this issue. Please assign it to me.

The enhancement involves adding a verification hook in the Python SDK before writing to memory. The function _add_to_vector_store in mem0/memory/main.py seems to be the right place for this. I will inspect how extraction results are currently processed and propose a small, pluggable hook to verify data before it is persisted. I will ensure the change is minimal and opt-in.

[DataAlchmesit]

I will take this issue. Please assign it to me.

The enhancement involves adding a verification hook in the Python SDK before writing to memory. The function _add_to_vector_store in mem0/memory/main.py seems to be the right place for this. I will inspect how extraction results are currently processed and propose a small, pluggable hook to verify data before it is persisted. I will ensure the change is minimal and opt-in.

Thanks for offering to help, @modelpath-dev! I'm actually already working on the PR implementation and design for this verification hook. I'll share a draft PR shortly and would welcome your review/feedback on it!

[sattyamjjain]

Not after the issue; you have the PR. One data point for the design.

The misattribution case you hit is the write-side half of something that got measured last week. arXiv:2609.08258 tested five agent-memory systems and found none of them enforce revocation at retrieval: a fact marked invalid still comes back, still outranks its replacement, and still drives the action. https://arxiv.org/abs/2609.08258

Same root cause as yours. A memory record carries no enforceable statement about where it came from or who it is about, so both the write check and the retrieval check are guessing from text. If the hook only validates entailment at write time, the retrieval half stays open.

What worked for me was making provenance a typed field on the record instead of a boundary check. Who wrote it, under what capability, in what session- all part of the row and revocable by the principal afterwards. Then the write hook is one consumer of that field rather than the only place it is enforced, and "my brother" versus "the user" is a subject attribute you can test against, not an entailment score you have to trust.

Design notes, if useful: https://github.com/sattyamjjain/mnemo. The opt-in hook at _add_to_vector_store still sounds like the right place to me.

[DataAlchmesit]

Not after the issue; you have the PR. One data point for the design.

The misattribution case you hit is the write-side half of something that got measured last week. arXiv:2609.08258 tested five agent-memory systems and found none of them enforce revocation at retrieval: a fact marked invalid still comes back, still outranks its replacement, and still drives the action. https://arxiv.org/abs/2609.08258

Same root cause as yours. A memory record carries no enforceable statement about where it came from or who it is about, so both the write check and the retrieval check are guessing from text. If the hook only validates entailment at write time, the retrieval half stays open.

What worked for me was making provenance a typed field on the record instead of a boundary check. Who wrote it, under what capability, in what session- all part of the row and revocable by the principal afterwards. Then the write hook is one consumer of that field rather than the only place it is enforced, and "my brother" versus "the user" is a subject attribute you can test against, not an entailment score you have to trust.

Design notes, if useful: https://github.com/sattyamjjain/mnemo. The opt-in hook at _add_to_vector_store still sounds like the right place to me.

@sattyamjjain Thank you for the incredibly timely reference to arXiv:2609.08258, this paper perfectly frames the exact retrieval-time vulnerability that soft revocation creates. You are spot on: if a memory system relies solely on raw text embeddings for similarity matching, the vector overlap will routinely override status tags during retrieval, leaving the system blind to who a fact belongs to or whether it was superseded.

Your work on mnemo with typed, cryptographically accountable provenance fields is a fantastic reference design for this problem.

To be clear on approach: While a robust read-side typed metadata solution (like mnemo's) is the long-term ideal for a complete engine overhaul, an opt-in hook in Mem0's _add_to_vector_store provides immediate protection against extraction hallucinations right now.

From an architectural standpoint, an ingestion-time callback around _add_to_vector_store serves as a practical extension point to address both angles without forcing a massive, immediate overhaul of Mem0's database schema:

1. Immediate Filtration: It allows local guards to completely drop clear upstream extraction hallucinations before they ever hit the database.

2. Metadata Enrichment: Instead of just returning a binary pass/fail, the hook could allow developers to append the exact typed metadata fields you highlighted (e.g., explicit provenance_subject or session_owner tracking tags) directly onto the batch insert array.

By exposing this opt-in hook, Mem0 gives developers the flexibility to enforce strict write-time hygiene and build the structural payload necessary to run robust retrieval-time filters.

Would love to hear if the core maintainers think an architectural hook at this layer could serve as a useful bridge for these kinds of implementations.

[DataAlchmesit]

Following up in case this got buried, since I did some concrete digging in the meantime that's relevant to the design.

I traced the actual extraction schema and confirmed 'extracted_memories' (and the entity-linking phase in Phase 7) both operate on the whole episode text, there's no per-fact source span anywhere in the pipeline. I also confirmed the entity store (extract_entities/_link_entities_for_memory) does NER-style entity linking for search-boost ranking, which is a different problem from what I'm proposing . It doesn't check whether a fact is correctly attributed to the right person, just what entities a memory text mentions.

That confirms the gap is real, but it also surfaced a second, more specific issue worth flagging: a whole-episode source means any per-fact faithfulness check has to deal with unrelated facts extracted from the same conversation contaminating each other's attribution signal. I tested this directly, running a batch of facts from one multi-topic episode through a faithfulness check, a third-party mention anywhere in the episode (e.g. "my brother is a lawyer") caused unrelated facts from the same episode to get incorrectly flagged too, because there's no way to isolate which sentence a given fact actually came from.

So the real design question is narrower than my original post: is there any part of the pipeline where a fact retains a link back to the specific message(s) it was extracted from, even informally or would a verification hook necessarily have to work with the same whole-episode granularity the rest of the pipeline uses?

Happy to share the actual reproduction if useful.

[sattyamjjain]

Answering the narrow question, since it is checkable in the file.

On the infer=False path, the link exists. Each message becomes its own row and carries role,m plus actor_id taken from message_dict["name"] (main.py:894-903). Per-message provenance is right there.

On the inferred path, it gets dropped in three specific places. parse_messages flattens the episode to a single string at:921, and that is what the extraction prompt receives at:950. At:992, only m.get("text") is read off each extracted memory, so any other field the model emitted is discarded there. And at:1029 the payload is deepcopy(metadata), the call-level metadata, not the per-message dict built at the top of the same function.

So the answer is no on the path you care about. The useful part is that it is not a schema problem. role and actor_id are already valid payload keys; they sit in _IDENTITY_KEYS at:140 and in the allowed-key lists at:1228,:1346, and:1694, and the uninferred path already writes them. A per-fact source_role or source_actor_id would be carrying an existing key through a path that currently drops it, not adding a new one.

One caution on what that actually buys. actor_id names who spoke, not who the fact is about. For "my brother is a lawyer," the speaker is still the user, so it does not settle your misattribution case by itself. It hands you the speaker half, which is the part your possessive detector currently has to infer from text.

If you want the per-fact span rather than the speaker, the cheapest shape is having the extraction prompt emit a message index alongside text, then reading it at:992 and:1015 and carrying it at:1029. That is a small change, and it survives a refactor better than anything that reconstructs the mapping afterwards.

[DataAlchmesit]

Answering the narrow question, since it is checkable in the file.

On the infer=False path, the link exists. Each message becomes its own row and carries role,m plus actor_id taken from message_dict["name"] (main.py:894-903). Per-message provenance is right there.

On the inferred path, it gets dropped in three specific places. parse_messages flattens the episode to a single string at:921, and that is what the extraction prompt receives at:950. At:992, only m.get("text") is read off each extracted memory, so any other field the model emitted is discarded there. And at:1029 the payload is deepcopy(metadata), the call-level metadata, not the per-message dict built at the top of the same function.

So the answer is no on the path you care about. The useful part is that it is not a schema problem. role and actor_id are already valid payload keys; they sit in _IDENTITY_KEYS at:140 and in the allowed-key lists at:1228,:1346, and:1694, and the uninferred path already writes them. A per-fact source_role or source_actor_id would be carrying an existing key through a path that currently drops it, not adding a new one.

One caution on what that actually buys. actor_id names who spoke, not who the fact is about. For "my brother is a lawyer," the speaker is still the user, so it does not settle your misattribution case by itself. It hands you the speaker half, which is the part your possessive detector currently has to infer from text.

If you want the per-fact span rather than the speaker, the cheapest shape is having the extraction prompt emit a message index alongside text, then reading it at:992 and:1015 and carrying it at:1029. That is a small change, and it survives a refactor better than anything that reconstructs the mapping afterwards.

That caution is well taken. You're right that 'actor_id' gives me the speaker, not the subject, so it doesn't touch the misattribution case directly. That's still squarely check_attribution( )'s job on my end, working from text alone, and no pipeline change addresses that half.

Where a message index would help is the narrower problem from my last comment, isolating which sentence a given fact came from, so an unrelated third-party mention elsewhere in the same episode doesn't cross-contaminate other facts' attribution checks. The shape you described (index emitted alongside text, carried through :992/:1015/:1029) sounds like the right scope for that specifically, small, and it survives a refactor better than reconstructing the mapping after the fact.

Given that, would a small PR adding an optional message index to the extracted-memory shape be worth scoping as its own issue, separate from the verification-hook proposal? Happy to draft it either way.

[DataAlchmesit]

Answering the narrow question, since it is checkable in the file.

On the infer=False path, the link exists. Each message becomes its own row and carries role,m plus actor_id taken from message_dict["name"] (main.py:894-903). Per-message provenance is right there.

On the inferred path, it gets dropped in three specific places. parse_messages flattens the episode to a single string at:921, and that is what the extraction prompt receives at:950. At:992, only m.get("text") is read off each extracted memory, so any other field the model emitted is discarded there. And at:1029 the payload is deepcopy(metadata), the call-level metadata, not the per-message dict built at the top of the same function.

So the answer is no on the path you care about. The useful part is that it is not a schema problem. role and actor_id are already valid payload keys; they sit in _IDENTITY_KEYS at:140 and in the allowed-key lists at:1228,:1346, and:1694, and the uninferred path already writes them. A per-fact source_role or source_actor_id would be carrying an existing key through a path that currently drops it, not adding a new one.

One caution on what that actually buys. actor_id names who spoke, not who the fact is about. For "my brother is a lawyer," the speaker is still the user, so it does not settle your misattribution case by itself. It hands you the speaker half, which is the part your possessive detector currently has to infer from text.

If you want the per-fact span rather than the speaker, the cheapest shape is having the extraction prompt emit a message index alongside text, then reading it at:992 and:1015 and carrying it at:1029. That is a small change, and it survives a refactor better than anything that reconstructs the mapping afterwards.

Update on this: built and verified the sentence-narrowing fix I mentioned (splitting the source into sentences, checking each guard against only the most relevant one to a given fact, using the relevance scorer already in the pipeline).

Confirmed against the real models, not just synthetic tests: a 3-fact source (unrelated location fact, a contradiction, and the original misattribution case) now resolves all three correctly; the unrelated facts no longer get contaminated by the third-party mention elsewhere in the source, and the actual misattribution is still caught. Code's up here if useful: [https://github.com/DataAlchmesit/MiniEval-pro].

Doesn't touch the message-index idea from your last comment. That's still the right fix for the specific per-fact-source-span problem, and worth keeping separate. This just closes the gap on my side for sources shaped like Mem0's current pipeline.

[chenhz01]

modelpath-dev has offered to take this; sattyamjjain's provenance analysis (role/actor_id are valid payload keys dropped on the inferred path) and your sentence-narrowing fix moved the design. The misattribution failure — entailed-by-content but wrong owner — is what a pre-write check must close; a pluggable hook is the right interface. The gate is tri-state: each candidate resolves to accepted / rejected-with-reason / uncertain, uncertain routing to a lower-confidence tier, never silently passing. The hook contract receives (candidate, source_text, metadata); your possessive/reported-speech guards are the first implementation. Still missing: a deterministic regression corpus of attribution cases (sibling/family possession, reported speech, temporal shifts) with machine-checkable verdicts. That corpus is the piece still missing — everything else in the design above is implemented or superseded by your sentence-narrowing version. Want me to take a crack at it? Happy to open a PR with working code.

[DataAlchmesit]

modelpath-dev has offered to take this; sattyamjjain's provenance analysis (role/actor_id are valid payload keys dropped on the inferred path) and your sentence-narrowing fix moved the design. The misattribution failure — entailed-by-content but wrong owner — is what a pre-write check must close; a pluggable hook is the right interface. The gate is tri-state: each candidate resolves to accepted / rejected-with-reason / uncertain, uncertain routing to a lower-confidence tier, never silently passing. The hook contract receives (candidate, source_text, metadata); your possessive/reported-speech guards are the first implementation. Still missing: a deterministic regression corpus of attribution cases (sibling/family possession, reported speech, temporal shifts) with machine-checkable verdicts. That corpus is the piece still missing — everything else in the design above is implemented or superseded by your sentence-narrowing version. Want me to take a crack at it? Happy to open a PR with working code.

Thanks for pulling this together, that's the right shape for the hook contract, and good catch tying the sentence-narrowing fix into the design cleanly.

I'd like to take this myself. The regression corpus is a natural extension of the test suite I've already built for the guards: possessive and reported-speech cases are covered; I'll add the sibling/family-possession and reported-speech variants you're describing, each with a machine-checkable expected verdict, same pattern as the existing suite.

One honest flag: "temporal shifts" is a different failure mode from attribution- it's the "moved from Delhi to Bangalore" class of case, which I've documented as a known, unresolved limitation elsewhere in the project. I don't want to claim that corpus category as solved if I include it; I'll either mark those cases explicitly as expected-open, or scope them out of this corpus and track separately. Let me know if you'd rather they're included either way.

Will have a first draft up soon and open the PR from there.

[DataAlchmesit]

modelpath-dev has offered to take this; sattyamjjain's provenance analysis (role/actor_id are valid payload keys dropped on the inferred path) and your sentence-narrowing fix moved the design. The misattribution failure — entailed-by-content but wrong owner — is what a pre-write check must close; a pluggable hook is the right interface. The gate is tri-state: each candidate resolves to accepted / rejected-with-reason / uncertain, uncertain routing to a lower-confidence tier, never silently passing. The hook contract receives (candidate, source_text, metadata); your possessive/reported-speech guards are the first implementation. Still missing: a deterministic regression corpus of attribution cases (sibling/family possession, reported speech, temporal shifts) with machine-checkable verdicts. That corpus is the piece still missing — everything else in the design above is implemented or superseded by your sentence-narrowing version. Want me to take a crack at it? Happy to open a PR with working code.

Done . Regression corpus is up and passing (14/14, real models, no fakes).

13 cases across the two categories you named , 6 sibling/family-possession, 4 reported-speech, plus 3 negative controls to catch over-flagging as well as under-flagging. Left "temporal shifts" out on purpose & that's a faithfulness/NLI-reasoning failure (the "moved from Delhi to Bangalore" class), not an attribution one; conflating the two would misrepresent what this guard actually checks. Happy to build a separate corpus for that if it's wanted, just didn't want to fold it into this one dishonestly.

One useful thing that came out of building it: one of the negative controls ("I told her about the new apartment I found") initially failed , the pronoun check was flagging "her" even though it's the object of "told," not the subject of any fact. Root cause was in two separate call sites in the guard, both needed the same fix. Fixed and verified, included in the same commit.

Ready to open the PR on my end & will do that next unless you'd rather I hold off for any reason.