Operations · Guide
Why identical-looking customer names fail to match
Resolve character-representation mismatches without overwriting names or silently merging distinct customer records.
Why identical-looking customer names fail to match
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Hong Kong Cantonese transcript · Macao Cantonese transcript
Case memo: one name, different representation
Imagine a U.S. catering company importing customers. José from a web form looks identical to José in an older export, yet an exact comparison fails. An AI assistant proposes a new customer. This is a hypothetical example, not a reported incident. Before asking the model to rewrite the name, ask a developer to inspect its character representation. The mismatch may be a precomposed character versus a letter followed by a combining accent.
Explanatory diagram redrawn from the approved article.
Inspect the representation before choosing a match
The character é can be represented by U+00E9 or by U+0065 followed by U+0301. Those original strings differ. Normalizing both to NFC makes this pair equal. Unicode defines canonical equivalence; JavaScript offers normalize("NFC") to perform the transformation.[S1][S2] This addresses a specific representation difference. It does not make every visually similar name equivalent, and it does not establish that two records describe the same person.
Explanatory diagram redrawn from the approved article.
Give one record three separate places
Keep the original name, a comparison key, and a stable customer identifier separately. This is our workflow recommendation: preserve the original for display and inspection, generate the key using a documented rule, and associate orders with the identifier. Apply the same rule to both sides of the comparison, including existing imports. Treat a match as a candidate, not permission to overwrite someone’s spelling or automatically merge namesakes. If several identifiers share a key, emit a collision list rather than choosing the first. Keeping originals also lets the team reverse a mistaken policy and recalculate keys.
Explanatory diagram redrawn from the approved article.
Decision card: NFC or NFKC?
For the canonical-equivalence problem here, evaluate NFC. NFKC additionally folds some compatibility distinctions, such as a circled digit into an ordinary digit. More transformation is not automatically better. Unicode warns against blindly applying compatibility normalization to arbitrary text.[S1] Agree rules separately for names, product codes, and contract text. A single universal cleaning switch can erase distinctions that a particular field needs to preserve.
Explanatory diagram redrawn from the approved article.
Keep this boundary visible
Normalization is not accent removal, lowercasing, translation, or identity verification. Visually similar characters can remain different; the W3C string-matching working draft explains this limitation.[S3] If your team separately adds accent-insensitive or case-insensitive search, label that behavior. Return multiple candidates when needed. A forgiving search experience should not silently become authority to update an account or merge customer records.
Explanatory diagram redrawn from the approved article.
Tabletop rehearsal: equal—and deliberately unequal
Before rollout, prepare three test groups. Precomposed and combining-accent forms should match under the chosen NFC rule. Jose and José should not become equal merely through NFC. Two identically named customers with different identifiers must remain separate records. Also check that original text survives import, search, and writeback. This is a proposed acceptance plan, not a claim that these tests have run against your systems.
Explanatory diagram redrawn from the approved article.
Hand the owner a decision, not a cleaning button
Have the business owner approve the comparison policy for each field. Then version the rule, retain originals, and list collision candidates. Begin with a suggestion-only trial showing which identifier was found, the evidence, and unresolved cases. Do not judge the result solely by fewer duplicates. Ask whether intended matches were found and whether distinct customers stayed distinct. Those are different outcomes, and both matter.
Explanatory diagram redrawn from the approved article.