When a retailer or regulator asks a brand to "use EPCIS", a common first reaction is concern: does this mean uploading our production and distribution data to a central GS1 database? It doesn't. EPCIS is about how you describe and exchange events, not about handing them to a central authority.
What EPCIS actually standardises
EPCIS is the GS1 standard for capturing and sharing event data about identified objects: what happened, when, where, why and how. GS1 describes it as a way to share that data "across, between and within enterprises". Two things are standardised:
- The data model. Five event types, standard fields for identifiers, times and locations, and shared vocabulary values from the CBV (Core Business Vocabulary).
- The interfaces. How events are captured into a system and queried out of it. EPCIS 2.0 added REST and JSON-LD alongside the older SOAP and XML options.
Nothing in that list says where the data must live. The standard deliberately leaves storage to the businesses using it. The EPCIS business guide explains the model in more detail.
Who stores EPCIS data
Each party stores the events it captures:
| Event | Usually captured and held by |
|---|---|
| Commissioning and packing at the factory | The brand or its contract manufacturer, often in a traceability or serialization platform |
| Shipping from the factory | The brand or its logistics provider |
| Receiving and dispatch at a warehouse | The distributor or 3PL |
| Receiving into store | The retailer, if it records events |
None of GS1's own descriptions of its services include a central store of these events. GS1's registries hold core identity data about numbers, such as which company a GTIN (Global Trade Item Number) is licensed to and a handful of product attributes. Does GS1 store all my product data? covers exactly what is and isn't held there.
Who shares what, with whom
If everyone keeps their own events, how does a traceability question get answered across companies? By agreement and by query.
Take Surya Laminates, a fictional maker of decorative laminate sheets that sells through regional distributors. A large project customer wants to know where a particular batch of sheets has been. The answer is spread across:
- Surya's own events: which sheets were made in the batch, how they were packed and when the pallets left.
- The distributor's events: when the pallets arrived and which orders the sheets went out on.
Surya can answer the first half from its own records. For the second half, it either queries the distributor's EPCIS interface, if the distributor offers one and has granted access, or asks the distributor to send the relevant events. Both parties use the same event format, so the results fit together.
Sharing usually works on a few principles:
- Need to know. A distributor may see receiving and shipping events for stock it handled, not the brand's line-level production data.
- Agreed scope. Partners agree which events, which identifiers (unit, batch or pallet) and which fields will be exchanged.
- Agreed terms. Retention, confidentiality and permitted uses are commercial matters, set in contracts rather than in the standard.
Access control: a public code is not a public history
A QR code on a pack is public: anyone can scan it. The detailed history behind it shouldn't be. Line numbers, shift times, supplier lots and shipment destinations are commercially sensitive, and a competitor or grey-market trader could learn a lot from them.
So access to EPCIS data is normally permissioned. The system holding the events authenticates whoever is asking and returns only what that party is entitled to see. A consumer scanning a product might see a short summary the brand chooses to publish; an authorised trading partner might query specific events; an internal quality team might see everything.
Discovery: finding the data without exposing it
There is still a practical question: if a partner holds a product's identifier, how does it find out where to ask for events about it? This is where a resolver can help.
With GS1 Digital Link, a product's identity is written as a web address, and a resolver can return a set of links for that identity, each labelled with a link type from the GS1 Web Vocabulary. Two link types are relevant here:
gs1:epcis, pointing to an EPCIS repository or interface for the item;gs1:traceability, pointing to traceability information about it.
The link tells a partner's software where to ask. It does not carry the events, and following it doesn't bypass access control: the endpoint behind the link still decides who gets what. GS1's guidance on 2D barcodes at retail describes this pattern, with information that "remains within [the] data owner's own system" and resolvers acting as a discovery service. What is a GS1 resolver? explains the mechanism, and how one product identity can lead to many digital services shows traceability alongside other uses.
What this means for your decisions
Because EPCIS doesn't decide where your data lives, you have to. The questions worth answering early:
- Where will our events be held? In-house, or in a platform? If a platform, who owns the data, and can we export it in EPCIS format if we leave?
- Which partners need which events? Start with what customers and regulators actually ask for.
- How will partners authenticate? Plan access control before you publish any discovery links.
- What will consumers see? A public summary, if any, should be a deliberate choice, separate from the operational history.
How EPCIS relates to the records already in your ERP is covered in EPCIS vs ERP.
Read how AIQR handles EPCIS data and access