Which Race Codes Should Be Used in a National Law Enforcement Telecommunications System NLETS Inquiry

In an NLETS inquiry, use the race codes in the current NLETS/NCIC code manual, and let the requesting agency's own record system drive the specific value: the federal standard is a single-character field (A, B, I, U, W), while many state and local systems add multi-character codes such as Asian or Hispanic categories. NLETS itself is a message switch, so the code you transmit must match what the destination state or federal database recognizes.

This is a technical explainer about data standards and interoperability. It is not legal advice, and it is not a substitute for your agency's terminal operator manual or the current NLETS operating manual.

How the NLETS switch and the code field actually interact

NLETS does not store criminal history records. It is an interstate message switch that routes a query from a terminal in one state to a database operator in another state or to a federal system. The receiving system decides what to do with the query fields it gets. That matters because race is one of the fields most likely to be defined differently from one agency to the next.

The federal person format that NLETS and NCIC share uses a single-character race field with five values: A (Asian or Pacific Islander), B (Black), I (American Indian or Alaska Native), U (Unknown), and W (White). That character is a data element, not a description. The terminal software translates the operator's input into the character, and the receiving system translates it back into whatever its own local code set uses.

The deeper mechanism is a code table, not a free-text field. Each system maps human-readable labels to fixed values, and the mapping is what breaks when two systems disagree. A message can be technically valid and still fail semantically if the sender's "I" means something different from the receiver's "I." That is why the reliable practice is to default to the federal set and only expand to local codes when you know the destination host expects them.

NLETS also enforces field-level validation before the message ever leaves. If a character is not in the accepted set for that transaction, the switch returns an error rather than delivering it. The validation protects data integrity but it cannot reconcile two valid codes that mean different things, which is the recurring failure in interstate traffic.

How the federal code set became the baseline

The five-value federal field is the product of a long standardization effort, not a single design decision. NCIC adopted the person format in the 1970s, and the race field was built to be compact because early terminal bandwidth was measured in characters per second. A one-character field saved space across millions of transactions, and that constraint outlived the technology.

The effort to harmonize federal codes advanced in steps. In 1980, the federal interagency committee on data standards endorsed common data elements for justice information, and the FBI's Advisory Policy Board later maintained the NCIC code tables that most state systems still mirror. FBI CJIS publishes those code tables for the NCIC and Nlets person formats. The pattern is consistent: federal systems define the minimum, and states extend it.

A key structural fact is that the federal set groups Asian and Pacific Islander into a single value and has no separate Hispanic category. Hispanic origin is tracked as an ethnicity attribute in many modern systems, not as a race value. That split explains most of the confusion operators hit when they type a query into a state system that still treats Hispanic as a race code. The receiving state's definition wins on that host, so a code that is correct in California may be rejected or misread in a state that never adopted it.

Quantified context: scale, error rates, and the cost of ambiguity

The numbers here are order-of-magnitude context, because published figures on race-code mismatch are sparse and agency-specific. Treat them as ranges to reason about, not as audited statistics.

Errors in this field are usually silent rather than loud. A nonstandard value may be rejected outright, which is easy to catch, or it may be accepted and stored under the wrong label, which is not. The second failure mode is the dangerous one, because a record built on a mismatched race value can persist for years and be pulled into later queries and reports. Plain language: most of the harm comes from codes that go through quietly, not codes that bounce.

A second order-of-magnitude point is that race is a relatively low-selectivity field on its own. A query that returns 200 records on a common name will still return many records after race is added. That is why operators lean on date of birth, sex, and identifiers first, and treat race as a refinement rather than a filter.

Edge cases where the choice of code genuinely changes the result

The gray zones are where agencies get burned, and they are worth walking through in order.

Multiracial identity is the first edge case. The federal five-value field has no "two or more races" option. If a subject identifies as more than one race, the federal convention is to select the single code that best reflects the record, often the one that appears in the source document, and to leave the rest to supplemental fields. Some state systems added an "M" or a multi-race flag, but those values do not travel to hosts that never adopted them.

Hispanic origin is the second. Because federal NCIC and Nlets person formats do not treat Hispanic as a race value, entering an "H" on a query to a host that expects the federal set will typically produce an invalid-field error. The correct approach on those hosts is to use the race value and add ethnicity in a separate field when the transaction supports it.

