Check whether normalization merges distinct source keys

A text cleanup can make labels easier to compare while merging keys that were distinct before it. Inspect that transformation explicitly. This manual exercise uses invented ASCII strings in a usual shared document. It does not change actual account identifiers or describe Kiguri search, email matching, import behavior, or an identity-management feature.

Preserve the raw strings and exact rule

Use four distinct practice keys: A-1, a1, A1, and B-2. Define the toy normalization as removing ASCII hyphens and converting ASCII letters to uppercase. Make no other changes. Spaces, other punctuation, and non-ASCII characters are outside this fixture.

Record each original before calculating its result. A rule described only as make it consistent leaves too much unstated. Readers might remove spaces, change punctuation, or apply a different character policy. Such choices would create another transformation and need another review, not an assumed extension of this one.

Group originals by their output

A-1 becomes A1 because its hyphen is removed. a1 becomes A1 because its letter is uppercased. A1 remains A1. B-2 becomes B2. All four original rows can remain in the record, but there are only two distinct normalized values.

Build a register with normalized value and every original that maps to it. The A1 entry contains A-1, a1, and A1. The B2 entry contains only B-2. This original-to-output grouping makes the collision visible without deleting a row or losing the reason it matched.

Separate comparable labels from unique identity

A shared normalized label may be useful for a stipulated display or comparison purpose. That does not establish that its three source keys represent the same entity. The fixture says only that the transformation maps them to the same string.

If a later operation assumes the normalized value identifies exactly one original, A1 fails that assumption. Choosing the first row would discard the other possibilities. Storing a result under A1 without preserving its originals could also conceal which source it concerns. Keep the collision separate from a judgment that one of the records is incorrect.

Decide how the intended use handles collisions

Ask what the normalized output is meant to do. If it is only a display label, retain a separate stable raw identifier. If it is proposed as a matching key, document how multiple originals are represented and when the result remains unresolved. Do not silently turn normalization into a merge decision.

Any claim that these originals are aliases needs evidence outside the string transformation. Keep that question with its responsible owner rather than assigning equivalence because the cleaned values look alike. This ASCII exercise supplies no rule for Unicode, case-sensitive external identifiers, email addresses, or real account identity.

Recheck every original after a revision

If the toy rule changes, recompute all four outputs and their original groups. Do not patch the A1 entry alone while assuming B-2 or a future key is unaffected. Preserve the earlier mapping so another person can explain what the new rule changes.

The finish check is a traceable answer to which originals share an output and whether the intended use permits that ambiguity. A cleaner-looking key is not automatically a safer identifier. The useful artifact keeps transformation evidence, source identity, and any actual equivalence decision separate.