July 4, 20267 min read

An ETA change does not deserve an alert until it changes a decision

QD

By Equipo Quantum Developers

Operator in front of a laptop showing a series of green points and one highlighted event, with a map and a ship image in the background.
Share

Shipment monitoring creates operational control only when a state change becomes an alert because it changes a decision, promise, or action, while duplicate updates remain correlated without interrupting the team again. Displaying every received ETA creates visible activity but forces operators to rebuild context, reject repetition, and decide who acts.

Event, condition, and alert are different objects

An event asserts that something occurred or was observed by a source. A condition compares new state with a plan, promise, or policy. An alert assigns action, owner, and clock because the condition requires intervention.

Separation preserves complete history without turning it into noise. An ETA change may update the timeline; it opens or modifies an alert only when it crosses an actionability rule.

Normalize before deciding

GS1 EPCIS structures visibility data around what, when, where, why, and how, supported by business-context vocabulary. IATA ONE Record proposes a shared data model and APIs for air cargo, with the source retaining ownership of its data. DCSA Track and Trace documentation standardizes events for container tracking.

They are not one alert catalog. They do provide a basis for preserving identity, event type, location, time, and source before internal policy is applied.

A normalized envelope should include event_id, source, shipment_ref, equipment_or_piece_ref, event_type, event_time, observed_at, location, source_status, payload_version, and supersedes. Retain the original message as a protected artifact when needed.

Minimum alert contract

Field Purpose
alert_id and shipment_id stable work identity
event_fingerprint correlation and deduplication
source_refs supporting events and versions
previous_state/current_state evaluated change
plan_ref and promise_ref expectation used for comparison
deviation_type ETA, milestone, route, documentation, or custody
actionability_class inform, observe, act, or escalate
consequence which decision or promise is exposed
owner and due_at accountable person and clock
suppression_key/policy why another interruption is not created
status and resolution_code open, acknowledged, resolved, reopened
outcome_ref confirmation of action and result

Severity without consequence is decorative. A “high” label must explain which window, commitment, or control is at risk and which authority can respond.

Four actionability classes

Inform: the event completes history but changes no decision. Observe: a deviation exists but has not crossed the action point; reevaluate on the next event or deadline. Act: there is a defined task, such as requesting a document, changing an appointment, or informing a recipient. Escalate: normal action cannot protect the consequence and an authority must decide.

Class depends on object and promise, not only a time difference. The same change may be informational for cargo with no immediate commitment and actionable for a close connection. Avoid universal thresholds.

Deduplicate without erasing evidence

Calculate a fingerprint using source, object identifier, type, effective time, and event identifier or version. If the same event arrives, add a technical observation without creating another alert. If a source corrects it, use supersedes and reevaluate.

For successive updates to the same condition, use a suppression_key based on shipment, deviation, and action. The open alert receives new evidence, updates state, and retains every version. Interrupt again only when:

  • actionability class or consequence changes;
  • a relevant conflicting source appears;
  • the assigned action expires;
  • new evidence invalidates resolution;
  • escalation policy requires another authority.

A fixed time window alone is insufficient. It can hide a material change inside the window or create noise when the window expires even though nothing changed.

Illustrative example: an ETA that moves repeatedly

This scenario is illustrative. A carrier publishes a later ETA and the engine determines that it does not yet affect the receiving appointment. The condition remains under observation without interruption. Another update repeats the same event and is deduplicated.

Later, a correction crosses the appointment window. Policy opens a “reschedule receiving” alert, assigns the coordinator, and links all three events. Another ETA update changes time, but the required action remains the same; the alert updates without creating another. When the warehouse confirms a new appointment, outcome_ref closes it. If a later source restores the original ETA after the appointment changed, the system does not erase history; it evaluates whether to restore or retain the new plan.

The operator sees one unit of work with context rather than four disconnected messages.

Conflicting sources and operational confidence

Do not average ETAs from different sources. Preserve authority by event type, provenance, and observed_at. One source may be authoritative for a physical milestone and another for a booking. When they disagree, open a conflict condition with evidence rather than inventing certainty.

Useful confidence describes completeness and provenance, not an opaque score. “Carrier event without location” guides action better than “medium confidence.”

Metrics for a system that helps

Measure received events, deduplicated events, open conditions, alerts by class, time to owner, action age, escalations, reopenings, and closures with outcome_ref. Review alerts without action and actions created without a changed consequence.

Do not turn “alerts avoided” into savings without observing actual work. Suppression is useful when it preserves evidence and reduces redundant interruption; it is dangerous when it lowers a number by hiding cases.

Representing the contract in Quantum

In Quantum Automation Center, the shipment acts as a business object. Its timeline retains events; artifacts and logs link evidence; executions show normalization and evaluation; permissions and approvals assign authority; analytics distinguish events, conditions, alerts, and outcomes. The business-object documentation connects state and operations.

An agent may summarize evidence and propose action. Policy decides whether to open, update, suppress, or escalate; people retain sensitive decisions.

Counterargument: suppression can also conceal

Alert suppression can hide deterioration or conflicting sources; suppression must be a versioned rule, preserve every event, and reopen when consequence, evidence, or required action changes. Audit suppressed cases and let operators inspect the chain.

A team may prefer higher sensitivity during a provider transition. Policy should be adjustable by population and effective date rather than hidden as a constant.

When not to automate alerts

Do not do so when sources lack reliable identity and time, the process is too sporadic to define ownership, or a safety signal requires independent notification without suppression. Establish the event contract and human procedure first.

Do not automate a promise nobody owns. Without action, owner, or authority, an alert only redistributes anxiety.

The contract test

Take one alert and answer which event opened it, which promise changed, why it was actionable, who received the task, which updates were suppressed, which evidence reopened or closed it, and what result followed. If the system only says “ETA changed,” tracking exists; alert control does not.

Sources