# Known limitations of the Scholar Sidekick citation verifier _v1 — last reviewed 2026-07-31._ The verifier is deliberately scoped and conservative. This page lists the cases where it is weak or can be wrong, so you can judge its output appropriately. It is the companion to the measured numbers and the immutable validation fixture at . These are the edges we currently know about. Found another? See _How to report a failure_ below. ## What the verifier actually checks Given a _claimed_ citation and an identifier (DOI, PMID, PMCID, ISBN, arXiv, ISSN, ADS bibcode, or WHO IRIS URL), it asks: does the claimed **title** — and, as secondary signals, the **first author**, **year**, and **container** — correspond to the paper that identifier resolves to? When the identifier and the claimed title disagree, it title-searches Crossref, PubMed, and OpenAlex to see whether the described work exists elsewhere (a wrong-identifier "citation error") or not at all. It returns one of `matched`, `mismatch`, `ambiguous`, or `not_found`, each with a confidence of `high`, `medium`, or `low`. **Reading `ambiguous` (it is a catch, not a pass).** When a real identifier is paired with the wrong one — e.g. a correct PMID but a DOI that resolves to a _different_ paper (a "PMID/DOI split") — the verifier resolves the identifier, finds the claimed title elsewhere via search, and returns `ambiguous`, not `mismatch`. That is the correct verdict for "real paper, wrong identifier" and counts as a successful flag. (Note for readers of the published validation receipts: the v4 fixture labelled the expected verdict for that fabrication subtype as `mismatch`, so its strict per-subtype pass-field can read low even though every case was flagged; a future fixture will accept either verdict.) ## What it does NOT tell you - **Whether the paper supports the citing sentence.** It confirms the citation points to a real, correctly-described paper — not that the paper's findings back the specific claim it is cited for. That still needs a human. - **Whether the paper has been retracted.** A correctly-cited retracted paper returns `matched`. Retraction is a separate signal — see the Retraction Checker. (The verifier ignores publisher "RETRACTED:"-style title prefixes when scoring, so a retracted paper still matches its original title.) - **Whether the paper is open access.** Separate signal — see the Open Access Checker. ## Current weaknesses (v1) ### 1. Translated or transliterated titles Title comparison is character-level. A citation that gives an English _translation_ of a non-English title, or a different romanization of a Cyrillic, Arabic, or CJK title than the registry holds, can score low and surface as `mismatch` or `ambiguous` even when it is the same work. Diacritics and common typographic variants are normalized away; genuinely different words (a translation) are not. _Mitigation:_ cite the title in the form the registry holds, or treat a low-confidence mismatch on a non-English work as "needs a human look." ### 2. Online-first vs print year A one-year gap downgrades a match to `medium` confidence; a two-year-or-greater gap pushes it toward `mismatch / low`. Legitimate online-first-then-print delays (and reprints) can therefore lower confidence on a genuine match — and, conversely, a fabricated citation that happens to be one year off can still read as `medium`. _Mitigation:_ read a year discrepancy as a soft signal and check the resolved record's date. ### 3. Preprint vs published version The same work often has both an arXiv ID and a journal DOI, with slightly different titles, author lists, year, and (always) a different container. Verifying a journal citation against the preprint record (or vice versa) can produce a container mismatch (a soft signal that does not change the verdict) and occasionally a year downgrade. ### 4. First author only Author checking compares the first author (with first/last name-order swap handling). A fabrication that keeps the real first author but invents the co-authors is not caught on the author axis — the title comparison is the gate. Initial-first and given-first forms (`"P Giral"`, `"Kristine Sørensen"`), a bare surname against an unsplit full name, and surname-first comma forms (`"Chukwuocha, Uchechukwu Madukaku"`) are now handled; group names supplied as the _author_, and collaboration names folded into the _title_, are too — see _Hardened cases_. **Compound surnames (fixed and still-broken halves, 2026-07-31).** Registries store double-barrelled and particle-carrying surnames in forms citations do not print, and until 2026-07-31 that produced confident false accusations on correct citations: - **Hyphen vs space — fixed.** `"Hatfield Dodds"` against a stored `"Hatfield-Dodds, Zac"` scored 0.912 against a 0.92 threshold and returned `mismatch / high`. Author names now tokenise across hyphens, so the existing surname rescues engage. - **Relocated particles — fixed 2026-07-31.** `"El Showk"` against a stored `"Showk, Sheer El"` differs in token _order_, which none of the ordered rescues could handle; it scored 0.550 and returned `mismatch / high`. Particles are now removed from both sides before the surname runs are compared, so the particle may move while the order of the real name parts is still checked. The obvious fix — matching on token overlap and ignoring order entirely — was **built, measured, and rejected**: it also accepts `"Smith Jones"` against `"Jones Smith"`, two different names. Discarding order discards real signal. - **Generational suffixes — fixed 2026-07-31.** `"Robert C. Kennicutt"` against a stored `"Kennicutt, Jr."` scored 0.487 and returned `mismatch / high`. A suffix carries no identity, so it is now dropped before the surname comparison. - **A long shared particle prefix carrying a match — fixed 2026-07-31.** `"van der Berg"` against `"van der Meer"` was _accepted_ (0.933) because the similarity measure weights a shared prefix heavily and `"van der "` is most of the string — two different people reading as the same author. When both names open with the same particle, that prefix is now discounted and the surnames proper are compared (0.667 here, correctly flagged). Same for `"van Dijk"`/`"van Dijkstra"` and `"de la Cruz"`/`"de la Torre"`. Unlike the other four author fixes of the same date, this one makes matching **stricter**, not looser: it closes a case where a wrong author was missed. - **A one-letter surname difference can still match — known, unfixed, and not fixable by string comparison.** `"de Jong"` against `"de Jonge"` scores 0.975 and is accepted. This is not the particle effect above (discounting the particle only moves it to 0.960) — the two names differ by a single letter. It is the largest open gap on the author axis, and the section below says how large, who it affects, and why we have stopped trying to close it with a better string metric. #### The one-letter surname gap, measured (2026-07-31) The bullet above understates it, so here is what we measured. A single-character surname difference becomes **arithmetically invisible from five characters up**. The worst case — the differing letter at the end of the name — scores 0.883 at four characters, 0.920 at five, 0.933 at six, and keeps rising. The match threshold is 0.92. Above that length, one wrong letter can no longer push a pair below it. Two panels, both showing the same gradient. The first is 8,090 machine-generated single-character edits of 56 real surnames; the second is 49 pairs of **real, distinct surnames** that genuinely differ by one letter. The generated panel shows the mechanism at scale but its mutated strings are not real names, so the attested panel is the one to weigh: | Surname length | Generated (n=8,090) | Attested pairs (n=49) | | -------------- | ------------------- | --------------------- | | 2–3 characters | 0.0% | 0 of 9 | | 4–5 | 13.9% | 6 of 18 | | 6–7 | 57.4% | 8 of 11 | | 8–9 | 79.0% | 9 of 9 | | 10+ | 88.8% | 2 of 2 | Read as: the share of genuinely different people who are accepted as the same author. Per-bin counts on the attested panel are small — 9 of 9 carries a 95% confidence interval of 70–100%, not certainty. **Who this affects.** Overwhelmingly long Scandinavian, Germanic and Slavic surnames where an `-sen`/`-son` alternation separates two common real names: `Hansen`/`Hanson`, `Jensen`/`Jenson`, `Larsen`/`Larson`, `Peterson`/`Petersen`, `Rasmussen`/`Rasmusson`, `Christensen`/`Christenson`, `Mikkelsen`/`Mikkelson`. Short surnames are **not** affected — `Li`/`Lu`, `Kim`/`Kam`, `Chen`/`Chan`, `Wang`/`Wong` are all correctly flagged. This runs opposite to the Unicode-dash failure fixed the same day (see _Hardened cases_ below), which fell hardest on short Chinese, Korean and Vietnamese surnames. **Why we are not fixing it with a better algorithm.** A genuine typo and a different person sit at the same edit distance — `Hernadez`/`Hernandez` (a typo) and `Hansen`/`Hanson` (two people) are both one edit apart. We tested twelve metrics — the character, token and phonetic families below — against 25 different-person pairs and 17 typo pairs. **None separated the two populations**; every metric's score range for real typos overlaps its range for different people, so no threshold on any of them works: | Metric | Different people | Typos | | ---------------------------------------- | ---------------- | ----------- | | Jaro-Winkler (what we use) | 0.920–0.980 | 0.950–0.982 | | Levenshtein / Damerau-Levenshtein | 1–2 edits | 1–2 edits | | Smith-Waterman (local alignment) | 0.750–1.000 | 0.750–1.000 | | Dice, Jaccard, Cosine (character n-gram) | 0.600–0.941 | 0.571–0.933 | The phonetic algorithms usually recommended for name matching are worse than unhelpful here, because they are built for the opposite job. Their purpose is to **cluster** spelling variants — the standard name-matching pipeline uses them precisely so that `Jensen`, `Jenson`, `Jansen` and `Yansen` land in one bucket. That is right for deduplicating a mailing list and wrong for asking whether a citation named a different person. Measured share of genuinely different people each one merges into a single key: Soundex 24 of 25, Double Metaphone 22 of 25, Daitch-Mokotoff 22 of 25 (the algorithm designed for exactly these Slavic and Germanic surnames), Metaphone 19 of 25. We also tested a second-stage check applied only to scores in a narrow band above the threshold, with a rule that tries to recognise typo fingerprints (adjacent swaps, doubled letters, dropped interior letters). The best version caught 23 of 25 different-person pairs but falsely accused 2 of 17 genuine typos, and on our own 299-citation validation corpus it would have newly accused real citations whose names had been mangled in transit — `Rodr??guez-Puebla` for `Rodríguez-Puebla`, `Grigor yan` for `Grigor'yan`. That is the wrong trade for this product, so it was not shipped. The honest conclusion is that the information needed — whether a citing author slipped a key or named a different person — is **not present in the two strings**. Closing this needs independent evidence, not a better comparison of the same two names. That is also what identity-resolution practice says: when two names score a high fuzzy match, production systems do not merge on the name alone — they consult a secondary field (a date of birth, an address, an identifier) as the tie-breaker. Bibliographic records carry the same shape of evidence in co-authors, year, and container. We use year and container already, as soft signals that adjust confidence rather than decide the verdict. The co-author list is the strongest unused signal, and the check described below is exactly that fix — it is off for its own measured reasons, not for want of the idea. _What to do with this:_ when a first author's surname is long and could plausibly be a near neighbour of another real name, read a first-author **match** as weak evidence and check the resolved record. This is a recall limit — it makes the verifier miss some wrong authors. It does not cause false accusations. **Measured cost, and the current state (2026-07-31).** An external benchmark (Badalova & Mayr, [10.5281/zenodo.21457492](https://doi.org/10.5281/zenodo.21457492)) put a number on this: 3 of our 7 misses were real papers cited with invented co-authors. A co-author cross-check was built to close this — it requires every claimed co-author to appear somewhere on the resolved record, and downgrades the verdict to `ambiguous` (review) rather than accusing. **It failed its acceptance test and is disabled.** Measured on the 48 entries of that benchmark it could affect, it caught 4 of 6 fabrications but **falsely flagged 2 of 42 genuine citations** (4.8%, 95% CI 1.3–15.8%) against a published false-accusation rate of 0.8%. Neither failure was a fabrication: one resolved record returned given names in the surname field, and the other reshaped two surnames (`El Showk` stored as `Showk, Sheer El`; `Hatfield Dodds` as `Hatfield-Dodds`). The limitation is not the idea but the quality of the author lists registries return, which is markedly worse for co-authors than for first authors. Both surname shapes named above have since been fixed on the **first-author** path (hyphen/space 2026-07-31, relocated particle 2026-07-31). At the time we noted that this did **not** retroactively pass the co-author check, because it had been measured on the first-author code of the day. **Re-tested 2026-08-02 — one of the two failures is gone.** The co-author pass reuses the same surname comparison as the first author, so both 2026-07-31 fixes reach it. On the identical 48-entry subset: **1 of 42 genuine citations falsely flagged** (2.4%, Wilson 95% CI 0.4–12.3%), down from 2 of 42, with fabrication detection unchanged at 4 of 6 and **no citation newly flagged**. The relocated- particle row (`El Showk`) now passes. **It is still off, and the reason is the arithmetic, not the result.** One event in 42 gives a 95% interval of 0.4–12.3% — that is consistent with our published 0.87% false-accusation rate and equally consistent with the 4.8% we rejected. A sample this small cannot tell those apart, so switching the check on would mean acting on a number that has not actually distinguished anything. The remaining failure is also the one shape no comparison logic can fix: that record returns **given names in the surname field** (`Jie`, `Yao`, `Tu`, `Balaji` against a correct claim of `Ren`, `Zhao`, `Vu`, `Liu`, `Lakshminarayanan`) — the citation is right and the registry is wrong. Worth stating plainly, because the incentive ran the other way: on the external benchmark's own scoring the change _improved_ both precision and recall. We declined it. Sending genuine work for needless review is a real cost to you that that metric does not price. It has not been retuned against the rows that failed — that would make the next measurement meaningless. #### The purpose-built measurement (2026-08-03) We said a decision needed a corpus sized to separate a 1% false-accusation rate from a 5% one, rather than a 48-row subset of someone else's benchmark. Here it is, in both directions. **Cost — three independent draws, n = 300 each.** Correctly-cited multi-author references, drawn from citing bibliographies' own LaTeX, selected on structure alone (author counts and DOI resolution) and never on whether the names agree — that axis is the one being measured, so selecting on it would be circular. Each draw was measured twice, with the check ON and OFF, because the raw flag count is misleading: on one draw 15 of 300 flagged with the check on, but 12 of those were already flagged with it off. The **attributable** cost was **1.00%, 1.00%, and 0.67%** (Wilson 95% upper bound 2.4%) — against the 4.8% that caused the rejection, and our published high-confidence false-accusation rate of 0.87%. **Benefit — what it actually catches, by fabrication shape.** Three shapes exist and they do not behave alike, so a single recall number would mislead: | shape | recall | | ----------------------------------------------------------------------------- | ------------------- | | co-author replaced by an **unrelated** real surname (n = 150) | **150/150** (100%) | | co-author replaced by a **near-miss** real surname (all 50 attested pairs) | **42/50** (84%) | | — excluding the pre-registered one-letter-long failure (§4.2 of the protocol) | **40/40** (100%) | | an invented co-author **added** to the list | **~0% — see below** | The unrelated-substitution set is measured end-to-end against the live API, and its baseline validates the design: with the check OFF, **1 of 150** was caught, because those rows carry a real DOI, real title, real year and real first author — they are indistinguishable from correct citations on every other axis. **⛔ The addition blind spot, and why we have not closed it.** The check refuses to run when the resolved record lists fewer authors than the citation claims, so a fabricator who _adds_ an invented co-author is invisible to it. That is not an oversight: on real data, adding one author would disable the check on **97% of references** (292/300), because publisher-deposited author lists are routinely shorter than the citation. The obvious repair — flag whenever the claim lists more authors than the record — was measured before we built anything, and it **false-accuses 2.0% of correct citations** (5/250, 95% CI 0.9–4.6%): three times the entire cost of the check it would be added to. Narrowing it to journal articles only gives 1.1% (2/183), still worse. And the shapes overlap exactly where it matters: a fabricator adding one author produces a gap of one, and one of the five legitimate cases is also a gap of one. No threshold separates them. **How much of the threat is that, actually?** We classified all 33 problematic references in the external Badalova & Mayr set by fabrication shape (2026-08-03): **21 (64%) were wholly invented papers** — no such work exists, so there is no author list to compare and the title axis is what catches them; **8 (24%) were author substitutions**, which this check does see; **1 (3%) was an addition**; the remaining 3 were single-author claims or had correct authors with the fabrication elsewhere. So on that corpus the blind spot covers about one reference in thirty, not a large share. ⚠️ Only 9 rows were classifiable, which puts the substitution/addition split at 89%/11% with a 95% interval of 56-98% — that bounds the question rather than settling it, and it is one corpus collected opportunistically. A purpose-built study of what LLMs actually produce is on the roadmap. So co-author checking, as designed, catches **substitutions and not additions**. If the dominant AI-fabrication pattern turns out to pad author lists rather than swap names, this check addresses the less common shape — and nobody has established which dominates. We would rather write that down than have it found for us. ### 5. Registry coverage gaps The "does the described work exist elsewhere?" search covers Crossref, PubMed, and OpenAlex. A real work not indexed there — many book chapters, theses, regional or non-English journals, very recent items, and grey literature — may not be found, so a wrong-identifier case can come back `not_found` or `ambiguous` rather than locating the true record. The same external benchmark showed this is our **largest** false-positive class: standards documents, software repositories, model cards and institutional reports are real, routinely cited, and indexed in none of the three registries. A `not_found` from an exhausted search now carries a caveat saying exactly that, so the response distinguishes "we looked in the scholarly registries and found nothing" from "this does not exist." It stops short of asserting the reference is non-academic — the API receives no URL, so that would be a guess. ### 6. Book edition ambiguity (ISBN) Different editions of a book carry different ISBNs but near-identical titles. The verifier may not distinguish editions, so edition/year differences can lower confidence on what is essentially the right work. ### 7. Ahead-of-print metadata churn A citation captured before a record's metadata is finalized (title tweaks, final year, volume/issue assignment) can mismatch the later, finalized record. ### 8. Conference vs journal duplicates A work published both as a conference paper and a journal article (different DOIs, containers, sometimes years) can produce `ambiguous` results depending on which version the citation targets. ### 9. Near-miss semantic flips (single-word meaning changes) This is the most significant known gap, surfaced by the 1,395-entry blind holdout (2026-06-05). When a real title is altered by flipping a single load-bearing word to its opposite ("children" → "adults", "increases" → "decreases", "with" → "without"), the title-similarity score barely moves — the change is one token in a long string — so the verifier returns a confident `matched`. On a designed panel of 30 such near-misses it caught only 4. This is distinct from the dominant AI-fabrication pattern (a real identifier paired with a wholesale-invented title, which the verifier catches reliably) and is closer to a subtle citation _error_; it is also hard for any similarity-based check. The opt-in LLM screen does not help here, because these cases return high-confidence matches and never enter its low-confidence review gate. **Planned fix:** a targeted antonym/negation detector that flags titles which are near-identical except for a meaning-flipping token. ### 10. Cross-registry metadata divergence (authors and titles) The verifier trusts what a registry returns. Two known shapes: (a) some registries store an author as a single `literal` string with a nobiliary prefix (DataCite's "de Azcarraga, Jose A." for an arXiv work) rather than structured family/given, which the author comparison can score below threshold even when the title matches exactly; and (b) a registry can mis-title a record (Open Library returning a study guide's ISBN under its parent textbook's title). In the second case the verifier is arguably correct to flag the disagreement, but the root cause is upstream data quality, not the citation. Both were observed (one each) among the two high-confidence false-accusations in the 1,395-entry holdout. ## Hardened cases (previously failed, now fixed) These were real failures we found and fixed; each carries a regression test, and they are listed here for transparency: - **A Unicode hyphen in a surname** (U+2010, or an en-dash) where the citing author typed an ASCII `-` produced a confident false `mismatch` — but only on SHORT surnames, because the fuzzy match that had been absorbing the difference is length-sensitive. "Duarte-Cabral" scored 0.969 and matched; "Wu-Li", "Ng-Yu" and "Lo-Fu" scored 0.893, under the 0.92 threshold. It therefore fell disproportionately on short Chinese, Korean, and Vietnamese surnames. Surname normalisation now unifies dash variants, as title normalisation already did — fixed 2026-07-31. - **HTML markup in titles** (for example `Gaia`) leaked tag letters into the comparison and dragged similarity below the match threshold — fixed 2026-05-13. - **Publisher retraction prefixes** ("RETRACTED: …", "Retraction Note to: …", "WITHDRAWN: …", "Expression of Concern: …") dragged a correctly-cited retracted paper to `ambiguous` — fixed 2026-05-18. The original title now matches while the retraction prefix still shows on the resolved record. - **First/last name-order inversion** from some adapters caused false first-author mismatches — fixed 2026-05-13. - **Too-sparse claims** (a single-word title with no identifier) returned a misleading `not_found / high`; they now return as "not verifiable" with an explanation — fixed 2026-05-13. - **Group- and consortium-authored citations** cited by their collaboration name (for example `RECOVERY Collaborative Group`, `PIOPED II Investigators`), and reference-list author fields that lump the surname with the given name/initials or transpose the name parts, previously produced false `mismatch` / `ambiguous` verdicts. They now match — the group directly when it is the stored author (after normalising a leading "The"), or, when the record stores only the individual authors, confirmed by title + identifier and returned `matched` with a point-of-use caveat (`_provenance.caveats`) noting the group author itself could not be cross-checked against the record — fixed 2026-05-24, with the earlier _medium_-confidence cap replaced by the caveat on 2026-05-25. See the [changelog](https://scholar-sidekick.com/changelog) for the full set. - **Surname-first "Lastname, Given" author strings** — a citation author written with a comma (`"Chukwuocha, Uchechukwu Madukaku"`, common in reference styles and Dublin-Core `dc:creator` fields such as WHO IRIS records) folded the given names into the surname comparison, so when the registry stored the same name split differently (Crossref family `"Madukaku Chukwuocha"`) the author scored below threshold and a correct citation was flagged as a high-confidence `mismatch`. The verifier now reads the comma as the surname boundary and matches the surname before it — recall-safe (a genuinely wrong author still does not match) — fixed 2026-06-05. - **Legacy SICI-style DOIs (angle brackets)** — old Wiley DOIs embed interior `<…>`, e.g. `10.1002/1521-4141(200205)32:5<1223::AID-IMMU1223>3.0.CO;2-5`. The identifier detector stopped at the first `<` and resolved a truncated, non-existent DOI → `not_found`. It now accepts `<`/`>` inside a DOI body so the DOI resolves to the right record; HTML-adjacent bare DOIs (`…/foo

