One thesis: scheme detection is registry data — a grammar, a check-digit algorithm, and a canonicalization rule, pinned per scheme in schemes/*.json — so one resolver behind one described door can serve every identifier the physical world prints, with a single linkset contract: conformant to the GS1 standard for GS1 keys, and the same contract, explicitly labeled, everywhere beyond them.
This is the property's architecture post, and the architecture fits in a transcript. Five identifiers, five schemes, one verb:
$ barcoding resolve 4006381333931 --json
{"scheme":"gs1.gtin","carrier":"ean-13","canonical":"04006381333931","check":"mod10 pass"}
$ barcoding resolve 1M8GDM9AXKP042788 --json
{"scheme":"vin","canonical":"1M8GDM9AXKP042788","check":"iso3779 mod11 pass (pos 9 = X)"}
$ barcoding resolve 9780306406157 --json
{"scheme":"isbn","within":"gtin","canonical":"9780306406157","check":"mod10 pass","route":"bookland 978"}
$ barcoding resolve '(01)08717648200274(10)LOT42' --json
{"scheme":"udi.gs1","di":"08717648200274","pi":{"lot":"LOT42"},"check":"mod10 pass"}
$ barcoding resolve 1Z999AA10123456784 --json
{"scheme":"ups-1z","shipper":"999AA1","check":"best-effort (no public UPS algorithm)"}Five grammars — a GS1 mod-10, a federal-regulation mod-11 with a transliteration table, a prefix-routed GTIN, a three-agency device grammar, a proprietary carrier format — one call shape, one output contract, and a per-row honesty column (check) that states exactly how strong each verdict is. Nothing in that transcript is a special case, because nothing in the engine is.
The registry file is the whole trick
Each scheme is one pinned file. The anatomy, constant across all of them:
{
"scheme": "…",
"detect": { … }, // how to recognize it: length, charset, prefix, AI, framing
"grammar": { … }, // segments, fixed/variable fields, embedded schemes
"check": { … }, // algorithm + pinned test vectors, or "none", or "best-effort"
"canonical": { … }, // the one form; source form preserved as metadata
"enrichment": [ … ], // rails, each with a license class
"joins": { … } // where this scheme lands in events and transactions
}Every file's digest is in PINS.json, printed by barcoding pins, changed only by journaled human ruling. Adding a scheme is adding a row; revising a grammar is a pin diff with a paper trail. There is no parser folklore anywhere in the path — which is the property that makes "universal" a maintenance posture instead of a boast.
Detection order matters and is itself data. The interesting cases are the nested ones: an ISBN is a GTIN-13 (prefixes 978/979 route to the book row while keeping the GTIN identity), and a US drug GTIN embeds an NDC (the wrapper's mod-10 is checked, the embedded code extracted, both facts reported separately). Ambiguity is resolved by declared precedence in the registry, not by whichever regex fired first — so the same input yields the same classification on every machine, every time, which is the property an integration agent actually needs.
The precedent is a government database
None of this architecture is speculative — the FDA has run its multi-scheme version for a decade. AccessGUDID accepts device identifiers in three accredited agencies' grammars (GS1, HIBCC, ICCBBA), detects which it was handed, parses identity from instance data, and serves public-domain answers through one door. barcoding.dev generalizes exactly that pattern past one vertical: more rows in the grammar table, the same one-door contract. The UDI post works that precedent in full.
The conformance boundary, drawn where it belongs
The hosted door serves the same universality over HTTP: a described resolver whose linksets answer for every scheme in the registry. The boundary statement is precise, and it is worth being precise about. For GS1 primary keys, the resolver is conformant to the GS1-Conformant Resolver standard — /.well-known/gs1resolver description file, RFC 9264 linkset behavior, gs1:defaultLink, 404/400 semantics. For everything else — a VIN, an ISBN routing, an NDC, a tracking format — it is the same contract extended, and labeled as an extension: same door, same linkset shape, non-GS1 keys declared for what they are. Conformant to the standard; explicit about everything beyond it. Never the standard's name stretched over things it does not cover — the description file is the machine-checkable version of that promise.
Why the aggregators structurally cannot copy this
The 500-million-row lookup services could add scheme detection tomorrow; detection is the easy half. What they cannot bolt on is what travels through the door: per-attribute, per-link provenance with an enforced license class. Their corpora are aggregated under terms that forbid exactly the redistribution their APIs perform, so the one field this architecture carries on every value — on what authority — is the field their foundations cannot fill. Universality here is not breadth of rows; it is the license class traveling with every answer, for every scheme, so that breadth never has to be paid for with provenance. That is a moat made of constraints, which is the durable kind.
Run the transcript
The five commands at the top run locally — npx barcoding.dev resolve, no account, no network — and the scheme pages behind them are the reference layer: /schemes/gtin, /schemes/vin, /schemes/isbn, /schemes/udi, /schemes/ndc, /schemes/sscc, /schemes/gln, /schemes/ai, /schemes/tracking, /schemes/dl. Feed the verb your own worst identifiers — the freetext UPC column, the mixed ISBN feed, the tracking numbers with no shipment context — and read the classifications. If your stack currently runs five identifier libraries with five failure vocabularies, the transcript above is the diff.
The hosted door — every scheme answered over HTTP as a provenance-carrying linkset — is the gated half: tell us who you are.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.