Your data team already syndicates product data through GDSN. Attributes flow to your retailers, the data pool is green, the syndication dashboards are healthy. So when the traceability requirement lands — a retailer's ask, a recall postmortem, an FSMA 204 line item — the reasonable first instinct is: we already send them all this data; why can't we do a traceback with it? Then someone tries, and the traceback does not come out, and the room quietly concludes traceability is harder than it looks.
The traceback did not fail because it is hard. It failed because GDSN and EPCIS answer two different questions, and no amount of the first one ever becomes the second. This is the read that ends the confusion — and it leads with the operational cost of confusing them, because that cost is real and you may be paying it right now.
The one-line distinction, then the reason it bites
**GDSN carries what the product is. EPCIS carries what happened to each unit of it.**
- GDSN — the Global Data Synchronization Network — is a network of certified data pools through which you and your trading partners keep product master data in sync: net content, dimensions, ingredients, allergens, images, GPC classification, nutritional panel, the GS1 Digital Link the pack will carry. It is keyed at the class level — a GTIN, a target market, an information provider — and it answers questions about the product as a type. It is the source of truth for description.
- EPCIS — Electronic Product Code Information Services — is the event layer. It records discrete Critical Tracking Events: an Object event (this instance was observed here, at this time, in this business step), an Aggregation event (these units were packed into this case), a Transformation event (these inputs became these outputs). It is keyed at the instance or lot level — a serialized GTIN, a lot code — and it answers questions about movement and custody.
The reason this distinction bites is that traceability is entirely a question of the second kind. "Where did lot L4471 go, who received it, and when did it leave my plant" is not a fact about what the product is. It is a chain of events, each tied to a specific lot or unit, each observed somewhere by someone. GDSN has no place to put those events, because it was never built to. Feeding more attributes into GDSN produces a richer description of a product that you still cannot trace.
Why feeding GDSN never produced a traceback
Put the two side by side on the exact question a recall asks, and the mismatch is obvious rather than mysterious:
| The question | GDSN | EPCIS |
|---|---|---|
| What are this product's ingredients and allergens? | Yes — this is what it is for | Not its job |
| What are the case dimensions and pack configuration? | Yes | No |
| Which specific lots shipped to which distribution centers last Tuesday? | No — no instance, no lot, no event | Yes |
| Who received this case, and when did it leave my co-packer? | No — no custody, no observer | Yes (with the observer caveat below) |
| Given a contaminated lot, what is the downstream withdrawal list? | No | Yes |
GDSN is a pool — a synchronized, current-state picture of what products exist and what they are. It has no concept of a timeline, an instance, or an observation. There is no field for "lot L4471 was scanned at DC-14 at 03:12," because there is no lot and no scan in the model. This is not a limitation to work around; it is a category difference. Asking GDSN for a traceback is asking a product catalog to be a shipping log.
The operational cost of not seeing this: teams spend real budget enriching GDSN feeds — more attributes, more images, better classification — believing they are improving traceability, and the traceback capability does not move an inch, because none of that enrichment lives in the layer traceability reads from. The spend is not wasted on GDSN's own terms. It is wasted as a traceability investment.
Where Sunrise 2027 and the 2D mark touch both
The reason the two get conflated right now is that Sunrise 2027 puts a mark on the pack that touches both layers at once, and it is easy to see one mark and assume one system.
- The GS1 Digital Link URI your 2D mark carries — the product identity, and optionally the attributes it resolves to — is fed and governed on the GDSN / master-data side. That is the "what it is" face of the mark.
- The scan of that mark, every time it happens — at your plant, at the co-man, at receiving, at the lane — is a candidate EPCIS event. That is the "what happened" face of the mark.
One physical square, two data layers behind it. Sunrise 2027 makes the mark scannable; it does not by itself make the scans into a record. GDSN tells the shopper and the retailer what the product is. Only EPCIS can tell you where that unit went and who saw it move. If your program funds the mark and the GDSN feed but never names the event layer, you have built a product that announces itself beautifully and remembers nothing about its own journey.
Only EPCIS answers "where did it go, and who observed it" — and the honest limit inside that
So the answer to "which one do we actually need for traceability" is unambiguous: EPCIS. GDSN is necessary for what it does and you should keep it healthy, but it is not a traceability system and no roadmap should treat it as one. The event layer is the one that produces a traceback, and it is the one most CPG programs have not actually staffed. You can read the event model yourself — the event types, the Critical Tracking Events, the data model — in the public GS1 EPCIS 2.0 standard; we conform to it.
But name the honest limit inside the win, because a skeptic on your team will. EPCIS answers where did it go cleanly. It answers who observed it only at company grain — the standard's event model has five dimensions (what, when, where, why, how) and no performer field, and its party fields identify an organization, not a person or an agent. So out of the box, EPCIS tells you a company did a process, not a worker, on whose authority, made this observation. Across a co-manufacturer boundary, that gap is exactly where a traceback goes soft — and it is the gap the parent program plan is built to close, by carrying an attested observer alongside the conformant event. That is the layer beyond the GDSN-vs-EPCIS choice, and it is where the real work is.
Get the read, then the answer
- Take the read. What Sunrise 2027 and the event layer actually require of a GTIN owner — GDSN kept where it belongs, EPCIS named as the traceability system it is. Free, no gate: Sunrise 2027 for brand owners.
- See what an event record looks like with a lot and an observer in it — the thing GDSN structurally cannot hold. Free, no gate.
- Then, the ask. Your capture workspace is provisioned from the seat list, in order.
Put me on the seat list
Put me on the seat list → Manufacturer / brand — you pack it out and you own the GTIN
The seat-list promise, exactly: your capture workspace is provisioned from this list, in order — one email when your seat is ready, one, not a drip campaign. Nothing else, ever. If we stop working on this, you get one message saying so and your address is deleted.
llms.txt entry (append under ## Pages on visibility.cloud)
- [GDSN vs EPCIS for traceability](https://visibility.cloud/gdsn-vs-epcis-traceability): GDSN carries what a product IS (class-level master data — attributes, ingredients, the Digital Link the pack carries), EPCIS carries what HAPPENED to each unit (instance/lot-level Critical Tracking Events); they answer different questions, feeding GDSN never produced a traceback, Sunrise 2027's 2D mark touches both, and only EPCIS answers where a lot went and who observed it; the spine's doors are live at epcis.dev; ends at the manufacturer seat list.