The GS1 DPP Provisional Standard has been available since June 2025. Ten months later, most teams still have not read it at the data model level. Here is what it actually requires.
Most commentary treats it as a news event. “GS1 published something. Here’s what DPP means.” That framing is not useful if you are building right now. You need to know what the spec mandates at data level. And where most current implementations are pointing in the wrong direction.
What the Provisional Standard Actually Covers
The GS1 DPP Provisional Standard is not the EU DPP regulation. That is ESPR. The GS1 standard is the technical specification that ESPR-compliant implementations must conform to.
Think of it this way. ESPR tells you what you need to prove about a product. The GS1 standard tells you how to prove it, technically.
The spec covers four things:
Product identification. How products are uniquely identified using GS1 identifiers: GTIN, GLN, SSCC. Standard GS1 territory.
Data carriers. How those identifiers are encoded on physical products. QR codes, NFC, RFID, GS1 DataMatrix. The GS1 and RAIN Alliance joint DPP statement confirmed that RFID and NFC are fully supported alongside QR. You do not have to choose one carrier type.
Digital Link URI structure. How a scan resolves to the correct data. More specific than most teams realize.
EPCIS event model. What supply chain events must be captured and how they link to the product passport.
That last item is the one most DPP projects underweight.
The Data Model: Three Layers, All Required
A compliant DPP implementation needs three connected data layers. Miss one and the others do not hold.
Layer 1: Master data (product identifiers)
Every product needs a GTIN. Every organization in the supply chain needs a GLN. Every shipment needs an SSCC.
None of this is new. GS1 has required it for years. What changes with DPP: the scope of what needs a GLN expands. It is not just your company headquarters. Every facility and sub-location used in a supply chain event needs a GLN.
Most companies have GTINs for their products. Complete GLN coverage across all relevant locations is a different story. That gap surfaces immediately when EPCIS event capture begins.
Layer 2: Event data (EPCIS 2.0)
This is where most DPP discussions stop short.
A DPP is not a label. It is a living record. The provisional standard requires DPP data to be backed by EPCIS 2.0 events. Not optional. Not recommended. Required.
EPCIS events are the evidence layer. A DPP makes claims about a product: origin, material composition, production steps, chain of custody. Those claims need to be verifiable against something. An EPCIS 2.0 event is that something.
The event types that matter for DPP compliance:
ObjectEvent with bizStep=commissioning is where the passport starts. The genesis record. This product exists. It was created at this location, at this time, from these inputs.
TransformationEvent is the most critical event type. When raw materials become a finished product, the TransformationEvent links input EPCs to output EPCs. For batteries, electronics, and textiles, this event is how you prove material composition. The DPP requires that composition claims trace back to a TransformationEvent showing which inputs became which output. No TransformationEvent chain means no verifiable composition claim.
ObjectEvent with bizStep=shipping and bizStep=receiving builds the chain of custody. Every handoff in the supply chain produces one of these.
ObjectEvent with bizStep=sensor_report handles condition monitoring. The Battery Regulation requires temperature and handling records for cells and packs. This is where that data lives in EPCIS.
Here is the requirement that breaks most DPP projects: EPCIS events are needed from every tier in the supply chain, not just your own operations. Your first-tier suppliers. Their first-tier suppliers. If your DPP claims the battery cells came from a specific facility, you need EPCIS events from that facility. Getting event data from Tier 2 and Tier 3 is an operational problem, not a technical one. Most DPP timelines underestimate it badly.
Layer 3: GS1 Digital Link resolver
Every product carries a data carrier encoding a GS1 Digital Link URI. For a product identified by GTIN, the URI looks like:
https://id.gs1.org/01/09506000134352/10/AB-123
The 01 is the GTIN application identifier. The 10 is the lot number. The domain routes to a resolver. The resolver returns the right resource for that product.
The provisional standard has specific requirements for the resolver. It must return machine-readable responses for automated systems, not just a webpage. It must support multiple link types: one for the DPP data, one for consumer product information, one for regulatory compliance documentation. It must return the right response based on who is asking. A consumer scan gets something different from a regulatory authority query. That context-based routing is link type negotiation and it is part of the GS1 Digital Link specification.
The DPP link type must resolve to structured data. Not a PDF. Not an HTML page. Machine-readable, parseable data.
Most teams I talk to are planning to point a QR code at a webpage. That does not meet the resolver requirements. Building a compliant GS1 Digital Link resolver is a distinct engineering problem. It needs to be scoped and built separately.
Where Implementations Will Break
Not getting EPCIS events from suppliers. This is the most common failure point.
You can instrument your own operations in months. Your suppliers are a harder problem. They run different ERP systems. They may not have EPCIS infrastructure. Their sub-locations may not have GLNs. Getting them to emit EPCIS events, or even to provide data in a format you can convert, is a supplier onboarding project in itself.
A useful rule of thumb: assume the supplier data problem will take twice as long as your internal event capture. Build that into the timeline from day one.
GLN gaps breaking the event chain. An EPCIS event requires GLNs for every location referenced. If your Turkish cotton supplier does not have a GLN for their warehouse, the receiving event at your facility has an incomplete sourceList. The chain breaks.
Audit GLN coverage across your supplier base before you start capturing events. It is easy to fix early. Painful to fix mid-project.
Using EPCIS 1.2 instead of 2.0. The provisional standard specifies EPCIS 2.0. The identifier format changed: GS1 Digital Link URIs instead of EPC URNs. The serialization adds JSON-LD. Several CBV business step values differ.
If your current traceability system runs on EPCIS 1.2, you need a conversion layer or a migration plan. The openepcis-document-converter exists for this reason: it handles JSON-LD to XML conversion and EPC URN to GS1 Digital Link URI translation. But starting in 2.0 from the beginning is cleaner.
Treating the DPP as a document. Teams that start by designing a “DPP certificate” or “passport PDF” are building in the wrong direction. A DPP is a data service. The resolver serves it. The EPCIS events back it. The data carrier on the product is the access point. None of those three components is optional.
No linkage between DPP identifier and EPCIS EPCs. The DPP has an identifier. The EPCIS events have EPCs. The resolver has a URI. All three must be explicitly linked. A DPP that cannot be verified against its own EPCIS events is not compliant. Design the linkage model before you capture the first event.
The ESPR Enforcement Timeline
The EU DPP registry infrastructure goes live in July 2026. That is when product registration becomes possible.
2026: Iron and steel products begin pilot registrations.
February 2027: Battery passports become mandatory for all EV and industrial batteries over 2kWh sold in the EU. This is the closest hard deadline. Battery supply chains are among the most complex: multi-tier, global component sourcing, strict condition monitoring requirements.
Mid-2027: Textiles and tyres. Indian exporters are heavily exposed here. If you are exporting fabric to Germany, you need DPP-compliant products by this date.
2028 to 2030: Electronics, furniture, vehicles, and everything else.
The timeline compresses faster than it looks. The battery passport deadline is ten months out. If you are building battery passport infrastructure from scratch today and have not started supplier onboarding, you are already behind on the hardest part.
Four regulations are converging on the same technical stack. ESPR for product ecodesign. EUDR for deforestation-linked supply chains. CSRD for sustainability reporting. The Battery Regulation for battery-specific traceability. All of them ultimately need EPCIS event data and GS1 Digital Link for product identification. This is the same interoperability thesis playing out across regulatory mandates. Build the foundation right once. Build it for one regulation at a time and you will rebuild it four times over.
What We See from the Build Side
I am an engineer. Not a compliance consultant. What I know about DPP requirements I know from building systems for them.
Our platforms are built on OpenEPCIS, the open-source EPCIS 2.0 repository led by benelog GmbH, to which Brevitaz is a core contributor. We played the primary role in architecting, designing, and building the backend for a Food Traceability Platform operated by GS1 Germany and Benelog GmbH, running across 770+ enterprises in Europe. The DPP technical requirements are things we designed systems around before the provisional standard was published.
If I were starting a DPP build today, here is where I would focus:
Get your EPCIS 2.0 repository in place first. Everything else sits on that foundation.
Start the GLN audit of your supplier base in parallel. Do not wait until your internal capture is working. The supplier data problem has a longer tail than the technical work.
Build the resolver for link type negotiation from the start. Retrofitting it later is much harder than designing for it upfront.
Define the DPP-to-EPCIS linkage model before you capture the first event. The data model decision affects everything downstream.
The provisional standard is well-specified. It gives you enough precision to build against. The challenge is not understanding what it requires. The challenge is the operational lift of getting a multi-tier supply chain to actually produce the data.
My honest prediction: companies that have already started the supplier onboarding work will make the battery passport deadline. Companies starting from scratch today have a real chance for textiles in mid-2027 if they move fast. The ones treating this as a “wait until the mandate lands” problem will be scrambling in Q4 2026.
If you are on the implementation side right now: what is the hardest part of getting event data out of your supplier base? The pattern we keep running into is not the technology. It is master data. Missing GLNs, inconsistent lot numbering across tiers, no single owner of the GS1 data registry at the supplier. What are you seeing?
