Electronic Product Code Information Services, or EPCIS, is a GS1 standard for visibility data that records real-world business events involving identified objects as they move through processes, locations and organisations.
In one line: an identifier tells you what object you are talking about; EPCIS records what happened to that object, when, where and in what business context.
This is Article 40 in eduKateSG’s 100-article logistics authority build and completes Batch 10. The canonical parent remains How Logistics Works. Article 39 gave the logistics unit a unique identity through SSCC. EPCIS adds time: the object now has an event history rather than merely a name.
Reader Status and Scope
- Reader job: understand how logistics visibility moves from static identifiers to interoperable event records.
- Mechanism owner: event capture, object identity, event time, place, business context, aggregation, sensor/status information and cross-organisation exchange.
- Boundary: EPCIS does not itself create accurate physical observations. Scanners, RFID readers, sensors, applications and people generate evidence that can then be represented as EPCIS events.
- Evidence anchor: GS1’s current standards repository lists EPCIS 2.0.1 with Core Business Vocabulary 2.0.0; GS1 describes EPCIS as a visibility-data standard whose events record something that happened to objects in the real world.
Identity Without Events Is a Static Map
An SSCC can uniquely identify Pallet 123. That is valuable. But logistics immediately asks more questions.
- Was Pallet 123 packed?
- When did it leave the warehouse?
- Which dock handled it?
- Was it loaded onto the expected vehicle?
- Did it arrive at the destination hub?
- Was it received or rejected?
- Was it split into smaller units?
Those are event questions.
Identity answers “which object?” Event visibility answers “what has happened to it?”
EPCIS Is About Business Events, Not GPS Dots
Tracking is often imagined as a moving dot on a map. EPCIS is more structured.
An event can represent a meaningful business step such as receiving, shipping, packing, commissioning, aggregating, transforming or observing an object in a defined process context.
The question is not merely “where was it?” but “what business event occurred here?”
The Core Event Questions
GS1 describes an EPCIS event around several fundamental dimensions:
- What: which object, objects or quantities were involved?
- When: when did the event occur?
- Where: where did it occur or what location was involved?
- Why: what business step, disposition or context explains the event?
EPCIS 2.0 also expanded support for sensor and status information, allowing event records to carry evidence such as temperature or shock observations where the use case requires it.
EPCIS Does Not Require Every Object to Be RFID-Tagged
The “Electronic Product Code” name can make readers assume EPCIS belongs only to RFID.
It does not. EPCIS can represent events involving GS1 identifiers captured through barcodes, RFID or other applications.
This is why GS1 presents barcode, EPCIS and RFID as interoperable layers rather than competing systems.
Capture Technology and Event Semantics Are Different Layers
A barcode scan may observe SSCC 123 at receiving. An RFID portal may observe the same identity at a dock. A temperature sensor may report a condition. A warehouse application may know that the business step is “shipping”.
EPCIS provides a standard way to express the event meaning after those observations and business facts are assembled.
Scanner / reader / sensor → application interpretation → EPCIS event → shared visibility.
Object Events Record Something About Identified Objects
At a basic level, a logistics system may need to record that one or more identified objects were observed at a business step.
For example, a pallet identified by SSCC can be recorded as shipped from a distribution centre at a particular time and location.
The event connects identity, time, place and business meaning in one structured record.
Aggregation Events Record Parent–Child Structure
Logistics repeatedly groups objects.
Cartons are placed on a pallet. Pallets are loaded into a container. Individual items are placed into a tote.
An aggregation event can represent the relationship between a parent object and the child objects assembled beneath it.
This is particularly useful after SSCC, because the pallet can have one identity while the system still knows what identified objects belong inside it.
Disaggregation Should Be Recorded Too
If cartons are removed from a pallet, the digital relationship should change with the physical one.
A visibility history that records aggregation but not later separation can keep asserting that objects are together after the warehouse has physically split them.
The event model must follow the world rather than forcing the world to remain inside an old digital structure.
Transformation Events Record Input Becoming Output
Some processes do not merely move objects; they transform them.
Ingredients become a finished product. Bulk material becomes packaged units. Several inputs become a new output identity.
EPCIS includes event concepts for representing transformations so traceability can follow relationships between inputs and outputs rather than pretending every object persists unchanged forever.
Association Events Can Represent Longer-Lived Relationships
EPCIS 2.0 introduced AssociationEvent to represent associations that are not simply momentary packing relationships, such as an object being associated with another entity for a period of time.
The precise semantics belong to the standard and use case. The broader logistics lesson is that visibility sometimes needs to represent more than “seen at this point”.
Business Step Gives the Event Meaning
A scan at 10:03 tells us something was observed. The business step tells us what the organisation says was happening: receiving, shipping, loading, inspecting or another defined process.
Without that semantic layer, partners can exchange timestamps but still misunderstand the process state.
Disposition Describes the Object’s Business State
An object can be active, in transit, damaged, recalled, available for sale or in another business condition depending on the vocabulary and process.
Core Business Vocabulary, or CBV, helps standardise values used with EPCIS so different organisations do not invent incompatible words for common business meanings.
CBV Is Why “Shipped” Can Mean Something Shared
Two companies can both use the word shipped while meaning different internal milestones.
A controlled vocabulary reduces that ambiguity by defining standard business-step and disposition concepts that can be referenced consistently across EPCIS events.
The current GS1 repository pairs EPCIS 2.0.1 with CBV 2.0.0.
Event Time and Record Time Are Different
An event can happen at 09:00 and be entered into a system at 09:07.
That difference matters when reconstructing sequences. The real-world event time should not be silently replaced by the time the database happened to receive the record.
Late-arriving events are especially common when devices work offline or partner systems transmit in batches.
Event Order Can Be More Important Than Database Arrival Order
If a delivery event reaches the shared system before a delayed shipping event, naïve software may think the sequence is impossible.
Good visibility systems distinguish when the event happened from when the record arrived and reconstruct the physical sequence accordingly.
Location Needs a Shared Identity Too
“Warehouse 4” is clear inside one company and ambiguous outside it.
GS1 identifiers such as GLN can provide standardised location identity, allowing EPCIS events to reference business locations or read points in a way that partners can interpret.
Object identity and place identity therefore work together in visibility.
Sensor Data Adds Condition to Event Visibility
EPCIS 2.0 expanded the standard so events can carry sensor information such as temperature, shock or other measurements associated with an object or process.
This is valuable for cold chain and fragile cargo because location alone does not prove usable condition.
The standard can carry the evidence; the sensing system still has to be calibrated and trustworthy.
EPCIS Can Cross Organisational Boundaries
A supplier can capture packing and shipping events. A carrier can capture transport milestones. A receiver can capture arrival and receiving events.
When all parties use interoperable event semantics, a single object can accumulate a coherent history across companies instead of being reborn as a different private record at every handoff.
This is the event version of Logistics Handoffs.
Visibility Is Not the Same as Universal Data Sharing
Different partners have legitimate commercial, security and privacy reasons to restrict information.
EPCIS provides a standard representation. Governance still decides which events each partner is authorised to access.
Interoperability does not require indiscriminate openness.
More Events Can Make Visibility Worse
A network can capture millions of events and still be hard to understand if the events are duplicated, semantically inconsistent or unrelated to decisions.
Useful event design asks which state changes matter enough to support receiving, ETA, traceability, exception detection, recall, compliance or customer communication.
Event density should serve operational meaning rather than become telemetry for its own sake.
EPCIS Can Detect Contradictions
Suppose the system records Pallet A loaded on Truck 5 at 10:00 and later records it received at a location impossible to reach by 10:05.
That contradiction can indicate timestamp error, wrong identity, delayed data or a bad event.
Event history becomes more valuable when systems test physical plausibility instead of merely storing records.
EPCIS Does Not Repair a Wrong Scan
If an operator scans the wrong pallet and the application creates a perfectly valid EPCIS event, the standard has represented false evidence correctly.
This is the hostile boundary between data structure and physical truth.
Standards make information interpretable. They do not make observations infallible.
EPCIS at Three Zoom Levels
One event
Does the event truthfully connect the right object, time, place and business context?
One shipment history
Do events form a plausible sequence from packing through shipping, transfer, receiving and delivery?
One network
Can several organisations exchange enough standardised event data to track, trace and recover freight without forcing one company’s private status vocabulary onto everyone else?
A Singapore Lens
Singapore’s logistics role involves dense cross-organisational movement through port, airport, warehouses, carriers and regional distribution. Shared event semantics are valuable precisely because physical flow crosses so many independent systems quickly.
The mechanism is universal: once identity is standardised, event visibility can turn isolated scans into a chronology that supports ETA, traceability, exception detection and proof.
Hostile Test: “We Have End-to-End EPCIS Data, So We Have End-to-End Truth”
Check the observations underneath it.
Were objects identified correctly? Were timestamps trustworthy? Did devices capture the intended read zone? Did partners use compatible business-step meanings? Were missing events interpreted as failure or merely absent data?
EPCIS makes evidence interoperable. Truth still depends on how the evidence was produced.
EPCIS Audit
- Which identified object or quantity is involved?
- What real-world business event is being represented?
- Is event time distinct from record time?
- Is location identified consistently?
- Which business step and disposition apply?
- Are aggregation and disaggregation recorded when physical relationships change?
- Are sensor values tied to a trustworthy device and event context?
- Do partners use compatible CBV semantics?
- How are duplicate and late-arriving events handled?
- What access controls govern partner visibility?
- Can the event history detect contradictions or missing states?
- Does event capture improve a real logistics decision?
Evidence and Further Reading
GS1’s current EPCIS standard repository points to EPCIS 2.0.1, with associated normative artefacts and CBV 2.0.0. GS1’s EPCIS overview explains that EPCIS records real-world events for products, assets, documents and other objects and that EPCIS 2.0 supports sensor/status information such as temperature and shock.
Return to the Logistics Hub
EPCIS completes Batch 10: optical identity capture → radio identity capture → unique logistics-unit identity → interoperable event history. Return to How Logistics Works | How the Right Thing Reaches the Right Place at the Right Time to reconnect identity and visibility to the full logistics system.
Final compression: an identifier gives an object a name; EPCIS gives that name a history. The standard becomes useful when many organisations can describe real events with enough shared meaning that one shipment remains traceable even while custody, location and process keep changing.