ArchitectureLogistics
Supply chain control tower architecture, layer by layer
A control tower earns the name when it changes what happens to a shipment, not when it draws a map. That takes layers working together: event ingestion across modes, a canonical shipment model, ETA prediction with honest uncertainty, exception scoring, agent-assisted resolution with human approval for spend, and a feedback loop. Here is each layer and the trade-offs behind build or buy.
On this page
- Visibility platform versus control tower
- Reference architecture: the layers of a logistics control tower
- Event sources by transport mode and the quirks to design for
- The canonical shipment model and event matching
- Predictive ETAs with honest uncertainty
- Rules or learned anomalies: choosing how to detect exceptions
- Agent-assisted resolution with an approval gate
- Non-functional requirements for a control tower
- Build, buy or extend: a control tower decision table
- Questions and answers
- Sources
Visibility platform versus control tower
A visibility platform answers where a shipment is. A control tower answers what should happen next and who does it. Most of the cost of a disruption sits in the response: a container rolled to a later vessel is a fact, but whether the customer hears in time, whether stock is reallocated and whether the replacement booking is sensible are decisions.
So start the design by listing those decisions per role. A planner decides whether to expedite or re-plan; customer service decides when to notify; a warehouse decides whether to move a dock appointment; procurement decides whether a carrier's lane reliability justifies its rate. Every layer below should serve at least one of these decisions, or be cut.
The view on our logistics hub is that disruption should be treated as the steady state rather than the exception3. Design for a constant flow of shipments that need attention, not for the occasional crisis.
Reference architecture: the layers of a logistics control tower
- Agent-assisted resolution
Drafts carrier queries, rebooking options and customer notices; people approve anything with a cost.
- Exception scoring
Detects deviations and ranks them by the chance of a missed commitment and its impact.
- ETA prediction
Estimates arrival per leg and per order as a range, refreshed as new events arrive.
- Canonical shipment model
One representation of orders, shipments, units, legs and milestones across every mode.
- Multi-mode event ingestion
Receives EDI, APIs, positions and warehouse events, then cleans and de-duplicates them.
- Root-cause feedback
Compares plan with outcome by lane, carrier and facility, feeding findings back into planning and models.
Event sources by transport mode and the quirks to design for
Each mode reports progress differently; ingestion absorbs the differences so upper layers see one stream.
| Source | Typical messages | Quirks to design for |
|---|---|---|
| Road (truckload and LTL) | EDI X12 214 shipment status, carrier APIs, telematics positions | Status codes vary by carrier; positions carry no link to your order unless the load is tagged at dispatch |
| Ocean | EDIFACT IFTSTA, carrier APIs using the DCSA Track and Trace event model1, AIS vessel positions2 | Events describe containers and vessels, not purchase orders; schedules change after departure and transshipments add legs |
| Air cargo | Freight status messages in IATA Cargo-IMP or Cargo-XML, forwarder portals | Milestones attach to air waybills that may be split across flights, so piece counts need reconciling |
| Rail | Railcar and intermodal unit location and interchange events | Coverage and latency vary by railroad; yard dwell is often the signal that matters |
| Warehouse and yard | WMS receipts, picks, loads and ship confirmations; dock appointment systems | Local times, some keyed by hand; partial shipments split one order into several units |
| Parcel and last mile | Carrier tracking APIs and webhooks, proof of delivery | High volume with terse scan codes; failed-delivery reasons need mapping before they are useful |
Standards are named for orientation. Real partner feeds deviate from them, so read each implementation guide.
The canonical shipment model and event matching
Beneath the visible layers sits the one that decides whether any of them work: a canonical model representing orders, shipments, transport units (containers, trailers, unit load devices), legs, stops and milestones the same way in every mode. Each message is normalized with two timestamps, when the event happened and when it arrived, because late events are normal and both matter for ETA training.
Matching is where most effort goes. An ocean event carries a container number in ISO 6346 format and a bill of lading, while your customer asks about a purchase order. Linking them needs booking references, packing lists or advance ship notices, plus rules for splits, consolidations and containers re-stuffed at a cross-dock. Keep a match confidence on every link and queue unmatched events for a person; silent mismatches produce wrong alerts, and wrong alerts destroy trust.
Define source precedence too: when a carrier API, an EDI message and a tracker disagree, record the disagreement and apply a rule for which wins.
Predictive ETAs with honest uncertainty
Useful ETA models combine the plan (scheduled times and contracted transit), history (actual transit times on the lane by carrier, season and weekday), live state (position, dwell so far, terminal or yard congestion) and context (holidays, weather warnings, known disruptions). On ocean legs, port dwell and transshipment connections usually matter more than sailing time; on road, time of day, driver hours and appointment slots dominate.
Publish the prediction as a range and alert on the risk that the range crosses a commitment, not on the point estimate. Benchmark against the carrier's own ETA; where the model does not beat it on a lane, show the carrier's figure. Monitor error by lane and retrain as fast as the network changes, since a new service or a strike shifts the pattern overnight.
Rules or learned anomalies: choosing how to detect exceptions
- If
The exception is defined in a contract or SLA, such as a missed pickup window, a temperature excursion or a missing customs release
ThenUse explicit rules with the thresholds from the agreement.
They are auditable, and customers expect the definition they signed.
- If
The signal is a deviation from normal, such as unusually long dwell at one terminal or a tracker that stops reporting
ThenUse learned baselines per lane, facility and carrier, and alert on significant deviation.
A single fixed threshold is too loose at some sites and too noisy at others.
- If
Many alerts share one root cause, such as a vessel delay affecting every container aboard
ThenGroup them into one incident before scoring and routing.
Planners act on incidents; floods of duplicate alerts get ignored.
- If
You must decide what gets attention first
ThenScore severity as the chance of missing a commitment times the impact if missed, using penalty terms, stock cover and customer priority.
Delay length alone overweights harmless slips and underweights small delays on critical orders.
Agent-assisted resolution with an approval gate
Agents suit the slow, repetitive part of resolution: gathering facts, drafting messages and pricing options. Approval stays with a person whenever an action commits money or changes a customer promise.
- Exception engine
Raises a scored incident when a shipment is at risk.
- Resolution agent
Collects facts, contacts the carrier and prepares options with costs.
- Planner
Chooses an option and approves any spend or customer commitment.
- Carrier
Confirms status, offers alternatives and accepts the booking.
- Customer
Receives an approved notice with the revised ETA range.
- Exception engine to Resolution agentLate-risk incident
- Resolution agent to CarrierStatus and options query
- Carrier to Resolution agentRevised ETA and options
- Resolution agent to PlannerOptions with costs
- Planner to Resolution agentApproves rebooking
- Resolution agent to CarrierBooks approved option
- Resolution agent to CustomerSends approved notice
Non-functional requirements for a control tower
Build, buy or extend: a control tower decision table
| Factor | Buy a visibility platform | Extend your TMS or ERP | Build custom layers |
|---|---|---|---|
| Time to first lane | Fastest if your carriers are already connected | Moderate; depends on vendor modules | Slowest; ingestion and matching come first |
| Carrier and mode coverage | Broad prebuilt connectivity, uneven depth | Strongest for modes you already plan there | Whatever you connect yourself |
| Fit to your exception workflow | Generic, configurable within limits | Tied to the core system's planning objects | Designed around your decisions and approvals |
| Control of models and data | Vendor models; check data-use and export terms | The vendor roadmap decides | Full control and full responsibility |
| Best when | Visibility is the main gap and workflows are standard | Most execution already runs in one system | Your decisions are a source of advantage or no product fits |
Many programs combine options: buy connectivity, keep execution in the TMS and build the upper layers.
Questions and answers
How accurate do control tower ETA predictions need to be?
Accurate enough to change a decision earlier than you otherwise would. Judge the model against the carrier's own ETA and your commitment windows, lane by lane, looking at the spread of errors as well as the average. A model that flags genuine late risk a day earlier beats one that is precise only on shipments never at risk.
Do we need IoT trackers to build a control tower?
Usually not to start. Carrier messages, APIs, vessel positions and warehouse events cover most milestones. Trackers earn their cost where you need condition data such as temperature or shock, for high-value or theft-prone freight, or on lanes where carriers report poorly. Treat tracker events as one more source feeding the canonical model.
How do we start a control tower with a single lane?
Pick a lane with enough volume to learn from, a clear customer commitment and at least one painful exception type. Connect its sources, build matching for its order and unit structure, and run ETA and exception scoring in shadow beside the current process. Once planners trust the alerts, add agent-assisted resolution and expand to lanes that share carriers or facilities.
Should customers get access to the control tower?
Yes, to a view designed for them rather than the operations console. Customers need their shipments, current ETA ranges and proactive notices about incidents that affect them. Severity scores, carrier performance and cost options stay internal. Enforce the scoping in the data layer, so an interface change cannot expose another customer's freight.
Sources
- DCSA Track & Trace standard — Digital Container Shipping Association · checked 10 October 2026
- AIS transponders — International Maritime Organization · checked 10 October 2026
- AI for Logistics: ColdAI industry perspective — ColdAI