For fuzzy matching, prefer no answer over confidently wrong
A messaging-app triage UI was suggesting wrong contact matches for outbound messages because of which field was used as the fuzzy-match hint
When ingesting messages, the natural way to derive a name to fuzzy-match against existing contacts is to use the from_display field. For inbound messages that is correct. For outbound messages from_display is the USER (the sender is us) — feeding that into fuzzy matching produces confidently wrong suggestions: the user themselves, or vault people whose names overlap with theirs. The recipient signal usually lives in a separate field (room_name, set by DM-portal adapters), but not always. When the recipient signal is missing, the right call is to return zero candidates rather than fall back to the sender — a no-answer is honest, a wrong-but-confident answer trains the user to distrust the system. Same principle: a guardrail that returns null when uncertain is more valuable than a fallback that returns the closest-by-distance answer. Especially relevant for any UI surfacing AI/ML/fuzzy suggestions where the user cannot easily verify provenance.
When building a fuzzy or ML-driven suggester, write down the inputs it MUST have to produce an answer, and short-circuit to null whenever those are missing. Fallbacks (use field B if A is empty) are tempting because they look helpful but degrade trust faster than gaps. Audit any direction-asymmetric data (inbound vs outbound, request vs response, etc.) for fields that mean different things on each side.