An identifier is not a number
Even when a value contains digits only, plates, VINs, and chassis identifiers should be modelled as strings. Numeric conversion can remove leading zeros, alter precision, or make letters and permitted symbols impossible to represent.
The schema should declare expected length and characters without using validation to silently rewrite the value. A clear rejection is safer than guessing a correction.
Separate original, normalised, and technical key
The original value explains what the system received. A normalised value supports comparison. A technical key connects events and results. They may match, but they serve different purposes and should not overwrite one another.
A simple transformation such as uppercasing is safe only when the contract permits it. Removing punctuation or spaces can merge distinct valid values and should be avoided unless the authoritative source defines the rule.
Validate in the context of each capability
There is no single regular expression for every vehicle query. The capability defines its accepted identifier, relevant country or jurisdiction, and required field combination.
Store identifier type and, when relevant, country next to the value. Future expansion will not require reinterpreting historical records with new rules.
Make every transformation visible
If an interface proposes a format correction, show the received value and proposal before execution. In bulk workflows, record the rule applied to each row and allow rejected items to be exported without unnecessary data.
Tests should cover leading zeros, internal spaces, symbols, case, empty values, and visually similar characters. The goal is not to accept everything; it is to prevent two identities from becoming one.
Sources and references
Informational content for integration design. It is not legal, regulatory, or financial advice.
