GS1 Application Identifiers: the grammar inside the symbol

One thesis: a GS1 element string is a binary wire format with a typed field system and deterministic termination rules — and nearly every "barcode data is garbled" bug in the field is a parser treating it as text and guessing where fields end instead of reading the grammar.

Application Identifiers are how one symbol carries many facts. (01) introduces a GTIN, (10) a lot, (17) an expiry date, (21) a serial, (00) an SSCC — several hundred AIs in all, each with a defined syntax, published as a machine-readable JSON-LD registry at ref.gs1.org/ai/ and normatively specified in the GS1 General Specifications (the full text is free at ref.gs1.org). The parentheses, note, exist only for humans on label text. The wire carries none.

What the scanner actually hands you

A scanner does not hand you fields; it hands you bytes with a three-character prologue. Here is a GS1-128 read, exactly as delivered, with <GS> standing for the ASCII Group Separator byte (0x1D):

]C101000160002752701727033110ABC123<GS>21XYZ009

Parse it byte by byte:

1. ]C1 — the AIM symbology identifier: Code 128 with FNC1 in first position, i.e. this is a GS1 element string, not arbitrary Code 128 text. (A DataMatrix would announce ]d2, a QR ]Q3.) Parsers that strip this prefix without reading it throw away the one byte that says which grammar applies.
2. 01 — an AI with predefined length: exactly 14 digits follow. Consume 00016000275270. GTIN, mod-10 verified.
3. 17 — predefined length, 6 digits: 270331 → 2027-03-31. No separator preceded it, and none is allowed to: fixed-length AIs terminate by arithmetic, not by delimiter.
4. 10 — a variable-length AI (lot, up to 20 characters). Consume until Group Separator or end-of-data: ABC123. The <GS> byte is the transmitted image of FNC1 — it is grammar, not garbage.
5. 21 — variable-length (serial). Last field, so it runs to end of data: XYZ009.

Four typed fields from one payload, no ambiguity, no guessing — provided the parser knows the predefined-length table.

The table is pinned data, not folklore

Everything above hinged on knowing that AI 01 takes exactly 14 digits, 17 exactly 6, and that 10 and 21 are variable. That knowledge is a table in the GenSpecs — the predefined-length list plus the per-AI format entries — and it belongs in your dependency graph as pinned data with a digest, not as constants transcribed into a parser in 2019. The registry ships it that way: the AI table is a sha256-pinned artifact, derived from the published registry, whose digest barcoding pins prints, and which changes only by journaled human ruling when GS1 revises the specification. The difference between a pinned table and folklore is auditability: when a payload parses differently after an update, a pin diff tells you why.

The ambiguity that catches parsers

Here is the deliberately nasty payload, and the reason the termination rules are rules:

]C1010001600027527010LOT17ABC<GS>17270331

A text-brained parser scans for "17", finds it inside the lot value LOT17ABC, and splits there — yielding a corrupt lot and a garbage date. The grammar-brained parse never even sees that trap: after the fixed 14 digits of AI 01, it reads AI 10, consumes everything to the Group Separator as the lot (LOT17ABC — digits, letters, embedded "17" and all), then reads the next AI cleanly. Variable-length fields are delimiter-terminated; substrings are not field boundaries. This single rule accounts for a remarkable share of "intermittent" scan-data corruption in the wild — intermittent because it only fires when a lot value happens to contain a two-digit sequence that looks like an AI.

Two more classic bug families, with their failing inputs:

• Date AIs. 17 is YYMMDD, and DD = 00 is legal — it means "end of the stated month." A parser that runs 152600 through a strict date library rejects a spec-conformant expiry. The typed value is "February 2026, last day," and the AI table entry says so.
• Decimal-point AIs. Weight AI 310n carries its decimal position in its own fourth digit: 3103001500 is AI 310 with implied precision 3 → 1.500 kg, not 1500 of anything. Parsers that treat the fourth digit as data ship thousandfold errors that pass every eyeball test until an invoice reconciles wrong.

resolve runs the grammar with the pinned table and returns the typed map — and on the nasty payload above, both fields, correctly:

$ barcoding resolve ']C1010001600027527010LOT17ABC<GS>17270331' --json
{"scheme":"gs1.element-string","ai":{"01":"00016000275270","10":"LOT17ABC","17":"2027-03-31"},
 "check":"mod10 pass"}

Exit 0, or a typed error on stderr naming the exact byte offset and rule that failed — which, for an agent consuming this output, is the difference between a result and an apology.

Same map, two carriers

An element string is one of two spellings. The identical AI map can travel as an HTTP path — /01/00016000275270/10/ABC123/21/XYZ009 — which is GS1 Digital Link, and the round trip between the two carriers is where symbol choice, browser behavior, and Sunrise-era encoding decisions all live. That is the next post in the arc. The AI reference itself is /schemes/ai.

The check you can run in the next thirty seconds: point npx barcoding.dev resolve at a raw scan from any GS1-128 case label or 2D pack code in reach — prologue, separators and all — and compare the typed map against what your current parser stored. Where they differ, one of you is reading grammar and one of you is reading text.

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.