CoreMem 0.16.0 — filtered recall can no longer starve
150 noise messages could push your answer out of the retrieval window entirely. The fix was teaching the vector store to filter before it searches.
Here’s the bug that shipped for a while, because single-user demos can’t see it: a filtered recall — “show me memories from this one session” — would fetch the top rows with no filter at all, then filter in Python. The math betrayed us: over-fetching max(limit×20, 100) rows means a session with enough relevant noise can push the real answer completely out of the window. The query returns empty. For a question you know the memory has the answer to.
We reproduced it the way you have to: 150 same-phrase rows in a noise session, one innocent target row, recall(session_id="target") → empty.
0.16.0 adopts HybridDB 0.7.0’s search(where=): equality filters (role, session_id, user_id, agent_id) now push into the Chroma scan before the vector search runs. The vector index never sees rows that can’t be answers. The Python post-filter stays on top — layering correctness, never trusting one layer — and the semantics are identical in every strategy.
The regression test that pins it has a beautiful name: test_session_filter_finds_message_beyond_overfetch_window. That test is the whole release in one sentence: retrieval should find what you asked for, even when the noise outnumbers the signal.
Also in this series
0.15.0 (the quiet release between 0.14 and 0.16) did the flip we’d greenlit: versioned=True is now the default for new stores. If you start fresh, your memory is tamper-evident by default — governance isn’t an opt-in feature you’ll forget to turn on, it’s the baseline.
Which is the through-line of these releases: filter before you search, verify before you trust, and default to the thing that protects the user. Next up: the timestamp fix in 0.16.1 — a one-line bug with a two-year story.