How does Smart search handle stale or conflicting memories?

[LightAim-hub]

Hi from Japan. I was reading the v15 release notes. The new Smart default (search a compact index, look at the surrounding context, then fetch only the details you need) is close to how my own setup works: an index file pointing to detailed markdown memory files, used with Claude Code.

My recurring problem is old memories that contradict newer ones. Does the judging step between searches have any way to notice stale or conflicting observations, or is that left to the model reading the results?

[Sagargupta16]

Left to the model. None of the three Smart steps (search, timeline, get_observations) compares observations with each other or flags one as superseded. The "reasoning between steps" in the v15 notes is the agent reading the index and the timeline, not a judging tool. The code says so for the one-call path too: the dumb_search footer in src/shared/progressive-search.ts reads "conflicting records are not reconciled", and docs/public/usage/search-tools.mdx repeats it.

What the tool does give the model to judge with:

• Every index row carries its date, and results are grouped under ### <date> headers, so age is visible before anything is fetched (docs/public/architecture/search-architecture.mdx).
• timeline shows the chronological neighbours of a hit, which is usually where the later correction lives.
• search defaults to orderBy=date_desc, so the newest match is at the top.

Three settings that bear on staleness (all in docs/public/configuration.mdx):

• CLAUDE_MEM_SEARCH_RECENCY_DAYS (default 90): date-less semantic search and the timeline only rank matches created in the last N days. That is the only built-in forgetting; set 0 to keep everything eligible.
• CLAUDE_MEM_REINFORCE_ALPHA (default 0, off): ACT-R ranking for SessionStart context only, not for search. A note the write path sees re-confirmed on later days climbs back into the window; a note nobody confirms decays. The write path appends a reinforcement day when a duplicate collapses onto an existing row (src/services/reinforcement/persist.ts).
• The SessionStart memory-use instructions (CLAUDE_MEM_MEMORY_INSTRUCTIONS_ENABLED, on by default) tell the agent to search before saving so it does not write a contradicting note in the first place.

For an index-file setup like yours the same pattern applies: put the date in every index line, keep the newest entries first, and delete rather than annotate when something is wrong. In claude-mem, deleting an observation also removes its Chroma document (v15.0.0 notes), so a deleted stale note stops surfacing in semantic hits.

[ajdelaguila]

Deleting the stale file works, but it also deletes the record that the fact changed, so an agent that later meets the old claim in a transcript or a commit message has nothing telling it the claim was retired. An alternative that fits an index-plus-markdown setup is to make the replacement explicit: the newer file carries a supersedes: <old id> field in its frontmatter, the old one gets status: superseded, and whatever loads your context only reads files whose status is current. The contradiction is then resolved once, when you write the newer file, instead of by the model every time it reads both.

Full disclosure, I maintain Data Olympus, which is built on that pattern: plain markdown with YAML frontmatter in git, an MCP server whose in-force queries leave out anything retired by an in-force successor even when nobody remembered to flip the old file's status, and a lint that fails when a supersedes points at a document that does not exist. It is aimed at decisions and rules rather than captured session observations, so it sits beside claude-mem rather than replacing it: https://github.com/knaisoma/data-olympus