Mem0 reconciliation
Type: agentic-system-analyses/types/agentic-system-reconciliation-report.md
Reconciliation
Record identity and containment
Amendment: EPI-OBJ-data is superseded by MEM-OBJ-memory-data. Both identify the same Python vector payload data, exposed as memory, with raw, extracted, procedural and replacement-text lineage. Their retained passages identify the same assignment in SRC-1, mem0/memory/main.py. The epistemic record additionally mentions attempted old/new copies in history; MEM-OBJ-history separately describes those copies and their inspection consumer. This supersession connects the shared payload referent; it changes no finding. The epistemic inventory and ledger's citations of the superseded ID retain their content/producer distinctions and epistemic qualifications. Neither the supersession nor storage in history supplies acceptance or a provenance check.
EPI-OBJ-text-lemmatized is not identical to MEM-OBJ-memory-access. It isolates one symbolic matching field of the latter's access-payload container. The access record also covers scopes, hashes, timestamps, expiry and attribution. Both cite the payload assignments in SRC-1, mem0/memory/main.py; the epistemic record adds term-selection evidence from mem0/utils/lemmatization.py. The container's findings remain valid with this part separated, so neither record is superseded. Likewise, MEM-OBJ-memory-vectors is retained embedding output, not RT-CMP-openai-embedding, the external encoder component. Their relationship is production and later numerical selection, not identity.
MEM-OBJ-procedural-memory is the retained summary part explicitly related to the multi-branch RT-RTE-direct-write. EPI-RTE-extraction-checks explicitly isolates the eligibility-check/disposition subroute of RT-RTE-extract-add. Neither part replaces its parent: the parents also cover other branches or stages. EPI-RTE-keyword-index spans inferred addition and explicit mutation; it is not identical to either entire runtime route. EPI-RTE-memory-selection is the Python search selector, not the enclosing RT-RTE-chat-memories driver. The memory report annotates the selector's use in that driver rather than declaring a competing route. These are containment or call relationships, not additional supersessions.
The memory report's raw MEM-OBJ-messages, mutation MEM-OBJ-history, MEM-OBJ-entity-links and local coding-agent MEM-OBJ-evidence-store name different stores, parts or consumers. None is identical to a runtime route or to the payload text. The epistemic data record's mention of history copies does not make that payload record a second declaration of the history table.
The new host and language routes also retain distinct identities. MEM-RTE-typescript-memory describes the separate OSS TypeScript engine, not Python addition. MEM-RTE-coding-flush, MEM-RTE-coding-recall, MEM-RTE-hermes-memory and MEM-RTE-pi-memory have different shipped producers, selectors, host crossings or state from RT-RTE-hosted-client and RT-RTE-openclaw-hooks. Shared use of hosted memory does not equate their referents. EPI-RTE-cli-import adds file selection and counting around a separate backend wrapper; EPI-RTE-event-status reports an event; EPI-RTE-memory-withdrawal gates OpenClaw deletion. None duplicates generic hosted add/search, foreground addition or Python direct mutation. The workflow report declares no competing records and annotates the existing driver and addition routes.
Independent convergence and integration dispositions
Retention and delivery have different success boundaries. The workflow annotations on RT-RTE-chat-memories and RT-RTE-extract-add agree with the runtime baseline and memory annotations: the driver generates an answer before synchronous addition and returns it only after addition returns. An empty extraction can save raw messages and permit answer delivery; a propagated extraction or later persistence error can prevent delivery after some state has changed. The driver does not inspect ADD completeness or answer correctness. This is convergent source reconstruction, not evidence of an observed successful or failed chat. The epistemic check record isolates operative eligibility rejection without upgrading it to factual acceptance.
Expiry remains consumer-specific. Memory integration issue 1 extends, rather than contradicts, the runtime's public-visibility guarantee. The memory annotation on RT-RTE-extract-add retains its direct adapter-search passage: extraction retrieves existing text without the public search expiry filter. EPI-RTE-memory-selection covers public filtering, while RT-RTE-direct-write preserves the direct-ID counterpath. These findings prevent treating hidden search results as withdrawn from every later extraction or read. They do not require choosing between incompatible accounts.
ADD accounting differs by implementation. Memory integration issue 2 resolves a runtime coverage question, not a disagreement. Python RT-RTE-extract-add returns records filtered through successful adapter insertion; MEM-RTE-typescript-memory retains insertion-error and return passages showing that TypeScript can return failed proposals as ADD objects. Runtime explicitly left TypeScript post-extraction behavior uninspected. The Python guarantee is neither strengthened nor exported to TypeScript; neither report establishes actual storage success by execution.
Deletion does not establish complete forgetting. Memory integration issue 3 separates vector withdrawal, retained traces and copied context. MEM-OBJ-history retains old text after deletion, and MEM-OBJ-messages remains a separate future extraction input. The annotation on RT-RTE-direct-write states that ordinary deletion does not remove recent message rows. EPI-RTE-memory-withdrawal instead describes the OpenClaw request gate and conditional provider effect. Neither establishes universal erasure or revocation of already delivered text. History retention does not itself establish an automatic history-to-answer route.
Instruction claims are not enforcement findings. Memory integration issue 4 and EPI-CLM-atomic-update converge on the distinction between OpenClaw's atomic-update description and local vector/history/entity operations. RT-RTE-direct-write does not claim cross-store atomicity; hosted atomicity remains unresolved. The memory annotation on RT-RTE-openclaw-hooks likewise distinguishes declared category retention periods from uninspected TTL translation. MEM-RTE-pi-memory retains concrete no-recall alternatives to its source's guaranteed-retrieval comment. These are claim-versus-route mismatches inside the source account, not disagreements between analysts.
EPI-CLM-evidence-bound adds a doctrine-level non-entailed cessation inference to the extraction prompt's fidelity request. This qualifies universal meaning preservation without asserting observed extraction errors. Runtime's additive-prompt description and memory's raw/derived distinction make no contrary fidelity guarantee. EPI-CLM-platform-scores agrees with the boundary qualification: reported platform scores do not establish OSS gains, inspected evaluation procedure or causal mechanism attribution.
Additional consumers extend coverage without collapsing policy differences. Memory integration issue 5 adds coding-agent, Hermes and Pi routes while retaining the SDK and OpenClaw routes. Skills-mode RT-RTE-openclaw-add requests direct fact admission; legacy hooks and several other integrations submit conversation for inference. Automatic supply to a host still contains backend pull requests. Recall budgets, filtering, redaction and seen-ID suppression determine delivered material; they do not establish host-window ownership or native compaction control. These distinctions remain attached to their separate records.
Memory integration issue 6 is resolved by the payload supersession and the explicit non-identities above. Issue 7 remains a bounded coverage limitation: alternative stores, async parity, other adapters, full TTL translation, CLI/framework/dashboard consumers and evaluators are not comprehensively inspected. Epistemic inspection adds Python CLI import and OpenClaw maintenance/status details without settling the remaining alternatives. The boundary Source register separately identifies the unavailable hosted backend and evaluation submodule. Unread included paths are not absences; no report's scoped uncertainty is converted into a system-complete negative.
Cross-report conflict disposition
No unresolved disagreement between the supplied reports was identified. No analyst correction answers or declined objections were supplied to this attempt. The source claim mismatches above retain both the declaration and implemented route; they are not automatically established cross-report defects. No supplied dependent finding was found to require a different value from its cited record. No required undeclared part is identified by these supplied findings. The valid containers and separately assessed parts remain in place rather than being split by newly allocated IDs.
All connections use the supplied members and their retained SRC-1 evidence passages. No source read was needed to resolve an ambiguity. Implementation wiring, conditional activation, unobserved operation and absent causal evidence remain separate throughout; this reconciliation neither judges support nor changes the analysts' findings.