Are NYSIIS codes numeric?

The method discussed here produces alphabetic keys.

Does strict mode always produce six letters?

No. It limits the maximum length; a shorter result can remain shorter.

Can two unrelated people share a code?

Yes. The encoding deliberately compresses spelling distinctions, so collisions are expected.

AI Glossary / Retrieval and knowledge systems / Intermediate

NYSIIS phonetic code

Definition

The NYSIIS phonetic code is a letter-based encoding used to group names with similar spelling-to-sound patterns. NYSIIS refers to the New York State Identification and Intelligence System. The algorithm applies contextual substitutions and simplifications to produce a search key. It supports approximate name retrieval and record-linkage candidate generation, but a shared key does not establish that two names identify the same person.

What it means

NYSIIS compresses selected spelling distinctions while retaining an alphabetic result. This differs from treating the original spelling as an exact identifier. The transformation can make plausible variants easier to find, but it also removes information and can group unrelated names.
The acronym names the method's historical context; it does not make every modern use a connection to a government database. A locally generated code is just a derived representation. Its meaning comes from the encoding rules and the application using it, not from any inherent authority attached to the label.

How it works

The reviewed Apache implementation first normalizes the input and transforms selected beginning and ending patterns. It then builds a key using contextual letter substitutions, suppresses repeated results, and applies ending cleanup. Internal vowels commonly become A, rather than simply disappearing.
Apache provides a strict mode that limits the result to six characters and a non-strict mode that retains the full result. This setting is essential for index compatibility. The implementation body is the reference for the examples below; prose summaries of algorithm steps can differ from actual code behavior. Preserve the original spelling alongside the key.

Three practical examples

A historical-document search can retrieve surname variants under a common code while displaying the original transcription.
A customer-data cleanup experiment can use NYSIIS agreement to suggest pairs for review alongside other record attributes.
A system-migration team can compare strict and full-length keys to understand why a new search service retrieves a different candidate set.

Think of it this way

Think of a filing system that replaces several spelling patterns with a common shorthand. Related spellings may arrive at the same drawer, reducing the need to guess every variant. However, the drawer can contain unrelated records. The analogy does not imply that the shorthand captures every pronunciation, historical spelling, or writing system accurately.

Worked example

Consider an original manual trace for MacDonald and McDonald under the reviewed Apache rules. After conversion to uppercase, MACDONALD begins with MAC, which becomes MCC. The working string is therefore MCCDONALD. Its initial M starts the key. The following repeated C characters contribute a single C. D is retained, O becomes A, N is retained, the next A remains A, and L and D are retained. The full result is MCDANALD.
MCDONALD does not need the initial MAC substitution. Its remaining sequence follows the same relevant transformations, also yielding MCDANALD. Neither full result is shortened by the ending-cleanup rules in this example. In strict mode, the first six characters are retained, giving MCDANA. In non-strict mode, MCDANALD remains eight characters long.
The two spellings therefore share a key in either mode, but the stored key differs across modes. If an index stores only MCDANALD and a query service asks for exact key MCDANA, it will not find that entry unless the service deliberately reconciles the formats. This is an integration error, not evidence that the two names are phonetically unrelated.
Now suppose a fictional index stores five records under MCDANA. Independent review finds two relevant to a particular search and three irrelevant. Candidate precision is 2/5, or 40 percent. The code has provided a manageable group to inspect, but the relevant records cannot be identified from key equality alone.
If a verified contextual condition excludes two irrelevant records without removing either relevant one, precision becomes 2/3. That change comes from additional information. It does not convert the NYSIIS key into a unique identity number. These are manual encoding and set-counting exercises, not a report of running the library or testing real personal records.

Illustrative case study

Fictional case: an archive combines two catalog systems. Both describe their name-search feature as NYSIIS, but one stores six-character keys and the other retains longer outputs. Some apparently obvious spelling variants disappear from cross-catalog suggestions.
The team records the configuration difference and regenerates a compatible search index from preserved original names. It keeps the full original text visible, tests known matches and nonmatches, and checks whether the broader candidate groups create excessive review work before making the combined search available.

Common misconceptions and mistakes

Do not assume every implementation labeled NYSIIS uses identical normalization, length limits, or rule variants. Do not mistake a six-character limit for a requirement that every output contain exactly six characters; short keys need not be padded in the reviewed implementation.
Code equality is not proof of identical pronunciation or identity. Name pronunciation and transcription vary across languages and communities. A phonetic key also cannot infer ancestry or other sensitive personal characteristics. Claims that one encoder is universally more accurate than another require an evaluation definition and representative evidence, not just a percentage repeated in documentation.

Business use

NYSIIS can be useful when exact spelling misses relevant records and a lightweight, explainable search key is sufficient for candidate discovery. Its practical value should be measured against the collection's actual names and review process.
Retain original values and record the encoder version, normalization policy, and strict-mode setting. Evaluate both missed known variants and extra unrelated candidates. Separate missing names from legitimate short outputs. During migration, regenerate keys consistently or provide a deliberate compatibility strategy. Avoid mixing key formats silently, because a correct encoder can still produce ineffective search when indexing and querying use different conventions.

Check your understanding

Why can a query for MCDANA miss an indexed MCDANALD even though both were produced by NYSIIS?

Answer: Exact string lookup treats the two keys as different. The index and query used incompatible length settings, so their encodings must be reconciled.

Related terms

Soundex
Metaphone
Record linkage
Candidate generation
Precision
Phonetic encoding
Name normalization
Entity resolution
Index compatibility

Learn next

Create a compatibility checklist for two systems exchanging phonetic keys. Include original text, normalization, rule version, and length mode. Then recalculate the fictional candidate precision if two additional unrelated records enter the same key group while the two relevant records remain unchanged.

Precision

Sources

Primary implementation source: Apache Commons Codec Nysiis source: https://commons.apache.org/proper/commons-codec/apidocs/src-html/org/apache/commons/codec/language/Nysiis.html . MacDonald/McDonald traces and candidate arithmetic are original manual examples based on the implementation body. The original historical specification was not accessed.

Previous: Nyquist - Shannon sampling theorem Next: O'Brien - Fleming boundary