Pre-publication review: our reading of GraphRAG's entity matching (corrections welcome by 2026-08-30)

[Eduard Izgorodin (izgorodin)]

Dear GraphRAG maintainers,

We are Edward Izgorodin and Olga Timoshina, authors of "Merge Without Measure: Entity Resolution and Deduplication in Six Agent-Memory Systems", a dated source review we plan to submit to arXiv. Full disclosure first: we work at Mnemoverse.AI, a vendor in the adjacent agent-memory space. The paper discloses that conflict and applies its rubric to our own system, which fails it (more below). Before submission, we are sending each reviewed project its own findings so any factual error is caught by the people best placed to catch it.

What the paper claims about GraphRAG, read at v3.1.1, commit 14a00ad, on 2026-07-18:

• Blocking window: no separate candidate window; the blocking key is the entity name itself, and records whose uppercased names are identical are grouped at index time.
• Matching: exact uppercased string match; your paper describes "exact string matching for entity matching". There is no fuzzy stage and no threshold.
• Conflict handling: conflicts get one sentence in the summarization prompt. At index time an LLM writes a new summary over the collected entity descriptions, which arrive alphabetically sorted and undated, so the model sees neither temporal order nor arrival order.
• Fate of the losing record: folded into the new LLM summary along with everything else attached to the name.
• What is published and stored: nothing is recorded about the decision, and no error rate is published. We report that the project previously contained an entity resolution step and removed it, quoting the maintainer comment in Discussion how can I enable entity resolution #778 that the associated setting was "left over from an entity resolution step we had in the codebase but were not happy with", and that the step is still absent at v3.1.1.

One framing point we want you to see verbatim: the paper explicitly calls the removal defensible engineering. It cites the OAEI 2023 Conference track, where two participating systems scored below a plain string-equality baseline, as evidence that sophisticated matchers can underperform string equality, and it states that the gap it documents is not the removal but the absence of a published measurement of what the removal cost.

Scope, stated plainly: this is a static reading. Nothing was executed; no index was built and no prompt was run. Every negative claim is scoped to the pinned commit and the sources read, with retrieval dates, and does not extend to later versions. One further caveat the paper states about itself: most of the GraphRAG findings are single-reviewer readings with no independent corroboration, which makes your check of them especially valuable.

The paper introduces the Merge Accountability Criteria (MAC): MAC-1, a published false-merge or false-split rate at the operating threshold; MAC-2, a merge record sufficient to undo a merge from the store; MAC-3, a threshold derived from a stipulated error budget. Your row in Table 3:

System	MAC-1 (error rate)	MAC-2 (reversibility)	MAC-3 (threshold provenance)	Nearest artifact
GraphRAG v3.1.1	No	No	Constant (string equality)	none

The same rubric is applied to Mnemoverse: our documented consolidate step publishes no false-merge rate, keeps no merge record, and derives no threshold from an error budget, so our own row fails MAC-1, MAC-2, and MAC-3.

Three questions:

1. Is any reading above factually wrong? If so, what is the correct reading, with a pointer (file, line, commit, or doc page)?
2. Is there a published error rate for the entity-matching decision, or a stored merge record, that we missed?
3. May we record your response verbatim in the companion repository (https://github.com/mnemoverse/merge-accountability)? Corrections enter as dated entries, and the paper acknowledges responders in its revisions.

Responses received by 2026-08-30 will be incorporated before the arXiv v1; later responses go into v2 and the repository, which records this outreach and its outcome as dated entries.

With thanks for your time,

Edward Izgorodin, Olga Timoshina (Mnemoverse.AI)
edward@mnemoverse.ai