Track and trace is the logistics capability to follow an identified shipment or object through its journey and reconstruct the sequence of events that explain where it is, where it has been and what happened along the way.
In one line: tracking asks for the latest useful state; tracing asks for the history that produced it.
This is Article 48 in eduKateSG’s 100-article logistics authority build and completes Batch 12. The canonical parent remains How Logistics Works. Articles 45–47 established regulatory state, custody history and delivery evidence. Track and trace ties those observations into one multi-actor journey.
Reader Status and Scope
- Reader job: understand how logistics visibility is built from identity plus events, and why a tracking page is only one presentation of that deeper system.
- Mechanism owner: stable identity, observations, event sequencing, current state, history, cross-partner exchange, exceptions and data gaps.
- Boundary: organisations use “track” and “trace” differently. This article uses a practical distinction—latest or forward state versus historical reconstruction—without claiming one universal legal definition.
- Evidence anchor: GS1’s Global Traceability Standard defines traceability as the ability to trace the history, application or location of an object, while EPCIS provides a standard event language for sharing what happened to identified objects across physical locations and organisations.
Tracking Is Not the Same as GPS
GPS is one possible source of location data. Track and trace is the wider information problem.
A container may have no GPS device and still be traceable through gate events, vessel loading records, terminal scans and delivery receipts. A parcel can be tracked through barcode scans at hubs without broadcasting its location continuously.
Visibility comes from meaningful observations, not from one specific sensor.
The system does not need to know where everything is every second; it needs enough trustworthy events to know what state the shipment is in and what should happen next.
Identity Is the Thread Through the Journey
Track and trace fails immediately if events cannot be tied to the same physical object.
A parcel number, SSCC, container number, serialised item or shipment identifier can act as the thread that connects observations across different organisations and systems.
This is why Batch 10 came first: barcodes, RFID and SSCC solve the object-identity problem before visibility tries to solve the time problem.
The Basic Track-and-Trace Chain
Identify object → capture event → timestamp → locate event → assign business meaning → share or store → compare with expected path → update current state → preserve history → detect exception.
A consumer tracking page may compress this into five friendly milestones. The operating system underneath can contain many more events.
Latest Observation and Current State Are Not Always the Same
Suppose the last scan occurred at Hub A at 09:00 and the truck departed at 09:10 without another scan.
The latest observation is “seen at Hub A at 09:00”. The inferred current state may be “in transit to Hub B”.
Systems should distinguish observed facts from inferred state so users understand what is known directly and what is predicted from the process.
Track Usually Looks Forward; Trace Usually Looks Backward
In practical logistics language, tracking often supports questions such as:
- Where is the shipment now?
- What milestone happened last?
- What is expected next?
- Is the shipment still on plan?
- What is the ETA?
Tracing often supports questions such as:
- Where did this unit come from?
- Which hubs handled it?
- Which pallet or container was it inside?
- Which lot or batch was involved?
- When did the first abnormal condition appear?
The same event history can support both directions.
GS1 Traceability Is Built Around Critical Tracking Events
GS1’s Global Traceability Standard introduces Critical Tracking Events, or CTEs: meaningful events such as receiving, packing, shipping and transporting that occur to a traceable object during its lifecycle.
Each event has Key Data Elements describing the actual occurrence.
This is stronger than storing a free-text status because the system can ask which event happened, to which object, at which time and location, involving which parties.
EPCIS Gives Events a Shared Language
EPCIS and Event Visibility explains the standard in detail.
For track and trace, the key value is interoperability. A supplier, warehouse, carrier and receiver can describe events using compatible structures rather than forcing one company’s internal status codes onto every partner.
GS1 explicitly describes EPCIS as supporting tracking and tracing across multiple physical locations and organisations.
Tracking Needs Business Meaning, Not Just Coordinates
A coordinate at a terminal tells us where a device or object was observed.
A business event can tell us that the container was discharged, received, loaded, inspected or released.
Those meanings matter because the next action depends on process state, not only geography.
Track and Trace Needs Place Identity
“Warehouse 4” may be meaningful inside one company and ambiguous across a network.
Standardised location identities such as GLN can help different organisations refer to the same site or location consistently.
The object thread and the place thread have to meet in each event.
Time Has More Than One Meaning
When did the event happen? When did the device record it? When did the partner transmit it? When did the receiving system ingest it?
Those timestamps can differ.
If a scan happens at 09:00 but reaches the shared platform at 09:20, the event is late-arriving data, not an event that happened at 09:20.
Good trace reconstruction preserves the physical event time separately from transmission or record time.
Missing Event Is Not Automatically a Missing Shipment
A scanner can fail. A partner integration can go offline. A driver can miss a scan.
The absence of an expected event lowers confidence but does not prove the physical shipment disappeared.
The system should distinguish “no evidence received” from “evidence of failure”.
Duplicate Events Can Distort the History
Retries and integrations can cause the same event to arrive more than once.
If the visibility system treats duplicates as separate physical events, counts and sequences become unreliable.
Track-and-trace architecture therefore needs event identity or deduplication rules, not merely storage capacity.
Out-of-Order Events Need Reconstruction
A receiving event can reach the central platform before a delayed shipping event from the origin system.
Database arrival order now differs from physical process order.
The system should use event time and process logic to reconstruct the most plausible chronology rather than assuming the newest message describes the newest physical state.
Aggregation Makes Tracking Efficient but Traceability Harder
Hundreds of cartons can be loaded onto pallets and pallets into containers.
Tracking only the container can be operationally efficient during the trunk journey. Tracing one carton later requires the system to know which pallet and container contained it at each relevant time.
GS1 traceability and EPCIS aggregation events support these parent-child relationships.
Deconsolidation Splits the Trace Path
When a mixed pallet is broken apart, the child units continue toward different destinations.
The event history should stop treating them as one physical bundle and preserve their separate downstream paths.
This is why traceability depends on accurate aggregation and disaggregation records, not merely scanning more often.
Track and Trace Supports Exception Detection
The planned route defines expected events and timing.
If a shipment was expected at Hub B by noon but no corresponding event appears and the last trusted observation is several hours old, the visibility system can surface the shipment as at risk.
This is where track and trace connects to Exception Management.
Track and Trace Supports ETA
ETA Prediction consumes current and historical event evidence.
A shipment that has completed a historically variable border process should receive a different arrival forecast from one that has not yet reached it.
Track and trace provides the state evidence; ETA converts that evidence into a future estimate.
Track and Trace Supports Recall
If a specific lot or serial range is recalled, traceability can help answer:
- Which warehouses received it?
- Which shipments contained it?
- Which customers received it?
- Which stock remains in the network?
That is the backward-and-forward power of a preserved event graph. Batch 15 will take recall logistics in full.
Track and Trace Supports Chain of Custody but Does Not Replace It
A visibility history can show locations and business steps while still omitting the exact physical custodian.
Chain of Custody requires enough control/possession evidence to identify who held responsibility through the handoffs.
The two systems reinforce each other without being identical.
Proof of Delivery Is the Final High-Value Trace Event
Proof of Delivery can close the outbound history with evidence tied to the receiver boundary.
The tracking page may show “Delivered”. The trace record should still retain the underlying object identity, event time, location and supporting delivery evidence required by the service.
Visibility Across Partners Needs Governance
Not every partner should automatically see every commercial detail.
Traceability systems need access control, data-sharing agreements, retention rules and a clear understanding of which partner is authoritative for each event.
Interoperability means information can be understood when shared. It does not mean all information is shared with everyone.
Customer Tracking and Operational Tracking Serve Different Jobs
A customer usually needs a clear milestone and a useful arrival expectation.
An operator may need carrier codes, exception reasons, terminal events, location identifiers and confidence states.
Both views can come from the same underlying event history while exposing different levels of complexity.
More Tracking Events Can Make the Experience Worse
A parcel page with twenty obscure internal scans can confuse the receiver without improving decision-making.
Operational systems can retain high-resolution evidence while customer interfaces compress it into meaningful states such as accepted, in transit, out for delivery, delivered or exception.
Visibility should be high-resolution underneath and legible at the surface.
Track and Trace at Three Zoom Levels
One object
Can the latest state and complete relevant history be tied to one persistent identity?
One route
Which events define normal progress, where are data gaps common and which missing states predict failure?
One network
Can several organisations exchange compatible event data without losing identity, chronology, authority or privacy?
A Singapore Lens
Singapore’s dense port, airport, warehouse and parcel networks make track and trace valuable because a shipment can change operational context several times over short physical distances.
The important transitions are not kilometres alone: discharged, released, collected, received, sorted, loaded, out for delivery and delivered can all happen inside a small geography while involving different organisations and responsibilities.
Hostile Test: “The Tracking Page Has No Gaps, So the Journey Is Fully Traceable”
Where did the statuses come from?
Were they actual scans, inferred milestones or carrier estimates? Do they refer to the same physical identity? Are aggregation relationships preserved? Are timestamps event times or message times? Can the underlying evidence be retrieved?
A smooth user interface can hide a weak evidence chain.
Track-and-Trace Audit
- What object identity persists through the journey?
- Which events count as critical tracking events?
- Which source produces each event?
- Is event time preserved separately from record time?
- Are places and parties identified consistently?
- Which states are observed and which are inferred?
- How are missing, duplicate and out-of-order events handled?
- Are aggregation and deconsolidation relationships preserved?
- Can the system trace backward as well as track forward?
- Does visibility support exception detection and ETA?
- Can the final POD evidence be retrieved?
- Are partner access and privacy rules appropriate?
- Does the visible status remain grounded in underlying evidence?
Evidence and Further Reading
GS1’s Traceability standards introduce Critical Tracking Events and Key Data Elements and connect identification, barcodes, RFID and EPCIS into interoperable traceability. The GS1 Global Traceability Standard provides the sector-neutral framework, while EPCIS & CBV provides a common event language for tracking and tracing objects across physical locations and organisations.
Return to the Logistics Hub
Track and trace completes Batch 12: regulatory release → custody history → delivery evidence → end-to-end event visibility. Return to How Logistics Works | How the Right Thing Reaches the Right Place at the Right Time to reconnect observability to physical execution.
Final compression: track and trace works when one stable identity accumulates trustworthy events across every meaningful handoff. Tracking turns that history into a current operational state; tracing turns the same evidence backward when the network needs to explain how the shipment got there.