Check-Digit or Format Validation¶
Validation rule — instantiates Durable Identifier Binding
A validation rule that rejects malformed or mistyped identifiers at the point of entry by checking them against the shape grammar and a built-in checksum.
Check-Digit or Format Validation is the input-time integrity gate. Before an identifier is accepted — typed, scanned, pasted, or submitted through an interface — this rule verifies that it matches the required shape and that its built-in check digit is internally consistent, catching a transcription error (a mistyped character, a transposed pair of digits) before it can create a wrong binding or a typo-induced collision. Its defining property is that it works on a single handle in isolation, using only the handle's own redundancy: no database, no lookup, no context — the identifier either validates against itself or it does not.
Example¶
A retail product barcode in the EAN-13 / GTIN standard carries thirteen digits, the last of which is a mod-10 check digit computed from the other twelve (a real GS1 standard). When a scanner or a data-entry clerk captures a code, the validation rule recomputes that check digit; if a digit was misread or two were transposed, the checksum no longer matches and the code is rejected on the spot — rather than silently binding the sale to a different, valid product. Alongside the checksum it enforces the format itself: exactly thirteen characters, all numeric. No catalogue is consulted at any point; the code is judged solely against its own structure and its own check digit.
That local, instantaneous rejection is the whole value: a large class of wrong bindings simply never happens, at the cheapest possible moment to stop them.
How it works¶
Validation runs in two layers. The first is format validation: the candidate string must match the shape grammar — length, allowed character set, field structure. The second is check-digit verification: a checksum computed over the payload must equal the digit embedded in the handle, which detects single-character errors and the common adjacent-transposition mistake. Both layers are purely local, deterministic, and instantaneous. Notably, the rule detects errors; it does not correct them, and it makes no claim that a well-formed identifier is the right one — only that it is not obviously broken.
Tuning parameters¶
- Checksum strength — a simple parity digit versus a stronger scheme (mod-97, multiple check digits). Stronger checksums catch more error patterns but lengthen the identifier.
- Strictness — reject on any deviation versus normalize-then-check (trim whitespace, up-case). Strict is safest; lenient normalization improves usability but can mask a real error.
- Where it runs — at data entry, at ingest, or on every read. Earlier and more often catches errors sooner but adds friction to every touch.
- Fail behaviour — hard reject versus warn-and-queue. Hard reject guarantees clean data; warn-and-queue routes a suspicious entry to review instead of losing it.
- Format vs. checksum weighting — enforce shape only, checksum only, or both, depending on where the likely errors are.
When it helps, and when it misleads¶
Its strength is that it stops the cheapest and commonest error — a mistyped or mis-scanned identifier — right at the door, using nothing but the handle itself. It needs no central lookup, is nearly free to run, and prevents a whole category of wrong bindings before they ever reach the registry.
Its crucial limitation is that a check digit is error-detecting, not error-correcting[n1], and that passing validation proves only that a handle is well-formed — never that it is the right handle for the intended referent. A perfectly valid identifier can still point at the wrong thing; a valid barcode can be entered for the wrong product entirely. The classic misuse is treating "passes validation" as "is correct," and skipping the semantic checks — does this identifier actually belong to this referent? — that a checksum was never designed to perform. The discipline is to pair format validation with the retrospective, cross-record checks of Collision Detection Review: validation is necessary, never sufficient.
How it implements the components¶
Check-Digit or Format Validation realizes the well-formedness-and-integrity side of the archetype — the checks a rule can run on a handle in isolation:
handle_shape_rule— it enforces the shape rule, accepting a candidate only if it conforms to the required grammar (length, characters, field layout). Where the Accession Numbering Protocol or the generator defines the shape, this rule is where that definition is checked.uniqueness_and_collision_check— the check digit guards against the transcription errors that would otherwise turn one valid identifier into another — a typo-collision — supplying the input-time half of collision defence.
It does NOT define what the shape should be (that's Accession Numbering Protocol and the UUID or Random Token Generator), and it does NOT detect semantic collisions — two records that truly denote the same entity (that's Collision Detection Review). It checks a handle against itself, never against the rest of the corpus.
Related¶
- Instantiates: Durable Identifier Binding — the rule keeps malformed and mistyped handles out of the binding system at the point of entry.
- Consumes: Accession Numbering Protocol — the shape grammar this rule enforces is the one the numbering protocol (or the generator) defines.
- Sibling mechanisms: Accession Numbering Protocol · Collision Detection Review · Identifier Minting Workflow · Identifier Registry · Alias Redirect Table · Persistent Identifier Resolver · Identifier Lifecycle Register · Identifier Reservation Queue · Namespace Prefix Registry · UUID or Random Token Generator
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: A validation rule that rejects malformed or mistyped identifiers at the point of entry by checking them against the shape grammar and a built-in checksum, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Check-Digit or Format Validation as 'A validation rule that rejects malformed or mistyped identifiers at the point of entry by checking them against the shape grammar and a built-in checksum', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Information Theory
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Coding and information theory established check characters as deliberately redundant symbols that detect human copying, keying, substitution, and transposition errors in an identifier string.
Related originating lineages:
- Computer Science & Software Engineering — Input validation and formal shape grammars contribute local format enforcement, normalization, and reject-or-review behavior.
- Mathematics — Modular arithmetic supplies the weighted checksum constructions used to detect substitution and transposition errors.
Review resolution: The reviewers split between information theory and computer science. ISO/IEC 7064 explicitly standardizes check-character systems for detecting copy and keying errors, while GS1 specifications apply weighted check algorithms to identifier keys and document detected error classes. Information theory therefore governs the checksum, with computing and mathematics completing the combined local validation rule.
Attribution caveat: Format validation is a computing lineage and check-digit arithmetic is mathematical, but the distinctive integrity property comes from error-detecting codes; passing the check still does not establish semantic identity.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- ISO/IEC 7064: Check Character Systems
- GS1 General Specifications: Check Digit and Character Calculations
- GS1: How to Calculate a Check Digit
Notes¶
[n1] Error-detecting versus error-correcting codes — a check digit is an error-detecting code: it reveals that a single-character or adjacent-transposition mistake has occurred but cannot say what the correct value was, and it misses error patterns it was not designed for. This is why passing a checksum proves well-formedness, not correctness. ↩