Shipment visibility: normalize events before adding an agent

A monitoring agent is governable only when every shipment change preserves identity, event time, source, vocabulary, and evidence; an ETA without that lineage is an opinion that is hard to audit. Before asking for predictions or summaries, an organization must make carrier, airline, warehouse, and sensor events refer to the same object without erasing who asserted what.

The problem is not a shortage of maps

Many control towers display a point and an estimated date. Difficulty begins when two parties report conflicting states, an update arrives late, or one event corrects another. When the dashboard overwrites the former value, operations loses the sequence needed to decide.

“Shipment” is not a sufficient identity either. It may mean booking, document, logistics unit, container, piece, flight, or leg. An alert must say which object changed and which relationship connects it to the outcome under control.

What three standards contribute—and do not solve alone

The GS1 EPCIS standard structures visibility through what, when, where, why, and how dimensions, supported by business-context vocabulary. It is useful for events involving physical or digital objects and chain of custody.

IATA ONE Record defines a common air-cargo data model, API, and security specification. Data remains at source and owners control access. Its single-record view is a linked shipment view, not an instruction to copy everything into one central database.

The DCSA Track & Trace standard provides processes, event structures, and APIs for container tracking across maritime phases. It supplies sector vocabulary for transport, equipment, and shipment events.

Each reduces ambiguity within its scope, but none automatically guarantees that a company links an air event to the correct internal order or preserves original evidence. That responsibility belongs to the operating layer.

A canonical logistics-event envelope

Do not force every message into one enormous schema. Create a small envelope and retain the original payload by reference.

Field	Function
event_id	identity of the received fact; supports deduplication
source_system and source_party	who published through which system
source_standard/version	EPCIS, ONE Record, DCSA, or another vocabulary
object_type/object_id	piece, logistics unit, container, shipment, or booking
occurred_at/timezone	when it happened in operations
received_at	when the platform learned it
event_type/business_step	canonical and original description
location_id	where it happened, including identifier system
related_objects	links to order, leg, document, and transport
evidence_ref	permitted original message, document, or reading
supersedes_event_id	explicit correction without erased history
confidence/origin	declared data, sensor, calculation, or inference

Separating occurred_at from received_at exposes latency and permits correct ordering. A later-received event can describe an earlier occurrence. Preserve both on the timeline.

Practical mapping into an execution timeline

The following mapping does not claim normative equivalence. It is an operating contract for integrating concepts:

Operating question	GS1 EPCIS	ONE Record	DCSA	Shared timeline
What changed?	object/event	logistics object	shipment/equipment/transport event	object_id + related_objects
When?	eventTime	event or object change	eventDateTime	occurred_at
Where?	readPoint/businessLocation	linked location	event location	location_id
Why/context?	businessStep/disposition	model type and relationships	eventType/classifier	event_type + business_step
Who asserts it?	repository source/party	data owner	publisher	source_party
Which evidence?	captured event	resource and revision	API message	evidence_ref + source version

Keep the original term beside its canonical translation. A future standard version can then be remapped without rewriting history.

From event to actionable exception

A new event should not automatically create an alert. Apply a state rule:

1. validate identity, version, and duplicate status;
2. update the object projection without erasing events;
3. compare new state with plan, promise, or policy;
4. classify the difference by required action;
5. assign owner, due time, and evidence;
6. close when an action or later event resolves the condition.

A calculated ETA must be recorded as an inference with version, inputs, and horizon, separate from a carrier-declared ETA. If they differ, the agent may explain the conflict and recommend priority. It must not pretend a single truth exists.

Illustrative multimodal example

This example is illustrative. A logistics unit leaves a warehouse, travels by road to a terminal, crosses by sea, and continues by air. An EPCIS event records dispatch of the unit; DCSA reports container loading; ONE Record updates an air-cargo object.

The shared layer does not turn them into one event. It connects them through relationships: the unit is contained in the container on one leg and associated with the air piece on another. When DCSA publishes a late discharge, the projection detects that the planned air milestone is no longer reachable. The agent prepares an exception with source events, variance from plan, and permitted alternatives. Operations decides whether to rebook.

Value does not come from “tracking three times.” It comes from preserving the causal change from source through decision and outcome.

Governing lineage across parties

Define which party may assert each event, how it authenticates, how long data is retained, and who can see it. An integrator must not silently become the author. Corrections use supersedes_event_id rather than editing the past. Sensitive records remain protected references.

Review quality by source: required-field completeness, latency, duplicates, corrections, and unlinked objects. Do not use event count as a proxy for visibility. A thousand messages without common identity can worsen operations.

Implementation in Quantum

Quantum Automation Center can use the business object as axis, the timeline for normalized events, artifacts and logs for permitted evidence, and state for exceptions. Permissions and human approval control actions; analytics can show latency, source quality, and resolution. See shipment monitoring and the Quantum ontology.

The agent should read that history and create a traceable recommendation, not replace it with an unreferenced summary.

Counterargument: another canonical model adds friction

It can. Another transformation may lose semantics, delay data, and create a central team that blocks changes. A design requiring every partner to abandon its standard will fail.

Keep the envelope small, versioned, and extensible. Preserve original payload and vocabulary, translating only what identity, order, context, and governance require. Sector teams continue using EPCIS, ONE Record, or DCSA in depth.

When not to build this layer

Do not build it when one network and standard already cover the journey and required decisions; configure that standard directly. Do not use an agent to invent missing events or “fill in” chronically late sources. An inference may support planning, but it must remain labeled as inference.

When no data-sharing agreement exists, resolve rights and accountability before integration. More technology does not create provenance.

Traceability test before the next model

Select one closed exception and walk from outcome to decision, events, relationships, and source messages. Then change one canonical mapping and verify that history can be reprocessed from the original. If the chain breaks, invest in identity and provenance before training another ETA prediction.

Sources

• GS1 EPCIS and Core Business Vocabulary — gs1.org
• IATA ONE Record — iata.org
• DCSA Track and Trace Standard Documentation — dcsa.org