Anomaly Classification
An anomaly flags a tradeflow whose computed transport plan contains an internal inconsistency worth a human look. It is a "check this one" signal, not a verdict that the shipment is wrong.
A tradeflow either has an anomaly or it does not. The dashboard flags any tradeflow with an anomaly present (anomaly > 0). There is no "small" or "large" anomaly to tune past - if the flag is on, something in the plan is worth reviewing. The underlying score is only a magnitude for sorting the worst first.
What triggers an anomaly
Anomalies come from the transport-plan builder detecting that the story it assembled does not hold together. The common triggers, in plain terms:
| Trigger | What it means | Typical cause |
|---|---|---|
| Multiple shipments merged | More than one distinct journey appears to have been folded into one tradeflow | Two bookings tracked under one reference; reused container number dragging an old journey in |
| Multiple bills of lading | More than one distinct BL detected on the tradeflow | Several BLs entered together; a BL reference that should have been split out |
| Container with no transport plan | A container on the tradeflow could not be placed into any plan | Missing or unmatched events for that container |
| Milestones out of order | Confirmed events sit in an impossible chronological sequence | Conflicting source timestamps; a late correction landing out of order |
| Origin equals destination | The load port and final discharge port resolve to the same location | Missing POL/POD information producing a circular plan; two journeys merged (see note) |
| Transshipment after final port | A transshipment step appears after what was marked the final discharge | A location wrongly classified as final POD |
| Orphan events | Events that could not be attached to any point in the plan | Location or sequencing data that does not line up |
| API locations with empty dates | Locations supplied via API arrive without usable dates while live data exists elsewhere | Incomplete API input alongside live tracking |
Most anomalies trace back to the input the plan was built from - references that should have been split, a reused container, a missing port - rather than to a container genuinely doing something impossible.
A container never runs a round trip
No single container ships out of a port and back to that same port within one tradeflow. So when the load port and final discharge port of the same container resolve to one location, it is always a defect - a phantom leg, two journeys merged, or missing port information - never a legitimate there-and-back. (Two different containers on one tradeflow travelling opposite directions, sharing a location, is normal and is not flagged.)
What you are expected to do
An anomaly is an invitation to check, in this order:
- Open the tradeflow and look at the plan the anomaly is pointing at.
- Check the references - is more than one booking or BL riding on one tradeflow that should be separate? Is a container number reused from an earlier shipment?
- Check the ports - is a POL or final POD missing or mis-resolved, producing a circular or truncated plan?
- If the input is correct and the plan is still inconsistent, that is a case worth reporting to support - it points at something to fix on the platform side, not on yours.
You do not need to act on every anomaly immediately. Sort worst-first and work down; a tradeflow that is already delivered and correct despite a flag can be left alone.
What an anomaly is not
- Not an SLA breach. Anomalies are about plan consistency, not timeliness. The timeliness metrics are Freshness, TTFF and Confirmation Delay.
- Not automatically your fault or ours. It is a neutral signal that the assembled plan is inconsistent; the cause could be input data or platform handling, which is what the review step establishes.
- Not gradable. There is no threshold to set. Present or absent.