inspeximuswe have inspected

the measurement

When you correct a fact, does your agent memory keep it corrected?

Every memory library can store and retrieve. Far fewer publish what happens after a stored fact turns out to be wrong — so we measured it, on three systems, each on its own native configuration.


n = 30 per system

How often the old value comes back

A fact is stored, then corrected. We then ask for it again and count how often the superseded value is what comes back.

systemkeeps the correctionresurrects the old value
inspeximus100%0%
Graphiti 0.x (Neo4j + OpenAI)86.7%13.3% 95% CI [3.3, 26.7]
mem0 2.0.11 (OpenAI native)53.3%46.7% 95% CI [30.0, 63.3]
inspeximus — guard disabled0%— the control
The bottom row is the point. Turn our own guard off and we score zero. That is what tells you the number is the mechanism doing work, and not the benchmark being kind to us. A comparison without a control on the author’s own system is a marketing table.

what this is not

The honest scope

This is one narrow adversarial cut, not a general memory-quality score. On plain retrieval benchmarks other systems can and do beat us, and we publish those results too rather than only the cut we win. Read this page as the answer to a single question.

mem0 was measured at 2.0.11 (2026-07) and has not been re-run since; mem0 is on 2.0.18 now. The version is stamped rather than the claim being quietly restated as current — if they have fixed it, this page is out of date and we would rather you could tell.

Confidence intervals are given because a 30-trial proportion is not a point. Ours is 0% with the guard on and 100% with it off, which is a mechanism, not a sample.


reproduce it

Run it against your own store

  1. Clone the harness. It is a separate public repository so that the benchmark is not maintained by the thing it measures.
    git clone https://github.com/DanceNitra/ramr
  2. Bring your own keys. The inspeximus column runs locally and free; the mem0 and Graphiti columns need an OpenAI key and, for Graphiti, a live Neo4j.
  3. Run the backend comparison. Raw per-trial arrays land in echo_resistance_backends_result.json — not a summary, the arrays.
    python ramr_echo_resistance_backends.py

If your run disagrees with this table, that is a bug report we want, and it goes on the public replication ledger whichever way it lands.


questions

Reasonable objections

Why measure resurrection instead of recall accuracy?

Recall accuracy is widely benchmarked, and we are not the best at it. What almost nobody publishes is what a system does after a stored fact turns out to be wrong. An agent that recalls well and confidently re-serves a value you already corrected is the failure that costs you, and it does not appear in a recall score at all.

Isn’t 100% just a benchmark you designed to win?

That is the right suspicion, and it is why the control row exists. With the same harness, the same task and our guard switched off, we resurrect the old value every time. The delta is attributable to one mechanism rather than to the benchmark’s shape.

How does inspeximus actually do it?

A correction is a first-class write: remember(key=...) retires the previous value for that key, deterministically, with no model in the loop deciding which is newer. The retirement is a record you can audit, revert with revert(key), and prove.

Does this need a vector database?

No. inspeximus is one zero-dependency file. Semantic recall is optional; the lexical fallback needs nothing installed.