feedback fuzzy matching window blind repost bug 20260715T173150

Found during CreatorTrack's Meta cross-post matcher (M3) review: the matcher used trigram title similarity + a 21-day publish-date proximity window + duration match to link reposts across platforms to their source YouTube video. An adversarial reviewer re-scored the live data directly (not simulated) and found the real false-positive rate was 5-in-190, not the 1 documented by the builder. Root cause: when old back-catalog content gets reposted months later, the true match falls outside the date window, so the matcher links it to whatever unrelated video happens to share enough boilerplate title structure and falls inside the window instead (a recurring "WILL X EAT A [variable]" template made this worse: differing-word guards missed cases where more than one word changed).

Why: this is a systematic class of bug, not a one-off edge case, because content republishing is common enough that it wasn't caught by simulated/documented review, only by re-querying the live DB and re-scoring real pairs. How to apply: for any future time-windowed similarity/proximity matcher (cross-post linking, transaction/finance dedup, calendar event matching, etc.), explicitly test what happens when the true match falls outside the window, don't just check same-window precision; and prefer re-scoring live data directly over trusting a builder's self-reported false-positive rate.

[auto-memory session 60d132de-4659-485c-8044-427af0ccce7f, confidence 0.68, mode staged]