> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # What is EPCIS? > A vendor neutral explanation of EPCIS: the GS1 standard for recording and sharing product event data, how it differs from identifiers and ERP systems, its four event types, and why it matters for product traceability and Digital Product Passports. ## Executive Summary Most organisations can answer the question "what is this product?". Far fewer can answer the question "what happened to it?". The first question is settled by identification. A [GTIN](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) names a trade item, a serial number names an individual unit, and a [data carrier](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) delivers that value to a reader. None of that says where the item has been, who held it, what it was packed into, what it was transformed from, or whether it was repaired, resold or recycled. **EPCIS** is the GS1 standard that answers the second question. It defines a shared vocabulary and data structure for recording business events about physical objects, so that events captured by one organisation can be understood by another without a bilateral integration project. Each event records what happened, to which objects, when, where, and why in business terms. The distinction is the whole point of this article. [Identifiers](/docs/knowledge-base/glossary/product-identifier) identify. EPCIS records events. [Resolvers](/docs/knowledge-base/glossary/resolver) locate information. [Digital Product Passports](/docs/knowledge-base/glossary/digital-product-passport) may consume event data, but a passport is not an EPCIS repository and an EPCIS repository is not a passport. EPCIS matters now for a reason that has little to do with logistics efficiency. Regulation is shifting from static declarations to evidenced product histories: recycled content that must be substantiated, supply chains whose origin must be demonstrated, batteries and textiles whose lifecycle must be reportable. Those obligations are event obligations. An organisation that has only identifiers has a naming scheme. An organisation that has identifiers plus events has a history it can stand behind. * EPCIS is a GS1 standard for capturing and sharing business events about physical objects. - It records events, not products: what happened, to which objects, when, where, and why. - Identifiers identify; EPCIS records what happened to the identified thing. - There are four event types: Object, Aggregation, Transformation and Transaction. - Core EPCIS Data answers five dimensions: business step, location, time, actors and identifiers. - EPCIS is not an ERP, not a database schema for product master data, and not a Digital Product Passport. - Passports may consume EPCIS event data as evidence, but the two serve different purposes. - Event data only becomes traceability when every party in the chain records and shares it consistently. This is the eighth article in the Standards & Technology pillar and the eighteenth in the tieback Knowledge learning path. It follows [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier), which explains how identifiers reach the systems that then record events about them. Framework TBF-018 The Product Event Lifecycle Frames supply chain visibility as a sequence of what, when, where and why events recorded against a product. ## Table of Contents * [Definition](#definition) * [Why Product Events Matter](#why-product-events-matter) * [The Product Event Lifecycle](#the-product-event-lifecycle) * [How EPCIS Works](#how-epcis-works) * [The Four EPCIS Event Types](#the-four-epcis-event-types) * [Core EPCIS Data](#core-epcis-data) * [A Product Moving Through the Chain](#a-product-moving-through-the-chain) * [EPCIS Compared With Adjacent Concepts](#epcis-compared-with-adjacent-concepts) * [How EPCIS Supports Digital Product Passports](#how-epcis-supports-digital-product-passports) * [Benefits for Manufacturers](#benefits-for-manufacturers) * [Benefits for Supply Chains](#benefits-for-supply-chains) * [Benefits for Regulators](#benefits-for-regulators) * [Benefits for Consumers](#benefits-for-consumers) * [Common Misconceptions](#common-misconceptions) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition EPCIS, Electronic Product Code Information Services, is a GS1 standard that defines how organisations capture and share information about the movement and status of physical or digital objects. It specifies a common event data model, a shared business vocabulary and interfaces for exchanging those events, so that a record created in one organisation's systems carries the same meaning in another's. Three things follow from that definition and are worth stating plainly. First, EPCIS is about **events**, not objects. It does not hold the product master record. It holds statements of the form: at this moment, at this place, these identified objects underwent this business step, in this state, in the context of this business transaction. Second, EPCIS is a **shared** standard rather than an internal one. Its value comes from the fact that a receiving party can interpret an event without a bespoke mapping. An internal event log with private codes achieves none of that. Third, EPCIS is **vendor neutral**. It is a specification, not a product. It can be implemented on almost any technology stack, and the standard says nothing about who should host a repository. > **The one sentence version** > > A [product identifier](/docs/knowledge-base/glossary/product-identifier) tells you which thing you > are looking at. An EPCIS event tells you something that happened to that thing. ## Why Product Events Matter Identification alone supports commerce. Events support accountability. Consider what an organisation genuinely cannot answer with identifiers alone: * Which specific units of a contaminated ingredient batch reached which retailers. * Whether the recycled content claimed for a component was actually present in the input material. * Where in a chain of custody a shipment discrepancy first appeared. * Whether a returned item is the item that was sold, or a substituted one. * How many units of a model have been repaired rather than discarded. Every one of those questions is a question about history. Each is answered by joining events across organisations that do not share systems and frequently do not share commercial interests. Historically each pairing solved this bilaterally: a custom file format between a manufacturer and its largest customer, another between that customer and its logistics provider. The result is brittle, expensive, and impossible to aggregate. EPCIS exists to replace a network of bilateral formats with one shared grammar. #### Why bilateral formats fail A manufacturer supplies forty distributors. Under bilateral integration it maintains forty interface specifications, forty test cycles and forty change processes. Adding a fifth data point to the record means forty negotiations. Under a shared event standard it publishes one event structure that every counterparty already understands, and adding a data point is one change. There is also a regulatory driver. Product rules increasingly require substantiation rather than assertion. A declaration that a product contains recycled material is a claim; an evidenced chain of events from recovered feedstock to finished component is a demonstration. As [ESPR](/docs/knowledge-base/glossary/espr) delegated acts define what must be disclosed for each product group, the underlying question of who holds the evidence becomes an event data question. ## The Product Event Lifecycle Organisations new to EPCIS often start by asking what fields they must populate. That is the wrong starting point. The right one is to map where in a product's life something meaningful happens, and then to decide which of those moments must be recorded and shared. **The Product Event Lifecycle** describes the seven stages at which almost every physical product generates events worth capturing. It is deliberately generic: a food item, a garment, a battery and an industrial pump all pass through the same shape, with different intensities at different stages. The framework makes one structural claim, and it is the claim that makes EPCIS comprehensible: **the product identifier stays constant across all seven stages, while a new event is recorded at each one**. EPCIS does not store the product. It stores the trail the product leaves. Production Distribution Ownership and Use S1 Product Created Identity begins The item comes into existence as a distinct object and receives its identifier. The first event is a commissioning event: this identifier now refers to a real thing, made here, at this time, from these inputs. Everything recorded later hangs from this point. S2 Packed Containment The item is placed into a case, pallet or container that has its own identifier. This is a relationship event rather than a movement: it states that for a period of time, these children belong to that parent, so that scanning the parent later reveals the contents. S3 Shipped Custody leaves The objects depart a location under a business transaction such as a despatch advice or purchase order. The event records the destination and the transaction reference, which is what later allows a discrepancy to be located rather than merely detected. S4 Received Custody arrives A different organisation records the counterpart event at its own location. The pair of shipped and received events, written independently by two parties about the same identifiers, is the atom of supply chain visibility. S5 Sold Ownership transfers The item leaves the commercial chain and enters private ownership. For recall and warranty purposes this is the boundary event: everything before it can be reached through business partners, and everything after it depends on the holder. S6 Used / Serviced Life in service Inspections, repairs, part replacements, resales and transfers all generate events about an item that is no longer in the supply chain. Historically this stage was invisible; durability and reparability obligations are what make it worth capturing. S7 Recovered / Recycled Identity ends or transforms The item is collected, dismantled or reprocessed. Its identity is either retired or consumed as input to something new, which is a transformation: outputs with fresh identifiers, linked to the inputs that produced them. The trail continues into the next product. Identifiers identify products. EPCIS records what happened to them. The identifier is constant down the whole column; each stage adds an event, never a replacement identity. Two observations follow. The lifecycle is a **loop, not a line**. Stage seven feeds stage one of another product, and it is that link, expressed as a transformation, that lets a recycled content claim be traced back to a recovery event rather than asserted on a specification sheet. The lifecycle is **distributed**. No single organisation observes all seven stages. This is not an implementation inconvenience to be engineered away; it is the reason a shared standard is necessary at all. #### Map the lifecycle before choosing fields Before evaluating any implementation, list the events your organisation actually observes, the events your counterparties observe, and the questions you are obliged to answer. The intersection of those three lists is your scope. Teams that skip this step invariably capture large volumes of events nobody ever queries while missing the two that a regulator asks about. ## How EPCIS Works Mechanically, EPCIS has three parts: capture, storage and query. **Capture.** Something happens in the physical world and is observed, usually by a scan of a data carrier, sometimes by a manual confirmation or a machine signal. The capturing system converts that observation into an event that conforms to the standard, and submits it to a repository. **Storage.** A repository holds events as an append-only history. Events are statements about the past and are not edited. If an event was wrong, a correcting event is recorded; the original stays, because an audit trail that can be rewritten is not an audit trail. **Query.** Consuming systems ask questions of the repository: give me every event for this identifier, or every event at this location in this window, or the history of the parent that contained this child. Access is governed, because event data is commercially sensitive and reveals volumes, partners and timing. Around those three parts sits the **Core Business Vocabulary**, a companion standard that supplies the agreed values for business steps and object states. Without it, one party writes "shipped", another writes "DESPATCH", and the shared grammar is lost at the last step. The vocabulary is what turns a structurally valid event into a semantically comparable one. #### Treating EPCIS as a message format EPCIS is frequently reduced to "an XML or JSON file we send". A file is the visible artefact, but the substance is the shared meaning: agreed business steps, agreed location identifiers, agreed object states. Two organisations exchanging structurally perfect events with private vocabularies have achieved integration without interoperability. ## The Four EPCIS Event Types EPCIS deliberately keeps its event vocabulary small. Four types cover virtually everything that happens to a physical object, and the discipline of the standard lies in resisting the urge to add more. ### Object Events An Object Event says something happened **to** one or more identified objects. Commissioning a newly made unit, observing a case at a reading point, despatching a pallet, receiving a shipment, decommissioning a recovered item: all are Object Events, distinguished by their business step and disposition. This is the workhorse type. In most implementations it accounts for the large majority of records. #### Object Event in plain language At 09:14 on Tuesday, at the finished goods reading point of the Lyon plant, serial numbers ending 0001 through 0500 of a given GTIN were commissioned as active inventory. ### Aggregation Events An Aggregation Event records **containment**: a set of child objects being associated with, or disassociated from, a parent container. Packing units into a case, cases onto a pallet, pallets into a container are all aggregations; unpacking is a disaggregation. Aggregation is what makes large scale traceability affordable. Once children are aggregated to a parent, subsequent movements can be recorded against the parent alone, and the contents are inferred from the aggregation. Scanning one pallet identifier at a dock stands in for scanning a thousand units, provided the aggregation was recorded correctly in the first place. > **Aggregation is a relationship, not a location** > > Packing does not move anything. An Aggregation Event asserts a parent and child relationship over > a period of time. Where those objects then travel is recorded by later Object Events against the > parent. ### Transformation Events A Transformation Event records that a set of input objects **ceased to exist as such** and a set of output objects came into being. Milling grain into flour, assembling components into a finished appliance, blending recovered polymer into a new moulding, cutting fabric into garments: inputs are consumed, outputs are created, and the link between them is the event. This is the type that matters most for material claims. Recycled content, origin and composition statements are only defensible where the transformation chain is recorded. Without transformation events, a chain of custody stops at every factory gate. ### Transaction Events A Transaction Event associates objects with a **business transaction**: a purchase order, an invoice, a despatch advice, a returns authorisation. It links the physical world to the commercial one. Transaction association is often also carried inside Object Events as context. The distinct event type exists for the cases where the association itself is the fact being recorded, such as assigning already-observed stock to an order. | Event type | Question it answers | Typical trigger | | -------------- | --------------------------------------- | ---------------------------------- | | Object | What happened to these objects? | A scan at a reading point | | Aggregation | What is inside what? | Packing, palletising, unpacking | | Transformation | What became what? | Manufacturing, blending, recycling | | Transaction | Which commercial document applies here? | Order allocation, despatch, return | ## Core EPCIS Data Whatever the event type, EPCIS answers a fixed set of dimensions. A useful mental model is that every event is a sentence with obligatory parts, and a missing part makes the sentence unusable rather than merely incomplete. ### Business Steps The **why** in business terms: commissioning, packing, shipping, receiving, inspecting, repairing, decommissioning. Business steps come from the shared vocabulary, not from local system codes. A disposition accompanies them, describing the resulting state of the objects: in progress, in transit, sellable, recalled, destroyed. The pair matters. "Shipped" plus "in transit" and "shipped" plus "recalled" are the same movement with entirely different consequences. ### Locations **Where** the event happened, and where the objects are headed. EPCIS distinguishes the read point, the specific place the observation occurred, from the business location, the place the objects are considered to be as a result. A scan at a despatch door is a read point; the business location after despatch may be in transit rather than the warehouse. Locations are expressed as governed identifiers rather than free text, for the same reason products are: two parties must be able to agree that they mean the same building. ### Time **When** the event occurred, recorded with a time zone offset. The distinction between event time and record time is important in disputes and outages: an event may be captured at the moment of scanning but transmitted hours later, and both timestamps are needed to reconstruct what was known when. ### Actors **Who** owns the event and who was party to it. Ownership matters for trust: the value of a received event lies partly in the fact that the receiving organisation, not the sender, asserted it. Actors are also the basis of access control, since event data exposes volumes and relationships that counterparties treat as confidential. ### Identifiers **What** the event is about. Objects are referenced by their governed identifiers, and this is the join between EPCIS and everything else in the identification stack: the [GTIN](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) with a serial or batch qualifier, the container identifier, the location identifier, the transaction reference. #### Governed identifiers are a precondition, not a detail EPCIS inherits the quality of the identifiers fed into it. Reused serial numbers, ad hoc location codes and internal-only product references produce event histories that cannot be joined across organisations. Fix identification first; event capture built on unstable identifiers records confusion at scale. ## A Product Moving Through the Chain The abstraction becomes concrete when one item is followed the whole way. Consider a single appliance, identified by a GTIN plus a serial number, and note that **the identifier never changes** at any point below. 1. **Manufacturer.** The unit is assembled from components and commissioned. A Transformation Event links the component inputs to the finished output; an Object Event commissions the serialised unit as sellable stock at the plant. 2. **Warehouse.** The unit is packed into a case and the case onto a pallet. Two Aggregation Events record the containment. An Object Event against the pallet records receipt into the distribution centre. 3. **Distributor.** The pallet is despatched under a purchase order. An Object Event with a shipping business step carries the destination and the transaction reference; the disposition becomes in transit. 4. **Retailer.** The retailer records its own receiving event at its own location. The pallet is disaggregated, cases are broken down, and the unit becomes individually sellable. 5. **Consumer.** The unit is sold. An Object Event marks the retail sale and the disposition changes to indicate it has left the commercial chain. 6. **Repair.** Three years later a service centre replaces a part. An Object Event records the repair business step against the same serialised identifier, and a further event records the replacement component fitted. 7. **Recycling.** At end of life the unit is collected and dismantled. A Transformation Event consumes the unit and produces recovered material outputs with their own identifiers, so the recovered fraction can be traced into whatever is made from it next. Seven organisations, seven systems, one identifier, and a history that no single participant holds in full. That is the shape of real traceability, and it is why the standard exists. #### Expecting one organisation to hold the whole chain Programmes routinely set out to build a complete product history inside a single system. It cannot be done: most events occur in organisations you do not control. The achievable goal is that your own events are complete, correctly identified and shareable, and that you can query the events others share with you. ## EPCIS Compared With Adjacent Concepts Three comparisons remove most of the confusion in practice. ### EPCIS vs Product Identifier | Dimension | Product Identifier | EPCIS | | ----------------- | ------------------------------- | ------------------------------------ | | Purpose | Names the thing | Records what happened to the thing | | Nature | A value | A stream of timestamped statements | | Changes over | Never, for the life of the item | Constantly, as events accumulate | | Held by | Anyone who reads the carrier | Each party that observed an event | | Answers | Which product is this? | Where has it been and what was done? | | Without the other | Identity with no history | Events about nothing identifiable | The last row is the practical point: the two are useless apart. An identifier with no events is a label. Events without governed identifiers cannot be joined to anything. ### EPCIS vs ERP | Dimension | ERP | EPCIS | | ------------- | -------------------------------------- | -------------------------------------------- | | Scope | One organisation's business processes | Events shared between organisations | | Data model | Vendor and configuration specific | Standardised and vendor neutral | | Optimised for | Transactions, planning, finance | Observations of physical objects over time | | Granularity | Usually quantities and stock positions | Individual objects, containers and instances | | Mutability | Records are updated in place | Events are appended, never rewritten | | Audience | Internal users | Internal users and external counterparties | EPCIS does not replace an ERP and rarely competes with one. In most architectures the ERP remains the [system of record](/docs/knowledge-base/glossary/system-of-record) for commercial process, while events are captured alongside it and shared outward. Attempting to expose ERP tables directly to partners reproduces the bilateral integration problem the standard exists to remove. ### EPCIS vs Digital Product Passport | Dimension | EPCIS | Digital Product Passport | | ------------ | ---------------------------------------- | ------------------------------------------------- | | Purpose | Record and share business events | Present governed product information to audiences | | Content | What happened, where, when, why, to what | Composition, compliance, durability, care, origin | | Audience | Trading partners and internal systems | Consumers, repairers, recyclers, authorities | | Access | Restricted and commercially sensitive | Tiered, with a public layer | | Time posture | Historical, append-only | Current state, with history where required | | Relationship | May supply evidence to a passport | May consume event data as evidence | A passport is a presentation and access obligation. EPCIS is an evidence infrastructure. A passport that shows a recycled content figure may be substantiated by transformation events; it does not publish the underlying event stream, and it should not, because that stream exposes commercial detail that no regulation asks to be made public. ## How EPCIS Supports Digital Product Passports The connection runs through evidence rather than through display. A passport typically asserts things that are only defensible with history: that a product contains a stated proportion of recycled material, that its components originate where claimed, that it has a documented service record, that a batch is or is not affected by a safety notice. Each assertion is the summary of a set of events. The architecture that results has four distinct roles, and conflating any two of them causes problems later: * **Identifiers** identify the object. See [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier). * **Data carriers** deliver the identifier to a reader. See [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier). * **Resolvers** turn a scanned identifier into the right destination for the requester. See [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link). * **EPCIS** records what happened to the object, and can supply evidence behind passport content. Identifiers identify. Data carriers transport. Resolvers locate. EPCIS records events. Digital Product Passports present governed information to defined audiences, and may draw on event data as evidence without being an event repository themselves. Three consequences deserve emphasis. **A passport is not an event feed.** Publishing raw event streams to consumers would be both commercially damaging and unhelpful. What reaches a passport is derived: an aggregate, a status, a date, a provenance statement. **Event data usually stays where it was captured.** Passport content can reference or summarise it under governed access rather than copying it into a public surface. **Passports are point-in-time presentations; events are the ongoing record.** Where a passport is published as an immutable snapshot, later events do not silently rewrite it. The relationship is that new evidence justifies a new publication, not that the published artefact mutates. #### Building a passport programme before fixing event capture Passport content requirements almost always outrun the evidence available. Teams discover late that a claim they must publish depends on transformation events nobody records. Establishing which claims are event dependent, early, is the difference between a schedule and a scramble. ## Benefits for Manufacturers Manufacturers gain the ability to answer questions about their own output after it has left their control. * **Recall precision.** Affected units can be identified by batch, serial or aggregation membership rather than by model, which is the difference between withdrawing a pallet and withdrawing a product line. * **Substantiated claims.** Material and origin statements rest on recorded transformations rather than on supplier assertions that cannot be inspected. * **Warranty integrity.** Serialised histories distinguish genuine units from grey market or counterfeit ones presented for service. * **Yield and loss visibility.** Transformation events expose where material is lost between input and output, which is an operational benefit that frequently funds the programme. * **Reduced integration cost.** One standardised event structure replaces a portfolio of bespoke customer specific interfaces. ## Benefits for Supply Chains For chains as a whole, the benefit is that independent parties can build a joint picture without merging systems. * **Shipment reconciliation.** Independently written shipping and receiving events make discrepancies visible at the point they arise rather than at month end. * **Chain of custody.** Custody is demonstrated by paired events from separate organisations, which is materially stronger evidence than a single party's ledger. * **Aggregation efficiency.** Parent level scanning replaces unit level scanning at most handling points, with contents inferred from recorded aggregations. * **Diversion detection.** Products appearing at unexpected locations are visible because expected locations were recorded. * **Shared vocabulary.** New trading relationships start from an existing standard rather than a fresh negotiation. #### Where a discrepancy actually occurred A retailer receives 480 units against a despatch of 500. With only commercial documents, the dispute is a difference of opinion between two invoices. With events, the pallet was aggregated with 500 children, shipped intact, received at a cross dock, disaggregated there and reaggregated with 480. The location and time of the loss are in the record. ## Benefits for Regulators * **Evidence rather than attestation.** Compliance claims can be examined against recorded events instead of accepted on the strength of a declaration. * **Targeted market surveillance.** Investigations can start from the units actually implicated, narrowing scope and cost. See [market surveillance](/docs/knowledge-base/glossary/market-surveillance). * **Cross border consistency.** A standardised event model reduces the divergence of national reporting formats. * **Faster incident response.** Distribution of an affected batch can be established from existing records rather than reconstructed by correspondence. * **Auditable circularity.** Recovery and recycling claims can be checked against transformation events rather than volumes reported in aggregate. ## Benefits for Consumers Consumers rarely interact with EPCIS directly, and should not have to. The benefits reach them through what event data makes possible. * **Trustworthy provenance.** Origin and composition statements shown in a passport are backed by records rather than marketing copy. * **Effective safety notices.** Recalls that identify specific batches reduce both unnecessary alarm and missed units. * **Repairability in practice.** Service histories and component records help independent repairers keep products in use. * **Meaningful sustainability information.** Recycled content and durability claims become comparable when they rest on the same kind of evidence. * **Secondhand confidence.** A verifiable history supports resale value and reduces fraud in secondary markets. ## Common Misconceptions **"EPCIS is a database."** It is a standard: an event model, a shared vocabulary and interfaces. A repository implements it. The distinction matters when comparing suppliers, because conformance is to the standard, not to a product. **"EPCIS stores the product."** It stores events about the product. Master data lives elsewhere, and an event referencing an identifier is not a substitute for the record that identifier names. **"EPCIS replaces our ERP."** It does not. The ERP runs the business; EPCIS shares observations of physical objects across organisational boundaries. **"EPCIS is a Digital Product Passport."** It is not. A passport presents governed information to audiences; EPCIS records events. A passport may consume event data as evidence. **"Adopting EPCIS gives us traceability."** Traceability is a property of the whole chain. Your events plus no events from your partners produces a history with holes precisely where the interesting questions are. **"EPCIS is only for retail and food."** It is domain neutral. Pharmaceuticals, textiles, electronics, industrial equipment and materials recovery all use the same four event types. **"Every scan should become an event."** Volume is not value. Capture the events that answer obligations and operational questions; indiscriminate capture produces cost and noise. **"Events can be corrected by editing them."** They cannot, and the append-only posture is a feature. Errors are addressed by recording correcting events, leaving the original visible. **"EPCIS requires a specific carrier technology."** It is carrier agnostic. Events can originate from a linear barcode, a QR code, a Data Matrix, an RFID read or a manual confirmation. ## Frequently Asked Questions #### What does EPCIS stand for, and does the name still fit? Electronic Product Code Information Services. The name is historical, dating from work on the Electronic Product Code, and it understates the current scope: the standard applies to objects identified by any GS1 identification key, not only to items carrying an Electronic Product Code. Treat it as a proper noun rather than a description. #### What is the difference between EPCIS and a product identifier? A product identifier is a value that names a product or unit. EPCIS is a standard for recording events about identified objects. The identifier answers which item this is; EPCIS answers what happened to it. Identifiers stay constant while events accumulate around them. #### Do we need EPCIS to have a Digital Product Passport? Not necessarily. Passport obligations concern identification, a data carrier and accessible governed information. Where passport content includes claims that depend on product history, such as recycled content or chain of custody, event data becomes the practical way to substantiate them. Many organisations will start with identification and add event capture as evidence requirements bite. #### Who hosts EPCIS event data? The standard does not say. Events may be held by each organisation, by a service provider, or by an industry platform. What matters is that events conform to the standard, that access is governed, and that counterparties can query what they are entitled to see. Hosting is an architectural and commercial decision, not a conformance one. #### Is EPCIS data public? No. Event data reveals volumes, partners, timing and locations, and is treated as commercially confidential. Access is controlled and typically bilateral or consortium based. Anything a consumer sees is derived and published deliberately, usually through a passport or similar surface. #### How does EPCIS relate to the Core Business Vocabulary? The Core Business Vocabulary supplies the standard values used inside events, such as business steps and dispositions. EPCIS defines the structure; the vocabulary defines the meaning of the values placed into it. Both are needed for events to be comparable between organisations. #### What is the difference between an Object Event and an Aggregation Event? An Object Event states that something happened to a set of objects, such as being commissioned, shipped or received. An Aggregation Event states a containment relationship between a parent container and its children, such as units packed into a case. Movement is recorded by Object Events; containment by Aggregation Events. #### Where should an organisation start? Start with the questions you are obliged to answer, then work backwards to the events that answer them and the identifiers those events require. Confirm identification and location identifiers first, capture a narrow set of high value events well, and extend once counterparties are exchanging them reliably. Breadth before reliability is the common failure pattern. ## Key Takeaways * EPCIS is a GS1 standard for capturing and sharing business events about physical objects between organisations. - Identifiers identify products; EPCIS records what happened to them; resolvers locate information; passports present it. - The Product Event Lifecycle has seven stages, and the product identifier stays constant across all of them. - Four event types cover almost everything: Object, Aggregation, Transformation and Transaction. - Every event answers five dimensions: business step, location, time, actors and identifiers. - The Core Business Vocabulary is what makes structurally valid events semantically comparable. - EPCIS is not an ERP, not master data and not a Digital Product Passport, though a passport may consume its evidence. - Events are append-only; corrections are recorded as new events so the audit trail stays intact. - Traceability is a property of the chain, not of one participant, which is why a shared standard is required. - Event data is commercially sensitive; what reaches a public surface is derived and deliberate. ## Related Articles * [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain) * [QR Codes vs GS1 Digital Link: What's the Difference?](/docs/knowledge-base/standards-and-technology/qr-codes-vs-gs1-digital-link) * [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) * [What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) * [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) * [What is GS1?](/docs/knowledge-base/standards-and-technology/what-is-gs1) * [Who Needs a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/who-needs-a-digital-product-passport) * [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance) ## Related Glossary Terms Definitions of record for the terms used above live in the [glossary](/docs/knowledge-base/glossary/overview). * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Product Data](/docs/knowledge-base/glossary/product-data) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [GS1](/docs/knowledge-base/glossary/gs1) * [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) * [QR Code](/docs/knowledge-base/glossary/qr-code) * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Circular Economy](/docs/knowledge-base/glossary/circular-economy) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) ## References * GS1 EPCIS and Core Business Vocabulary standard, the primary specification for event data capture and sharing: [https://www.gs1.org/standards/epcis](https://www.gs1.org/standards/epcis) * GS1 EPCIS and CBV implementation guideline: [https://www.gs1.org/standards/epcis/epcis-cbv-implementation-guideline](https://www.gs1.org/standards/epcis/epcis-cbv-implementation-guideline) * GS1 traceability standards and guidance: [https://www.gs1.org/standards/traceability](https://www.gs1.org/standards/traceability) * GS1 identification keys, including the GTIN and location and container keys: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys) * GS1 General Specifications: [https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications](https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications) * GS1 Digital Link standard: [https://www.gs1.org/standards/gs1-digital-link](https://www.gs1.org/standards/gs1-digital-link) * GS1, the global standards organisation: [https://www.gs1.org](https://www.gs1.org) * International Organization for Standardization, ISO/IEC 19987 on the EPC Information Services specification: [https://www.iso.org/standard/66796.html](https://www.iso.org/standard/66796.html) * International Organization for Standardization, ISO/IEC 19988 on the GS1 Core Business Vocabulary: [https://www.iso.org/standard/66797.html](https://www.iso.org/standard/66797.html) * International Organization for Standardization: [https://www.iso.org](https://www.iso.org) * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, including battery passport and supply chain due diligence provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * European Commission, Ecodesign for Sustainable Products Regulation: [https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation\_en](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en) * EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu) ## About This Article About This Article
Last Reviewed
2026-08-08
Next Scheduled Review
2027-08-08
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## Related Docs * [Standards & Technology](/docs/knowledge-base/standards-and-technology/overview) * [What is a GTIN?](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) * [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) * [What is GS1 Digital Link?](/docs/knowledge-base/standards-and-technology/what-is-gs1-digital-link) * [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) * [What is a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-is-a-digital-product-passport) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) * [How Digital Product Passports Will Be Enforced](/docs/knowledge-base/regulations/how-digital-product-passports-will-be-enforced)