For the director of supplier data — the GDSN steward at a grocery retailer, the person who lives on attribute quality from data pools and knows exactly how bad it is.
You run the cleanest data operation nobody thanks: attribute feeds from data pools, supplier scorecards, the quiet war against a wrong net weight propagating into a thousand shelf tags. The 2D transition is about to hand you a new class of data — and the first thing to understand about it is that your existing tooling is the wrong grain for it, structurally, not qualitatively. No amount of data-pool hygiene reaches what a 2D mark carries, because the mark and the pool describe different things.
First, the correction that keeps you out of bad meetings
GS1 Sunrise 2027's baseline expectation is that retail point-of-sale can scan and process 2D barcodes and extract the GTIN by the end of December 2027 — GS1 US frames the programme with the explicit scope limit that "it is not necessary to implement all the capabilities of 2D by that date." Lot and expiry are additional application identifiers a brand may choose to encode. Nothing in Sunrise obliges them, and Sunrise puts nothing on anyone's pack — the GTIN owner does, if it chooses.
So the sentence to strike from any internal deck is "Sunrise puts lot and expiry in the barcode." The true sentence is longer and more useful: some of your suppliers will choose to encode lot and expiry, on their own timelines, because the same mark that satisfies your lane can also serve their regulated and consumer-facing purposes — and when they do, an item-instance data stream starts arriving at your lanes and docks that no feed you currently steward can represent.
One yogurt, three grains
Take one SKU — a 32-ounce vanilla yogurt — and walk it through the three grains at which data about it can exist:
| Grain | Instrument | What it says about the yogurt | Cardinality |
|---|---|---|---|
| Class | GDSN attribute feed | "GTIN 00850012345678 is a 32-oz vanilla yogurt, refrigerated, 14-day shelf life, 12 per case" | One record per GTIN, ever |
| Instance | 2D mark AIs: (01) GTIN + (10) lot + (17) expiry | "This cup is lot 4271, expiring 2027-06-30" | One combination per lot — thousands per GTIN per year |
| Occurrence | EPCIS 2.0 event | "Lot 4271 was received at DC 6 on Tuesday 06:40, and this attested observer accepted it" | One event per thing that happens — unbounded |
Your data pool operates entirely on row one. It is definitionally class-grain: GDSN synchronizes what is true of every instance of a GTIN. It has no vocabulary for lot 4271, because lot 4271 is not an attribute of the product — it is a fact about a particular Tuesday's production run. When a 2D mark carrying (10) and (17) hits your lane, the data in it has never passed through your data pool and never will. The GDSN-versus-EPCIS distinction is the standards-level version of this argument; this is what it means for your tooling specifically.
The third row is the one nobody budgets: an instance-grain mark read at a lane or a dock produces occurrences — and occurrences need an event record, not an attribute feed. A lane that reads "lot 4271, expiring June 30" and has nowhere to put it has extracted the GTIN, rung the sale, and discarded the only new information in the symbol.
What supplier-encoded lot and expiry changes in your building
Concretely, when suppliers begin exercising the lot/expiry option, three things become possible at your four walls that are impossible today — each one only as real as the record behind it:
- At receiving: the case mark can answer "which lots entered this DC this week" as a scan, not a paper reconciliation — which is the shape of the FSMA 204 receiving KDEs your food-safety colleagues carry across DSD and DC simultaneously.
- At the shelf: rotation stops being faith-based; the mark on the front-most unit says whether it expires before the one behind it.
- At the lane: an expired unit can be caught at the only moment the store ever provably touches every item it sells.
None of that runs on class-grain data, and all of it evaporates if the reads are discarded after GTIN extraction. The record layer that keeps them — a conformant EPCIS 2.0 event per occurrence, with an attested who on every capture, the two grains who and capturedBy never collapsed — is what this platform records, and every open gap on our side is a named entry in the open P0 ledger.
What the steward should do with this
Your instrument is the supplier scorecard, so here are the lines this brief argues you add at the next revision — questions, not mandates, because the choice is genuinely the supplier's:
- "Do you encode lot (AI 10) and expiry (AI 17) in your consumer-unit and case-level 2D marks, and on what timeline?" — establishing which rows of your assortment go instance-grain, and when.
- "Which payload form do your marks carry — element strings or GS1 Digital Link URI?" — because only the URI form is web-resolvable, and the answer tells you how sophisticated the supplier's 2D programme actually is.
- "Is your GDSN shelf-life attribute consistent with the expiry AIs you encode?" — the one question only you will think to ask, and the first place instance data will catch class data lying.
The scheme-level anatomy of the AIs, check digits, and payload forms is documented at barcoding.dev if your team wants the engineer-literal version.
Grain is the argument you were already making — you have told colleagues for years that the data pool cannot say which pallet showed up. Now the marks themselves are about to agree with you. The written read for your seat — where instance-grain data enters, what record it lands in, what to ask suppliers first — starts at get started: your address first under the one-message promise, then questions that branch on your answers, ending in a read for your situation. It runs on this origin and locks when it ends.