`) are unaffected (a SICI bracket is followed by a digit, an HTML tag by a letter) — fixed 2026-06-05. - **Entity-encoded HTML tags in titles** — some publishers (e.g. Dove Press) return titles wrapped in entity-encoded tags, `<p>…</p>` (DOI `10.2147/cia.s244707`). The tag-stripper handled raw `…` but not the entity-encoded form, which collapsed the brackets to spaces and leaked the tag-name letter (`p`) as a spurious token → a false `mismatch`. The angle-bracket entities are now decoded before the tag strip — fixed 2026-06-05. - **arXiv resolution timeouts** — arXiv identifiers were resolved via `export.arxiv.org` (the Atom API), which is rate-limited and frequently returned 429/503 on cold ids → a transient `502`. They now resolve via the arXiv DataCite DOI (`10.48550/arXiv.{id}`) first — a robust, non-rate-limited registry with the same preprint title, submission date, authors, and published-DOI link — with the Atom API as a fallback. arXiv lookups are also cached now — fixed 2026-06-05. - **Online-first vs print publication years** — a work published online in one year and in print a year or two later carries two valid years. A citation that used the print year was scored against the online-first year (the single year we kept) and flagged with a low-confidence year mismatch even when title and author matched exactly. The resolver now carries both years (Crossref `published-print` / `published-online`) and the verifier accepts a claimed year matching either; a year matching neither still lowers confidence as before — fixed 2026-06-05. - **Group author folded into the citation title** — a collaboration name prepended or appended to the title field (for example `"NETTER-1 trial investigators. Phase 3 trial of…"`, or `"…on behalf of the NETTER-1 trial investigators"`) dragged title similarity below the match threshold. The affix is now stripped before the comparison — additively, so it can only rescue a correct citation, never let a fabricated title through — fixed 2026-05-25. - **PubMed collective authors** — a group-authored paper resolved via `PMID` whose PubMed record stores the collaboration as a `CollectiveName` is now rendered with the group name intact (previously mangled into a personal name), so it both formats correctly and matches the group-authored citation — fixed 2026-05-25. - **Structured subtitles** — a citation that kept a work's subtitle while the source (Crossref) stored the title and subtitle as separate fields was scored against the title alone and could fall below the match threshold. The verifier now recombines the canonical title + subtitle before comparing — fixed 2026-05-25. - **Initial-first and given-first author fields** — reference lists often store the first author as initials-or-given-name-first (`"P Giral"`, `"MJ Fila"`, `"Kristine Sørensen"`), or as a bare surname against an unsplit resolved full name (`"kim"` vs `"Hongryel Kim"`). These previously read as an author mismatch. The claimed surname is now recognised as a leading-or-trailing token run of the resolved name in either order; the match is additive and recall-safe — fixed 2026-05-26. - **"Collaborators" group authors** — collaboration names ending in `"Collaborators"` (e.g. the GBD `"… Collaborators"` consortium form) were not recognised as group authors. They now are, alongside the existing investigators / group / consortium / collaboration markers — fixed 2026-05-26. - **Greek letters spelled out vs the symbol** — a citation writing a Greek letter in full ("Calcineurin Aalpha", "IFN-gamma") against a title carrying the symbol ("Calcineurin Aα", "IFN-γ") read as a mismatch. Greek letters are now transliterated to their Latin romanisation on both sides before comparison — recall-safe (it can only raise similarity when one side spelled the letter out) — fixed 2026-06-05. - **Numeric HTML entities in titles** — a character carried as a numeric entity (`IFN-γ`, `γ`) was dropped to whitespace instead of decoded, so an entity-encoded Greek letter or accent never reached transliteration. Numeric entities are now decoded to their character — fixed 2026-06-05. - **Latin-extended letters with no decomposition** — letters such as ø, ł, æ, œ, ð, þ, ß have no Unicode decomposition and survived as non-ASCII tokens that dragged similarity below threshold (worst in a leading word — "Łukasiewicz", "Sørensen"). They are now folded to their conventional ASCII romanisation — fixed 2026-06-05. ## How to report a failure Found a citation the verifier gets wrong? Email . Confirmed new failure modes are added to this list and, where fixable, become regression tests.