Join-key calculator casts confident no-match votes off OCR noise mis-parsed as a set code (no lexicon check, 85% of 61k no-match votes affected)

[WilfordGrimley]

Finding (confirmed live, 2026-07-23; surfaced by the orchestrator's discrepancy sampling on cards 77046/31096/14961). local_ocr.py's _SET_CODE_RE = re.compile(r"\b([A-Za-z0-9]{3,5})\b") accepts any 3–5 character alnum token near a parsed collector number as a candidate set code — there is no check anywhere that the token is a real MTG set code. parse_collector_line's own docstring is explicit that this is deliberate ("tolerant extraction, not validation... the validation rail... is what decides trust") — but the validation rail it's referring to (find_matching_candidates/validate_against_candidates) only ever checks the token against this one card's own name-narrowed candidate list, never against the full, real set-code lexicon (CanonicalExpansion.code, ~1,047 real codes).

The result: OCR noise that happens to look like a plausible token — "sew", "ree", "eee" (artwork/border noise, not text) — reads as a genuine (but wrong) set-code attempt. Since it obviously won't match this card's own real candidates (it isn't a real set code at all), validate_against_candidates returns "parsed-but-no-match", which calculate_join_key_verdict treats as genuine whole-candidate-set negative evidence and casts a confident is_no_match=True vote (JOIN_KEY_NO_MATCH_CONFIDENCE=0.6) — indistinguishable from a card where OCR genuinely read a real-but-wrong set code.

Sizing, DB-verified 2026-07-23, read-only:

• Total stage-d-join-key-v1 is_no_match=True votes: 61,247
• Of those, current stored collector_line_set_code is not present in the known-set-code lexicon (CanonicalExpansion.code, case-insensitive): 52,349 (85.5%)
• Blank set_code (the legitimate pre-M15 collector-number-only path — unaffected by this defect): 4,586
• Real, lexicon-valid set code that simply doesn't match this card's own candidates (working as intended): 4,312
• Restricting to cards that also carry a deductive-backfill-v1 deduction vote (a potential double-signal-conflict population): 6,772 cards carry both a no-match vote and a deduction vote, of which 5,906 (87.2%) rest on a lexicon-invalid set code. (Note: I could not reproduce the specific "4,768" figure referenced when this was flagged to me under any cohort definition I tried — a truly blank-collector-line-OCR card structurally can never reach a parsed-but-no-match no-match vote in the first place, since that requires a parsed collector number. Flagging this as an open item for reconciliation rather than asserting a number I couldn't verify.)

Ask: validate parsed.set_code against the real set-code lexicon before calculate_join_key_verdict is allowed to treat a "parsed-but-no-match" result as confident negative evidence. A set code that isn't in the lexicon should downgrade to a "no-text"-style (rescannable) abstention, not a confident is_no_match vote — the OCR didn't find a genuine (if wrong) set-code attempt, it found noise. This directly inflates the no-match vote pool with false negatives at ~85% of its current volume, which matters for any downstream consumer treating a no-match vote as trustworthy signal (e.g. review-queue routing, #262's clustering).

[WilfordGrimley]

Reconciliation of the unreproducible 4,768: that figure was computed by the orchestrator as |deduction-voted cards whose new-era machine vote is no-match| — no blank-OCR restriction (the blank framing in the surrounding conversation was conflation, correctly caught here). Your directly-computed 6,772 (any no-match ∩ any deduction, 87.2% lexicon-invalid) is the authoritative overlap number; treat 4,768 as superseded.

[WilfordGrimley]

Second OCR-preprocessing probe result (2026-07-23), directly targeting this issue's own population.

Ran a stratified 450-card experiment: 300 cards uniform-random from exactly the 52,349-card lexicon-invalid no-match population sized above ("stratum A", pool/counts reproduced live and matched exactly: lexicon 1,047 codes, 61,247 total no-match, 52,349 lexicon-invalid, 4,586 blank, 4,312 lexicon-valid-no-match), plus 150 cards from the 39,253 genuine matches as a positive control ("stratum B", ground truth = the recorded vote's own printing_id). Tested the same 4 preprocessing variant sets as the first OCR probe (baseline / +Sauvola adaptive threshold / +CC text-localization / +combined) via local_ocr.py's existing internals, read-only, no votes cast, no evidence written, transient pixels only (governing premise).

Result: clean negative, cleaner than the first probe. Baseline itself finds 0/300 genuine matches in stratum A (not even the first probe's 2/300 floor), and all three non-baseline variants gain exactly 0 genuine matches. Stratum B is a clean pass on its own (100% match preservation, zero drift) but that's moot since stratum A's gate fails outright.

The split this implies for the 52k pool: 0/300 rescues → rule-of-three 95% upper bound on the true rescue rate is ~1%. Best read: the lexicon-invalid population is overwhelmingly (~99%+) genuine art-noise, not degraded-but-real collector lines - at least as far as reachable by local-adaptive-threshold or connected-component text-localization preprocessing.

One caveat that connects directly back to this issue's own root cause, worth flagging here specifically: 282/300 (94%) of the stratum-A sample short-circuits at the very first preprocessing attempt, because image_evidence.py's own escalation loop (lines 619-627, unchanged by #380) breaks the instant parse_collector_line returns any non-None collector_number - with no lexicon check before accepting. That's the same defect #380 just fixed at the vote-casting layer (calculate_join_key_verdict now abstains on a lexicon-invalid parse) - but #380 doesn't touch the extraction layer, so a card that reads garbage on tier 1 still gets that garbage locked into ImageEvidence.collector_line_set_code/collector_line_raw_text, and the preprocessing tiers this probe (and any future one) would try are never even attempted for 94% of this specific population. Only the 18/300 cards that DID escalate past tier 1 got a fair shot from either probe, and among those, zero genuine or lexicon-valid recoveries (one coincidental lexicon collision, not a real read - see report).

Confirmed live: #380's own --selector set-code-lexicon-gate retraction tool has NOT yet been run against this population (61,247/39,253 vote counts unchanged before/after this probe).

Possible follow-up (not built, not requested by this task, flagging for a decision): make the escalation loop's own break condition lexicon-aware too - only stop early on a lexicon-valid parse, keep escalating through preprocessing tiers on a lexicon-invalid one. That's a different, not-yet-run experiment from either OCR-preprocessing probe to date; both so far tested "does better preprocessing help," not "does the pipeline even give preprocessing a chance to run" for this population.

Full report (variant×stratum×metric tables, per-card examples, verification detail): https://github.com/ProxyPrints/ProxyPrints.github.io/blob/report-ocr-preprocessing-probe-2-f4c91e/docs/reports/2026-07-23-ocr-preprocessing-probe-2.md

[WilfordGrimley]

Escalation short-circuit disposition (owner discussion 2026-07-23): the accept-any-parse acceptance criterion is the same root cause class as this issue, but probe data (probe 1: full forced escalation yields 1/300; probe 2: 0/300 variant rescues) shows fixing it recovers ~nothing, and the merged lexicon gate already neutralizes its damage at the vote layer. Disposition: tighten the acceptance criterion to lexicon-valid-parse-else-keep-escalating as part of the already-deferred live-pilot-engine lexicon-gate follow-up (both engines in one pass, reusing known_set_codes()). No short-circuit cancelled; not urgent.

[WilfordGrimley]

Closing: fix merged via PR #380 (2026-07-23) and PR #392 (2026-07-23) — set-code lexicon gate on join-key no-match votes and OCR escalation acceptance. 52,349 bad votes retracted; snip post-pass fidelity gate showed 0 wrong votes across 41,586 checked (pipeline investigation 2026-07-27).