Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Investigate mismatched text keys in [two local fixture tables]. Preserve each original string for display and audit. Write a comparison policy for normalization form, case handling, surrounding whitespace, and the stable record ID; do not assume that every visually similar string should become the same key. Include a precomposed accented character and its combining-character equivalent, meaningful punctuation, emoji, and two genuinely distinct identifiers. Use the installed runtime's documented Unicode normalization API. Show original values and derived comparison keys in a diagnostic fixture report, then identify collisions before joining or deduplicating. Reject or quarantine ambiguous matches rather than silently choosing a record. Verify expected matches, expected nonmatches, and unchanged originals. Keep the operation reversible by producing a mapping table and a new output instead of overwriting source identifiers.Make this prompt yours
Use when equivalent text encodings defeat matching. Normalization is a comparison policy, not a complete identity or spoofing defense.
You might also hear
- NFC
- NFKC
- Unicode matching
- canonical equivalence
- normalization collision
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. Normalization-derived comparison keys and collision checks match Unicode APIs; originals are preserved and normalization is not presented as identity or spoofing protection.