Skip to main content

GTF Concepts: CTEs and KDEs Explained

A plain-language guide to the core traceability concepts behind the GTF: Critical Tracking Events, Key Data Elements, the difference between event data and master data, and which supply chain actors are responsible for recording what.

This section explains how the GTF requirements apply in practice. It provides additional context for Critical Tracking Events (CTEs), Key Data Elements (KDEs), roles and responsibilities, and the relationship between event data and master data.

Critical Tracking Events (CTEs)

Building a Traceability History

Every product follows a unique journey through the supply chain. It may be harvested or manufactured, transported between facilities, combined with other materials, transformed into new products, repackaged, distributed, and eventually removed from the supply chain.

The purpose of event-based traceability is to document this journey in a consistent manner.

The GTF accomplishes this by recording information whenever a significant supply chain activity occurs. These activities are referred to as CTEs.

Rather than documenting an entire supply chain as a single record, event-based traceability creates a chronological history of discrete business events. Each event captures what happened to a product at a specific point in time and provides a link to the events that occurred before and after it.

Why Critical Tracking Events?

Supply chains generate many types of events throughout normal business operations. Some of these events establish or preserve traceability, while others support quality management, inventory control, regulatory compliance, sustainability programs, or other operational objectives.

The GTF does not seek to standardize every type of supply chain event. Instead, it identifies a foundational set of CTEs that are broadly applicable across supply chains and that establish the minimum information required to create an interoperable traceability history.

By standardizing only this common foundation, the GTF remains broadly applicable while allowing Modules to define additional event types that support the needs of specific commodities, regulatory programs, sustainability initiatives, or other business requirements.

Examples of non-GTF events may include:

  • product inspections
  • quality assurance activities
  • inventory counts
  • laboratory testing
  • environmental monitoring

These events may provide significant business value and may be recorded within a traceability system when appropriate.

This approach balances consistency with flexibility. Organizations share a common language for recording the events essential to interoperable traceability while remaining free to capture additional information that supports their own operational objectives.

A Common Language Across Supply Chains

Although supply chains differ significantly, many operational activities are fundamentally similar.

For example: harvesting fish, harvesting crops and mining minerals all represent the creation of a new traceable product.

Similarly, shipping seafood, shipping pharmaceuticals and shipping packaged foods all represent the movement of products between locations.

The GTF therefore defines common event types that describe these universal business activities.

Modules then interpret these events within their own operational context.

This common language enables organizations operating in different industries to exchange traceability information using a consistent structure.

Key Data Elements (KDEs)

Describing Supply Chain Events

Critical Tracking Events establish when information should be recorded. Key Data Elements define what information should be recorded.

Every event answers a common set of questions:

  • What product was involved?
  • What activity occurred?
  • When did it occur?
  • Where did it occur?
  • How much product was involved?

Collecting this data consistently allows traceability information to be exchanged and interpreted across organizations regardless of the technology being used.

Why Standardized KDEs Matter

Different organizations often describe identical activities differently.

One organization may refer to a "processing plant” while another may call it a "factory” or "Plant 12."

Without common data definitions, these differences create ambiguity that prevents automated interpretation.

The GTF addresses this challenge by defining a common set of foundational KDEs that establish a consistent description of supply chain events.

Modules may introduce additional KDEs where needed, but they continue to share this common foundation.

Two Types of Traceability Data

Event-based traceability relies upon two complementary categories of KDEs: event data and master data.

Although closely related, these serve different purposes within a traceability system.

Event Data

Event Data records activities that occur throughout the supply chain.

Each event captures information describing a specific business activity, including the products involved, where the activity occurred, and when it took place.

Event Data continually grows as products move through the supply chain.

Master Data

Master Data provides descriptive information about the entities referenced within Event Data.

Rather than repeatedly recording KDEs such as product descriptions or facility addresses within every event, Event Data simply references standardized identifiers.

Master Data supplies the information associated with those identifiers.

Examples include:

  • product descriptions
  • product classifications
  • location names
  • facility addresses
  • organizational information

Separating Master Data from Event Data reduces duplication while ensuring consistent information across all events.

Integrating CTEs & KDEs

Products Create Histories

An important characteristic of event-based traceability is that products accumulate histories rather than carrying all information with them.

No single event contains every piece of information about a product. Rather, each new event contributes another piece of information to the product's overall genealogy.

For example:

  • A Commission event records that a product was created.
  • A Shipping event records where it was sent.
  • A Receiving event records where it arrived.
  • A Transformation event records how it was processed.

Together these events create a complete digital history.

Rather than replacing previous information or duplicating it at every point in the supply chain, each organization records only the events it performs. Together, these events form a connected history that can be reconstructed whenever needed.

This distinction is fundamental to interoperable traceability.

A common misconception is that every organization must receive, store, and retransmit the complete history of every product it handles. Under such an approach, the amount of data associated with a product would continually increase as it moves through the supply chain, resulting in significant duplication of both data storage and data exchange.

Instead, event-based traceability distributes information across the organizations that create it. During normal business operations, trading partners exchange only the information necessary to support the transaction taking place—for example, shipping and receiving events associated with a product transfer.

When a complete product history is required—such as during a traceback investigation, product recall, regulatory inquiry, or sustainability assessment—authorized users can retrieve the relevant historical events at that time.

By connecting these events, the complete product history can be reconstructed without requiring every trading partner to permanently store or continually exchange the full history of every product.

This distributed approach reduces unnecessary duplication, limits the routine exchange of business-sensitive information, and allows organizations to maintain ownership of the data they generate while still supporting end-to-end traceability across interoperable systems.

Roles & Responsibilities

Recording Information at the Source

A fundamental principle of the GTF is that organizations record the activities they perform.

Rather than requiring downstream organizations to recreate or infer historical information, each supply chain participant records the events for which they are directly responsible.

For example:

  • Producers record production events.
  • Processors record transformation events.
  • Distributors record shipping events.
  • Receiving facilities record receiving events.

This distributed approach improves data quality because information is captured at its source by the organization performing the activity.

Multiple Operational Roles

Responsibilities are therefore determined by operational activities rather than organizational type. Organizations often perform more than one operational role.

For example:

  • A processor may also operate distribution facilities.
  • A producer may perform primary processing.
  • A retailer may operate centralized distribution centers.

In these situations, organizations record every GTF CTE associated with the activities they perform.

GTF Concepts Takeaways

The GTF concepts introduced throughout this section work together to create an interoperable event-based traceability system.

Critical Tracking Events identify when traceability information should be recorded. Key Data Elements describe each event in a consistent manner.

Organizations record the events they perform, creating a distributed but connected history of product movement and transformation.

Event Data captures the activities that occur throughout the supply chain, while Master Data provides the descriptive information needed to interpret those events.

Together, these concepts establish the common language upon which the remainder of the GTF is built. Subsequent sections describe how internationally recognized standards and interoperable data exchange protocols implement these concepts within digital traceability systems.

How did we do?

Understanding the GTF Approach

GTF Technical Architecture

Contact