Designing Your EPCIS Event Model

Teams adopting EPCIS frequently expect it to tell them what to record. It does not. It tells them how to express what they have decided to record, which leaves the harder half of the problem with them.

What the standard actually gives you

An EPCIS event answers four questions about something that happened, and the discipline of the standard is that every event answers all four.

The fourth is the one that carries most of the meaning and the one most often filled in carelessly. A business step of shipping and a disposition of in transit say something specific; a local code meaning "left the plant" says something only your organisation can interpret.

Choosing which events to capture

The instinct to capture every scan produces a dataset that is expensive to store and difficult to query for anything useful. The better rule is to capture events where something changes that a downstream party would need to know.

• Custody changes — the object moved between organisations, which is what most traceability questions turn on.
• Transformations — inputs became outputs, and identity changed with them.
• State changes — the object was tested, repaired, graded or decommissioned.
• Aggregations — items were packed into a case, or a case onto a pallet, and later separated.

Intermediate movements within a single facility rarely earn their place. They are operationally useful and belong in a warehouse system, not in a record intended to be shared across a supply chain.

Granularity is the decision to get right

Whether events reference a product class, a batch or an individual serial number determines what questions the data can ever answer, and it is difficult to change retrospectively.

That said, serialisation carries real operational cost: marking, capturing, storing and reconciling identifiers at every step. The honest answer is that granularity should follow the questions the business genuinely needs answered, with a bias toward the finer level where the cost is close.

Vocabulary discipline is what makes events shareable

The Core Business Vocabulary provides standard values for business steps and dispositions. Using them is what allows a partner to interpret your events without a bilateral mapping document.

Local extensions are permitted and are frequently necessary, but every local term is a term somebody outside your organisation cannot interpret. The workable rule is to use CBV terms wherever one fits, and to treat reaching for an extension as a signal to check the standard vocabulary again first.

Where events meet the passport

A passport describes what a product is. Events describe what has happened to it. The two are complementary and the relationship between them needs deciding explicitly.

The fourth layer is worth designing deliberately. Current ownership is not usually stored as an attribute; it is the result of replaying custody events. Storing it as an attribute as well creates two sources of truth that will disagree.

Common mistakes worth avoiding

Three patterns recur across implementations and each is cheaper to avoid than to correct.

Recording event time as the time the record was created rather than the time the event occurred. EPCIS carries both fields precisely because they differ, and conflating them makes any latency analysis impossible.

Treating read point and business location as the same thing. A read point is where the capture happened; a business location is where the object is understood to be. A scan at a dock door is a read point, and the business location is the warehouse.

Emitting events without a stable identifier scheme behind them. Events referencing identifiers that are reassigned or reformatted between systems produce a history that cannot be reliably reassembled, which defeats the purpose of capturing it.