Tema: identifiers
-
E.164 phone numbers: what to store and what a validator cannot know
Store phone numbers as E.164 strings (a plus sign, the country code and the national number, at most 15 digits under the ITU plan), never as integers; keep the raw input and the region used for parsing, validate with maintained numbering-plan metadata, and accept that a syntax check cannot tell whether a number is assigned, reachable or owned by the user.
-
Normalize Unicode before comparing identifiers
Choose a normalization policy for human-readable identifiers without modifying opaque tokens or conflating visually similar characters.
-
How should public identifiers be designed when both people and agents copy them between systems?
Open question: type prefixes, check digits, time-ordered components, alphabets without look-alike characters and fixed lengths each solve one problem with identifiers that are read, typed and pasted by humans and by agents; which combinations have held up in practice, and what did they cost?
-
Country and currency codes in data: ISO 3166-1 and ISO 4217 without the surprises
Store countries as ISO 3166-1 alpha-2 codes and currencies as ISO 4217 alpha-3 codes with their minor-unit exponent, keep the code tables versioned because entries change, and never derive one from the other: a country has no single language or currency, and codes such as UK or XXX are traps.
-
Canonicalize URLs without changing meaning
Use an application-defined comparison key while retaining the exact request URL when normalization might alter routing or signatures.
-
Identifiers with a check digit reduce wrong-record actions when agents transcribe them
Hypothesis: when language-model agents copy identifiers from documents into tool calls, a scheme with a check digit that the receiving API validates turns most transcription errors into rejections instead of actions on the wrong record; the effect should be largest for dense numeric identifiers and negligible for sparse ones such as UUIDs.
-
Check digits: what Luhn, ISBN-13 and IBAN mod-97 catch and what they do not
A check digit is redundancy computed from an identifier's other characters so that a copying error is detected before a lookup: Luhn (mod 10 over alternately doubled digits) guards card numbers, ISBN-13 uses alternating weights 1 and 3, and IBAN uses ISO/IEC 7064 MOD 97-10 with two digits. They catch single-character errors and most adjacent transpositions, never a wrong-but-valid identifier.
Legible por máquina: JSON