GS1 Standards for the Global Traceability Framework: Technical Application
Part 2 of a two-part guide, for implementers: the GS1 identification keys, the EPCIS event types mapped to common core CTEs, and how master data and event data are actually shared between trading partners.
Effective digital traceability depends on a few foundational elements: the ability to uniquely identify products and locations, a consistent structure for recording data, and reliable mechanisms for sharing that information across partners. Without these building blocks, traceability data risks being fragmented, inconsistent, or unusable across systems. This resource provides a practical explanation of how GS1 standards are used to bring these elements together to support the Global Traceability Framework for Beef and Leather (GTFBL). It outlines the role of identification, data structure, and data exchange protocols, showing how they work in combination to enable interoperable traceability. While not highly technical, this resource is designed for practitioners in technical or implementation roles who need to understand the mechanics of GS1 standards in action.
Identification
Being able to uniquely identify objects and locations is one of the foundational building blocks of traceability. Without a reliable way to distinguish between products, batches, or facilities, it becomes nearly impossible to track movements or link events across different stages of the supply chain.
Why identifiers matter
In terms of traceability, identifiers answer key questions:
- What is the product, lot, or shipment?
- Where did an event take place?
- Who:
- Owns the product?
- Has custody of the product?
- Is providing the traceability data?
GS1 standards provide a set of globally recognized identifiers—known as GS1 Identification Keys—that can be assigned to products, locations, and logistical units. While some organizations use internal IDs, these are often not compatible or recognizable outside their own systems. In contrast, GS1 Identification Keys are standardized and globally unique, meaning they can be shared across and between organizations without risk of duplication or confusion. Their consistent global structure ensures interoperability across supply chains, regardless of geography, commodity, or software platform. This enables supply chain partners to exchange and interpret data consistently, which is essential for end-to-end visibility.
These identifiers are universally unique and are compatible across industries and geographies.
Common GS1 Identification Keys
- GTIN (Global Trade Item Number) – Identifies a specific product or trade item.
- GLN (Global Location Number) – Identifies a physical location (e.g. processing facility) or an organizational entity (e.g., a processing company
- with multiple locations).
- SSCC (Serial Shipping Container Code) – Identifies a specific logistics unit, such as a pallet or container, which may contain multiple trade items.
- EPC (Electronic Product Code) – Combines a product identifier (like a GTIN) with batch/lot or serial numbers to identify a specific instance of a product.
GS1 vs. non-GS1 identifiers
Using GS1 Identification Keys typically requires an organization to become a GS1 member and license a GS1 Company Prefix. This prefix forms the foundation for all GS1 Identification Keys registered to that organization. For large companies—especially downstream supply chain actors with extensive product catalogs—this is often the most practical option. In many cases, major retailers require their suppliers to use GS1 GTINs for product identification.
However, this approach is not the only option. For smaller organizations, particularly upstream or first-mile actors, the cost of licensing a GS1 Company Prefix or purchasing individual GTINs may not be financially practical. In many cases, these businesses operate from a single location and manage only a few products, making a GS1 prefix unnecessary from a logistical standpoint.
GS1 standards allow for the use of non-GS1 identifiers which can easily be created for these circumstances.
The Global Directory for Standardized Traceability (GDST) built upon these standards to develop a standardized URN format for private industry identifiers. These identifiers still follow GS1's structural rules for uniqueness, meaning they can work alongside GS1-based systems. In simple terms, GDST identifiers act like “GS1-compatible” IDs—they can be used in EPCIS events and function within the GS1 Digital Link framework in the same way as a GTIN or other GS1 ID Key. While managing large volumes of these non-GS1 identifiers would be inefficient for bigger companies with many products and locations, they can be a cost-effective and practical solution for small upstream actors who need globally unique IDs without the ongoing costs of GS1 membership.
Data Modeling
A consistent, standardized event model is essential for establishing digital traceability across supply chains because it ensures that every actor records and shares information in the same predictable way. This standardization makes data interoperable, comparable, and useful from end to end—regardless of the product, location, or system used.
GS1s EPCIS standard provides this structure by using a standardized “event vocabulary” to describe supply chain activities in a clear, uniform format. Instead of treating every data capture as a generic record, EPCIS organizes information into four core event types, each designed for a specific type of real-world activity:
- Object Event – captures what happens to one or more items (identified objects) at a given time and place (e.g., receiving, shipping, or moving cases in a warehouse).
- Aggregation Event – records when items are grouped together or separated (e.g., packing products into a carton or breaking down a pallet).
- Transformation Event – captures when inputs are changed into outputs (e.g., processing raw ingredients into finished goods).
- Transaction Event – links physical objects or events to a business transaction (e.g., a purchase order or shipping manifest).
Each event type follows a consistent structure built around the what, when, where, and why of the event that illustrates what occurred. This approach ensures event data is machine-readable, interoperable, and meaningful across systems and organizations.
The GTFBL uses only three of the four core EPCIS event types: Object, Aggregation, and Transformation. The table below illustrates how these event types translate into common core CTEs and includes examples applicable to beef and leather supply chains.
EPCIS Event Type | Common CTE Name & Description |
Object An object event can be defined in three ways. An object ADD event describes an event in which a product is commissioned or added to the supply chain. An object DELETE event describes an event in which a product is decommissioned or removed from the supply chain. An object OBSERVE event describes an observation of the products associated with an event; the products are not coming into or out of existence. Often these products are being moved or inspected in some way. | Shipping (Object Observe) An event in which product is shipped from one physical location to another. Shipping events can occur internally (between facilities of a single organization) or externally (from one organization to another). Receiving (Object Observe) An event in which shipped product is received by the ship-to facility. Receiving events can occur internally (between facilities of a single organization) or externally (from one organization to another). Commission (Object Add) An event in which a new product instance is created/documented for the first time. These events typically occur in the far upstream steps of a supply chain. Decommission (Object Delete) An event in which a product instance is removed from a supply chain. These events typically occur when a product is consumed or must be removed from the supply chain due to damage or defects. |
Aggregation An aggregation event can be defined in two ways. An aggregation ADD event describes an event in which products are grouped together. An aggregation DELETE event describes an event in which previously grouped products are separated. | Aggregation (Aggregation Add) An event in which one or more distinct products are physically grouped together. Aggregation is always reversible, and usually performed for shipping, storage, or other logistical purposes, such as combining multiple cases on a pallet Disaggregation (Aggregation Delete) An event in which previously aggregated items are separated (e.g. breaking down a pallet into distinct cases) |
Transformation A transformation event describes an event in which product input(s) are transformed to create product output(s). | Transformation An event that involves irreversible changes to a products physical form (e.g. manufacturing, processing) or packaging (e.g. commingling, re-packing, re-labeling) |
Just as it is important to have a standardized event structure, it is equally important that events are populated with standardized, predictable Key Data Elements (KDEs).
In addition to the event structure, EPCIS works in tandem with GS1’s Core Business Vocabulary (CBV), a companion standard that defines consistent data attributes and values to populate these events. For example, EPCIS events will contain a “business step” (bizStep) attribute to describe the type of event that occurred. A shipping event will use the standardized CBV value “shipping” for its bizStep attribute, ensuring it is interpreted consistently across all systems—regardless of the company or software in use.
By combining a standardized event structure (EPCIS) with standardized data attributes and values (CBV), organizations can create traceability records that are both precise and interoperable, enabling seamless data exchange throughout beef and leather supply chains.
Data Sharing
Standardized, universal data-sharing protocols are essential for digital traceability because they allow different companies—and their different software systems—to exchange information in a consistent, predictable way. Without them, every trading partner connection would require a custom integration, multiplying cost and complexity across the supply chain.
Sharing traceability data involves the exchange of two types of data: master data and event data.
- Master Data – basic information about an organization and its products, suppliers, and customers that remains consistent over time (e.g. product description or facility location).
- Event Data – information generated by a product as it moves through its supply chain.
The GTFBL uses two GS1-based mechanisms standards for data exchange:
- EPCIS Query Interface – for retrieving standardized event data.
- GS1 Digital Link Resolver – for retrieving master data and locating the sources for event data.
Together, these tools enable interoperable “system-to-system” data exchange between trading partners, while giving organizations control over who can access their data and under what conditions.
How It Works
Locating the data source
A company receives a shipment and wants to see the product's traceability history. Using the product's unique identifier (like a GTIN + lot number), it sends a request to their suppliers GS1 Digital Link Resolver.
Think of this like looking up a website: you enter a known code, and the resolver gives you the “address” of the system that holds the data. The request includes a “link type” that signals what kind of data is needed. Two primary link types are used:
gs1:epcisreturns a link to the EPCIS Query Interface for event data.gs1:masterDatareturns a link to the master data for the identifier (e.g., product specs, location details) in GS1 Web Vocab JSON-LD format.
Requesting the product history
Once the address is found, the company can go directly to the source and query the EPCIS Query Interface to request the history of events for that product.
This request retrieves a list of standardized traceability events, structured according to the EPCIS 2.0 standard and formatted in JSON-LD.
These events show what happened to the product—such as when it was shipped, received, or transformed—and include relevant traceability data like dates and locations.
Filling in missing master data
Event data often references products or facilities using globally unique identifiers (GTINs, GLNs, PGLNs). If the event history mentions a product or location the company doesn't recognize, it can use the GS1 Digital Link again to pull up extra details—such as product specifications or facility information.
- For each unknown identifier, the requester queries the sender's Digital Link Resolver using
gs1:masterDatato retrieve the associated master data.
This ensures that the traceability record is not only complete, but also understandable.
Control access to sensitive data
Access to EPCIS data can be restricted using API keys or other security methods.
The company that owns the data controls access and typically shares it directly with trusted partners under agreed terms of use. This point-to-point sharing model protects sensitive commercial information while ensuring that only authorized parties can retrieve traceability data.
Why This Matters
This approach means every partner in the supply chain can:
- Access standardized, structured event data directly from the source.
- Eliminate the need for one-off data exchange formats with each trading partner.
- Preserve control over sensitive business information by granting access only to authorized parties.
- Support regulatory, certification, and customer information requests efficiently.
Key Insights
Digitized traceability is only as strong as the standards that support it. By adopting these globally recognized systems for identification, data structuring, and data sharing, supply chain actors can establish traceability systems that are not only interoperable, but also scalable and fit for future demands. While the technical components—like EPCIS, CBV, and Digital Link—may take time to implement, the use of standardized data exchange protocols significantly reduces the cost and complexity of sharing information across diverse partners and platforms.
How did we do?
GS1 Standards for the Global Traceability Framework: An Introduction
Event Data