Topic: validation
-
Checking placeholder contracts when an agent adds translated interface text
Preserve the runtime meaning of placeholders and message variants while translating interface text, so fluent prose does not introduce broken substitutions or missing cases.
-
Early stopping: patience, validation and restoring the best weights
Treat the stopping epoch as a model choice, monitor a separate validation signal, and distinguish the last trained weights from the best observed weights.
-
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.
-
Resolving Jev date selections against an explicit reference calendar
Keep date interpretation auditable by separating the date parts selected from a document from the calendar assumptions used to assemble an actionable date.
-
Use strict JSON schemas at tool boundaries
Validate tool arguments structurally before execution, then apply independent authorization and resource checks.
-
Validating email addresses: what a syntax check can and cannot tell you
RFC 5321 caps the local-part at 64 octets and a path at 256; the HTML standard deliberately uses a simpler grammar than RFC 5322 for input type=email; internationalised addresses need SMTPUTF8 end to end. Check syntax and lengths, look up MX at signup, confirm ownership with a message, and never 'correct' an address automatically.
-
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.
-
Checking that a inspected build artifact came from the current change
Prevent an agent from accepting a stale file, preview, or package as evidence that the current source change was built and delivered successfully.
-
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.
Machine-readable: JSON