One thesis: *"serialized" is not a buzzword, it is a grain decision — GTIN+serial names this unit (SGTIN), GTIN+lot names this batch (LGTIN) — and the choice decides forever which questions your event history can answer, at materially different cost on the line.* Because the choice is permanent per unit produced, it deserves to be made with both versions in hand, not discovered after the labels are printed.
If you run plant IT, this decision reaches you the way most of them do: a customer mandate names "serialization" without defining the grain, and the line needs an answer that a marking system can execute. Here is the decision in its actual mechanics — the two identity forms, the same case eventized both ways, and the query that shows what each version can never tell you.
Two grains, two spellings each
Both grains start from the GTIN — the class identifier, which product. What you append decides what you can point at:
SGTIN — GTIN + serial (AI 21). An instance identity: this unit, distinguishable from every other unit of the same product ever made. The serial is up to 20 characters from the GS1 invariant set, per the AI registry's own entry for AI (21), and the EPC Tag Data Standard gives the identity its URN spelling. One physical case, two equivalent grammars:
element string (01)09506000134352(21)40614
epc urn urn:epc:id:sgtin:9506000.013435.40614LGTIN — GTIN + lot (AI 10). A batch identity: this production run, every unit of it interchangeable with every other. Same two grammars:
element string (01)09506000134352(10)AB12
epc class urn:epc:class:lgtin:9506000.013435.AB12The URN prefixes are not decoration: epc:id versus epc:class is the standard itself telling you that one names an individual and the other names a kind. barcoding resolve derives either form from the parsed AI map, and generate writes either onto a mark — the grammar is the easy part. The consequences are not.
The same case, eventized both ways
Write down the moment a case leaves your line, once per grain. Both are valid EPCIS 2.0 ObjectEvents; both validate against the pinned official schema; they differ in exactly one structural place, and that place is everything.
Serialized — the unit goes in epcList:
{ "type": "ObjectEvent", "action": "OBSERVE", "bizStep": "shipping",
"epcList": ["urn:epc:id:sgtin:9506000.013435.40614"] }Lot-marked — the batch goes in quantityList, as a class with a count:
{ "type": "ObjectEvent", "action": "OBSERVE", "bizStep": "shipping",
"quantityList": [{ "epcClass": "urn:epc:class:lgtin:9506000.013435.AB12",
"quantity": 96, "uom": "EA" }] }Read the difference as a database schema, because that is what it is. epcList rows join to a unit's history — every subsequent event naming that SGTIN is the same physical object, provably. quantityList rows join to a batch's arithmetic — 96 units of lot AB12 passed this point, and which 96 is a question the record is structurally incapable of holding.
The recall query, run against both
The question that makes the grain decision real: customer X reports a problem with one case; what do we pull back?
Against a serialized history, the trace is a walk: the SGTIN in question appears in a chain of events — commissioning, aggregation onto a pallet, shipping, receiving — and the affected scope is computed by following that unit and its aggregation parents. The answer comes back as a list of specific units at specific custody points. Scope: what actually moved.
Against a lot-marked history, the trace is a sum: lot AB12 appears in quantity events across every shipment that carried any of it, and the affected scope is every destination that received any unit of the lot — because no record can say which units went where within the batch. Scope: everywhere the batch touched. A lot-grain recall is honest, fast, and broad; a serial-grain recall is surgical. The delta between those two scopes, priced in returned product and customer calls, is the value side of the decision.
The cost side, stated fairly
Serialization is not free, and a plant-side page owes you the ledger. Lot marking asks your lines for what they mostly already do: one mark per batch, printed from batch records. Serial marking asks for a unique mark per unit — per-unit variable-data printing at line speed, serial allocation that guarantees no reissue across lines and shifts, and journaled ranges so the numbers themselves are accountable. The allocation discipline is a durable-state problem — sequential or randomized ranges under your GTIN, collision-guaranteed, exportable — and it is precisely the kind of promise a stateless tool cannot make, which is why range management lives on the managed side of this property while marking and validation stay free and local.
The end state is not hypothetical, either: US pharma already runs everything-serialized under DSCSA, every package carrying GTIN+serial+lot+expiry — the precedent post Pharma already lives in 2027 walks what that rollout teaches everyone else.
How to decide, from the plant seat
The honest heuristic: the grain should match the question your customer's mandate actually asks. If the mandate is batch-level trace-back — most food-safety regimes, most retailer programs today — LGTIN answers it at a cost your lines already know how to pay. If the mandate names unit-level custody, or the product's unit value makes surgical recalls worth per-unit marking, SGTIN is the only grain that can ever answer it — and it cannot be retrofitted onto units already produced, which is why this page exists before the label order does.
Render both versions of your own case mark and put them side by side — npx barcoding.dev generate writes either grain, resolve reads both back, pure and local, no account. The event capture that turns those marks into the history the queries above run against is the family's spine, one door over: the construction mechanics are in From scan to conformant event.
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.