An event answers what happened
An event is a record of activity affecting identified objects in a business context. Receiving a lot, consuming material, producing a batch, packing a case and transferring custody are different activities. A single generic “updated” timestamp cannot explain all of them.
Begin with the process questions you must answer. Then define which activities need records and which data makes each activity interpretable. Avoid recording every system action while overlooking the one transformation that connects inputs to outputs.
Use a clear event vocabulary
Agree on the meaning of receipt, dispatch, transformation and correction across teams. Specify what starts and ends each event, who can record it and which source system owns it. Record the relevant identities, event time, facility and business context.
Keep event occurrence time distinct from the time data was entered or received. Delayed upload should not make yesterday’s production appear to have happened today. Time zones and clock assumptions need explicit handling.
Separate event types from relationships
A receiving event establishes an observation or business activity. A transformation connects consumed inputs to produced outputs. A packing activity creates a containment relationship. A custody transfer links responsible parties. These relationships should be represented deliberately.
The educational trace on this site simplifies those ideas. It is not a standards-compliant payload or a complete schema. Use the official specification when designing a standards-based implementation.
Correct records without losing history
Operators can scan the wrong unit or enter a wrong quantity. Define a correction workflow that retains the original record, identifies the correction and explains the reason. A silent overwrite makes an investigation harder to reproduce.
Detect duplicates and retain a stable event reference. Repeated transmission of the same event should not look like two separate receipts. Offline capture also needs a clear reconciliation process when the connection returns.
Where EPCIS fits
GS1 EPCIS is a standard for sharing visibility event data between applications and organisations. EPCIS 2.0 includes models and interfaces for event capture and query. It provides a common exchange foundation; operational procedures and data quality still require implementation work.
Choosing EPCIS does not by itself prove that an origin is true or that a legal duty has been satisfied. Start with the interoperability mapping, then test that partners interpret the exchanged data consistently.
Frequently asked questions
Does every scan create a custody transfer?
No. A scan may be an observation or an internal handling activity. Record the actual business context and parties before interpreting it as a handover. Treat ownership, location and custody as distinct concepts where needed.
What if events arrive out of order?
Retain the event occurrence time, source and identity. Apply your reconciliation rules without assuming upload order is the physical sequence. Investigate contradictory records rather than silently rearranging them into a plausible history.
Sources and scope
Primary references checked on 4 October 2026. The process examples and implementation suggestions are editorial guidance. Formal standards are distinct from legal requirements.