EPCIS 2.0 Explained for Developers

What EPCIS actually models

EPCIS answers four questions about every event in a supply chain: what, when, where and why. What object or objects were involved. When it happened, including both the event time and the time zone in which it was recorded. Where it happened, expressed as a location identifier. And why, meaning the business step and disposition — was this a shipping event, a receiving event, an inspection, and what state did the object end up in.

That framing is more useful than it first appears, because it separates the physical facts from any particular company's interpretation of them. Two organisations with completely different internal systems can exchange EPCIS events and understand each other, which is the entire point of having a standard rather than an integration.

For Digital Product Passport work, EPCIS supplies the lifecycle history that the passport presents. The passport says what a product is; the event stream says what has happened to it and where it has been.

The four event types

Object events are the workhorse: something happened to one or more objects. Received, shipped, inspected, destroyed. Most of the volume in any real EPCIS implementation is object events, and they are straightforward to model correctly.

Aggregation events describe containment — cases onto a pallet, items into a case. They record a parent and its children, and they matter because they let you reason about a shipment without tracking every individual item through every step. Disaggregation is the same event type with a different action.

Transaction events link physical objects to business documents such as a purchase order or invoice. Transformation events, added as a first-class concept, describe inputs being consumed to produce outputs — several raw materials becoming one manufactured item. Transformation is where most implementations get into difficulty, and it is worth modelling first rather than last.

Why transformation events are the hard part

In a simple distribution chain, an object retains its identity from manufacture to sale, and traceability is a matter of following one identifier. Manufacturing breaks that. Three input batches are consumed and one output batch appears, and the output is not any of the inputs — it is a new thing with its own identifier and a documented relationship to what produced it.

Modelling this correctly matters because it is precisely where traceability queries either work or fail. A recall on an input batch needs to identify every output that consumed it, which requires the transformation to have been recorded with both sides of the relationship. Implementations that record only inputs, or only outputs, produce a chain that looks complete and breaks under exactly the query it was built for.

The practical advice is to model your hardest transformation first, before building any infrastructure. If your event model can represent a partial batch consumed across two production runs with a byproduct, it can represent everything else. If you start with simple shipping events, you will build something that needs restructuring when manufacturing arrives.

Implementation notes that save time

• Use the JSON-LD binding rather than XML unless a partner specifically requires otherwise
• Record event time and record time separately, because they diverge and auditors ask about the gap
• Include the time zone offset explicitly rather than normalising everything to UTC on ingest
• Model transformation events before object events, since they constrain the rest of the design
• Use standard business steps and dispositions rather than inventing your own vocabulary
• Treat events as immutable, and correct errors with compensating events rather than updates
• Test the query interface against a partner implementation before declaring the work finished

The query side is half the standard

Teams frequently implement capture, declare success, and then discover that nobody can actually get anything useful out. EPCIS defines a query interface as well as a capture interface, and the query side is what determines whether the event data has any value to anybody outside the system that produced it.

The queries that matter in practice are trace-forward and trace-backward from a given identifier, and events within a time window at a given location. If those are slow or unavailable, your traceability system is a write-only archive. Designing indexes for them at the start is considerably cheaper than retrofitting once the event volume is large.

Interoperability testing belongs here too. A capture interface tested only against your own client will accept exactly what your client sends and reject perfectly valid events from a partner. Validating against an external conforming implementation before launch is the single most effective way to avoid a painful integration phase later.

Part of the Circular Economy & Digital Product Passports cluster · Read the pillar page