American Indian or Alaska Native subjects are a third friction point. Some local systems split tribal affiliation into a separate field, and the federal "I" does not carry that detail. If the query reaches a tribal or state host that validates the tribal field, the message may be accepted but with less specificity than the local operator intended.

Unknown race is the fourth, and it is underused. "U" is the correct value when the race is genuinely not known, and leaving it blank is not the same thing. Blank fields can be read as incomplete records, and some validators reject them. Use "U" deliberately.

Mismatch between a subject's self-identification and the arresting agency's entry is a fifth recurring problem. The operator's job is to record what the source document says, not to reclassify the subject. Reclassifying to match an expectation is a data integrity problem that compounds downstream.

Red flags to watch for before you hit send: A race value with two or more characters on a transaction that expects the federal set. A Hispanic "H" sent to a host whose manual lists only A, B, I, U, W. A blank race field where the receiving form requires a value. A local extension code from one state sent to a different state host. A record pulled from a supplemental report rather than the primary format.

A comparison of the code vocabularies you will encounter

The table below shows the main vocabularies and how they differ. It omits changing details such as current manual edition numbers, which change and should be checked at the terminal.

The practical reading is that the federal set is the lingua franca. It is the smallest common vocabulary, and it is the one that survives across state lines. The local sets carry more information but pay for that detail with interoperability.

Misconceptions that cause bad queries

The most common misconception is that NLETS itself holds a master race list you can look up and copy. It does not. NLETS is a switch; the code definitions live in the manuals of the systems you are querying. If you need the exact accepted values, the authoritative source is the terminal operator manual and the current NLETS operating manual, not a roster at NLETS headquarters.

A second misconception is that race is mandatory on every transaction. Some transaction types require it and others do not, and the requirement is a function of the transaction format, not of the query topic. Sending race when it is optional adds a failure point for no gain.

A third is that "Hispanic" has always been a federal race code. It has not. Hispanic origin entered federal statistics as a separate ethnicity concept, and many systems still keep the two dimensions apart. Operators who assume otherwise generate invalid-field errors on a predictable schedule.

The professional caveat worth stating plainly: the code that is "correct" is the one the receiving host's manual lists for that transaction, not the one that best describes the person in front of you. Those two things are usually the same, but when they diverge, the host's manual wins. That inversion of ordinary intuition is the single biggest source of repeat errors.

Practical actions for the terminal operator

The concrete workflow below is designed to reduce rejected messages and silent misclassification. It assumes you are working from a terminal connected to NLETS through your state system.

Check the destination before composing. Determine whether the query goes to a state repository, a federal system, or another state through NLETS, and pull that host's accepted code set from its manual. Default to the federal five-value set unless the host manual says otherwise. Use A, B, I, U, and W, and use U rather than leaving the field blank. Record what the source document says. Do not reclassify a subject to fit a code; if the source is ambiguous, use U and note the ambiguity in the remarks field where the format allows one. Separate race from ethnicity. When the transaction supports an ethnicity attribute, put Hispanic origin there instead of forcing an H into the race field. Validate the whole message before sending. A race code can be valid while a companion field, such as date format or name order, fails validation, and the race error message can mask the real problem. Log and report recurring rejections. A pattern of invalid race values from one host is an interoperability defect worth sending up to your state control terminal agency.

A useful threshold for escalation: if the same race value is rejected twice for the same host, stop hand-correcting and contact the state agency that manages the connection. Repeated rejections usually mean the host's code table changed or your terminal software is out of date.

The main limits of what this guidance can conclude are real. Published, audited statistics on race-code mismatch rates are not readily available, and code sets change with manual revisions, so this article deliberately avoids quoting edition-specific values. For the exact accepted codes on a specific transaction, the current NLETS operating manual and your state's terminal operator manual are the authoritative sources, and they should be checked at the point of use.

This article is general educational information about data standards and interoperability. It is not a legal opinion and does not create a compliance obligation or predict an outcome. For decisions about a specific transaction, record, or agency policy, consult your state control terminal agency, your legal counsel, and the current NLETS operating manual.