Logistics domain fundamentals

An order is a commercial intent: someone has agreed to buy or move a set of goods, and it carries prices, terms and a promise. A shipment is one physical movement of goods from one place to another under one transport arrangement. A consignment is the contractual unit handed to a carrier — one sender, one receiver, one set of documents — which is what a waybill actually covers. One order can become five shipments, and one shipment can carry consignments for forty customers. Systems that treat them as the same row cannot express a partial despatch, cannot split a backorder, and cannot answer the two questions every logistics business asks daily: what did we promise, and where is it now.

The entities nest, and each level exists because something in the business changes at that level.

order OS-99120                       commercial promise, 3 lines
 |
 +- shipment SHP-A  Leeds -> Bristol   one movement, one carrier, one waybill
 |   |
 |   +- handling unit SSCC ...0001     a pallet, what a forklift moves
 |   |   +- carton C-1   GTIN 5012345000015  x 24 EA
 |   |   +- carton C-2   GTIN 5012345000015  x 24 EA
 |   |
 |   +- handling unit SSCC ...0002     a second pallet on the same shipment
 |       +- carton C-3   GTIN 5012345000022  x 6 EA
 |
 +- shipment SHP-B  Leeds -> Bristol   line 3 was out of stock, ships Thursday
     +- handling unit SSCC ...0003
         +- carton C-4   GTIN 5012345000039  x 12 EA

Read the levels by what changes at each. The order level is where money and the customer promise live. The shipment level is where the carrier, the cost and the transit time live. The handling unit level is where scanning, custody and damage live, because a scan is always against a physical thing somebody can put their hands on. The item level is where inventory and picking live.

The classic conflation is putting the tracking number on the order. It works until the first split despatch, at which point the customer has two parcels and one tracking number, the second parcel has no identity in your system, and support cannot tell them where it is. The mirror error is putting quantity on the handling unit rather than on its contents, which makes a partial short-shipment unrepresentable — you can say the pallet arrived but not that it arrived with twenty-two cartons instead of twenty-four.

The third conflation is treating the handling unit as disposable. Packaging nests: cartons onto a pallet, pallets into a container, and a cross-dock may break a pallet down and rebuild it into three others. If the handling unit has no stable identity across that rebuild, the scan history breaks at exactly the point where goods most often go missing, and you lose the ability to say which custody transfer the loss happened in.

What all three failures have in common is that they surface in operations, not in development, because a happy-path order has exactly one of everything.

A load is a carrier-side unit: the set of consignments assigned to one vehicle for one journey, with a sequence of stops. A shipment is a customer-side unit: goods moving from A to B. The distinction matters because they have different owners and different optimisation objectives. The shipper wants each shipment fast and cheap; the carrier wants each load full and each route short, and those goals conflict directly. Load planning is where the conflict is resolved, which is why the same physical parcel appears in a shipment table keyed by customer and a load table keyed by vehicle and departure time, joined by a stop.

GS1 identifiers look like arbitrary numbers and are not — each field is allocated, and knowing the structure explains why they cannot be generated casually.

GTIN-13  identifies a product, not an instance
  5 012345 00001 5
  |  |      |    |
  |  |      |    +- check digit, modulo 10
  |  |      +------ item reference, assigned by the brand owner
  |  +------------- company prefix, licensed from GS1
  +---------------- GS1 prefix indicating the issuing member organisation

SSCC-18  identifies one logical handling unit, uniquely, worldwide, once
  3 5012345 000000001 6
  | |       |         |
  | |       |         +- check digit
  | |       +----------- serial reference, the sender must never reuse it
  | +------------------- company prefix, same licensed block
  +--------------------- extension digit, sender's own use

GS1-128 barcode on the pallet label, application identifiers in brackets
  (00)350123450000000016 (02)05012345000015 (37)0048 (10)LOT7741 (15)261130
   00 = SSCC            02 = contained GTIN   37 = count  10 = lot  15 = best before

The engineering consequence of the GTIN is that it identifies a kind of thing. Two cartons of the same product share a GTIN, so a GTIN can never be a primary key for a physical unit, and a scan of a GTIN alone tells you what something is and nothing about which one it is.

The SSCC is the opposite: it identifies one handling unit and must be globally unique and never reused. That single constraint means serial allocation cannot be a random number or a database identity that resets on a restore, and it means handling-unit labels are a resource with a lifecycle — allocated, printed, applied, consumed, and eventually retired after the reuse embargo.

The application identifiers are where integration work actually lives. A pallet label carries the SSCC, the contained GTIN, a count, a lot number and a date, and a receiving scan can therefore create stock, attach traceability and check shelf life in one action. Sites that print their own non-GS1 labels lose all of that, which is why their receiving is manual and their recalls are spreadsheets.

The interview point is that these standards exist so two companies who have never spoken can read each other's pallets. Reinventing them is not a shortcut; it is opting out of everyone else's automation.

Because the ratio of stops to volume inverts along the chain. The first mile collects from a small number of senders in bulk, so cost per unit is low and the variable is scheduling. The middle mile is line haul between sorting facilities: high volume, few stops, and cost driven by vehicle fill and fuel, so it rewards consolidation above all. The last mile is one drop per customer, so the driver spends most of the day stopping, parking, walking and knocking — labour dominates and volume barely helps. That is why the last mile is routinely half the total cost of a parcel journey while covering the shortest distance, and why every last-mile idea is really an attempt to raise drops per hour.

Each arrow is a custody transfer, and every one of them is a place where the parcel can stop moving.

flowchart LR
    A[Collection from merchant<br/>first mile] --> B[Origin depot<br/>sort by destination region]
    B --> C[Line haul trunk<br/>middle mile]
    C --> D[Destination depot<br/>sort into delivery rounds]
    D --> E[Delivery round<br/>last mile]
    E --> F{Delivered on attempt}
    F -->|no| D

The loop from the failed attempt back to the destination depot is the whole economics of the last mile in one edge. A first-time delivery costs one drop; a second attempt costs another full drop for the same revenue, so a network with a ninety per cent first-time rate has ten per cent of its most expensive resource producing nothing.

The sort steps are where the network's shape shows. At the origin depot a parcel is sorted by region because the trunk vehicles are regional; at the destination depot it is sorted by round because the vans are geographic. A parcel that arrives after the round has been built and loaded does not get delivered today regardless of how early it was collected, which is why cut-off times are a hard product constraint rather than an operational preference.

The custody transfers are also where liability moves, and each one needs a scan for the same reason a bank needs a ledger entry: without it, a loss cannot be attributed. The practical rule is that anywhere goods change hands, vehicle or building, there is an event, and the absence of an expected event is itself the most useful signal you have.

When there are many origins and many destinations and no individual pair has enough volume to fill a vehicle. Routing everything through a hub means each spoke needs one vehicle to the hub rather than one to every other spoke, so the number of links falls from roughly n squared to n and every vehicle runs full. The cost is distance and time — a parcel travelling between neighbouring towns may go two hundred miles via the hub — plus a single point of congestion where a sort failure delays the entire network overnight. Point to point wins on dense lanes with reliable volume, which is why mature networks are hybrids that bypass the hub for their strongest pairs.

A carrier owns the vehicles and moves goods. A freight forwarder owns no vehicles: it buys capacity, consolidates consignments and handles documentation, so its product is arrangement and paperwork rather than transport. A third-party logistics provider operates a function on a client's behalf — warehousing, fulfilment, transport management, or all three — and typically holds the client's stock under its own roof. The engineering consequence is whose system is the system of record. When a 3PL runs the warehouse, its WMS holds bin-level truth and the client's ERP holds an aggregate that arrives on a file, so the client's stock figure is always a little behind reality and reconciliation is a permanent scheduled job rather than an exception.

The layout defines the coordinate system every task is expressed in, and it is not a free choice afterwards. Locations have a structure — zone, aisle, bay, level, position — and that hierarchy becomes the sort key for travel, the unit of a cycle count, the granularity of a stock record and the boundary of a picking zone. Aisle direction and cross-aisle placement determine what a sensible pick sequence looks like, so a system built for one layout produces absurd routes in another. Change the racking and every stored location code, and every optimisation tuned to it, becomes wrong at once, which is why location naming is one of the few schema decisions in this domain worth arguing about early.

Goods arrive, are checked against an expected receipt, and become stock. It is the highest-leverage step because every error made here is inherited by everything downstream: a mis-keyed quantity becomes a phantom stock figure that sells goods you do not have, a missed damage note becomes an unrecoverable supplier claim, and an unrecorded lot number becomes a recall you cannot scope. It is also the only point where you can refuse the problem — once goods are putaway, a discrepancy is yours to investigate rather than the supplier's to explain. Advance shipping notices exist so that receiving becomes a confirmation rather than a data-entry exercise.

Putaway is moving received goods from the dock into a storage location, and the decision is a small optimisation with real consequences. The system weighs travel distance, whether the product already has a home location, whether the location's size and weight limits fit, storage rules such as hazard segregation or temperature, and rotation — putting new stock behind old so first-expiry picks first. Directed putaway, where the system nominates the location and the operator confirms by scanning it, is what keeps stock records true; letting operators choose freely produces a warehouse where the stock exists and nobody can find it, which is functionally identical to not having it.

Moving stock from bulk storage into the small, fast pick locations that pickers actually visit. It exists because a pick face holding two days of stock keeps walking short, while a pick face holding two months of stock would make the pick path enormous. The engineering problem is triggering it at the right moment: replenish too late and picks fail with the goods on site, which is the most infuriating stockout there is, and replenish too eagerly and you spend more labour on internal moves than on picking. Most systems use a minimum-maximum level per location, with demand-aware triggers that look ahead at released orders rather than only at current quantity.

The strategies differ in what they batch, and every one of them trades walking against a downstream sortation or consolidation step.

strategy   picker handles            best when                      cost moves to
---------  ------------------------  -----------------------------  --------------------
discrete   one order at a time       low volume, large orders       most walking per line
batch      many orders in one pass   many small similar orders      sortation at pack
zone       only their own zone       large site, dense picking      consolidation of parts
wave       a timed released set      hard carrier cut-off times     idle between waves
waveless   continuous release        steady flow, tight promises    labour harder to plan

Discrete picking is the honest baseline: nothing to reassemble, one tote, one order, and the worst travel per line. It survives in operations where orders are large enough that the picker fills a cage in one aisle anyway.

Batch picking is the biggest single win in an operation with many one-line and two-line orders, because the picker visits a location once and takes twelve units for twelve customers. The cost does not disappear — it moves to pack, where those twelve units must be separated correctly, so batch picking without a sortation mechanism trades a walking problem for a mispick problem.

Zone picking scales a large site by giving each picker a small territory, so travel per line collapses. What it creates is consolidation: an order picked across four zones arrives at pack in four pieces at four different times, so you now need a place to hold partial orders and logic to know when one is complete. That holding area is the thing that overflows on peak days.

Wave and waveless are about release timing rather than picker behaviour. Waves align work to despatch cut-offs, which is exactly right when a carrier collects at 16:00 and useless the rest of the day, because labour idles between waves. Waveless release smooths labour and makes hitting a specific cut-off a matter of prioritisation rather than scheduling — better for continuous same-day promises, harder to plan a shift around.

The choice is not permanent and most large sites run several at once: waveless for next-day, waves for the airfreight cut-off, discrete for oversized goods.

Same eight lines, same warehouse, two sequences — and the difference is not a few per cent.

Layout: aisles 1 to 10, cross-aisle at both ends, 40 m per aisle.
Order of 8 lines. Locations, in the sequence the lines were keyed:
  A-07, A-02, A-09, A-01, A-06, A-03, A-08, A-04

unoptimised, picked in line sequence
  start -> 07 -> 02 -> 09 -> 01 -> 06 -> 03 -> 08 -> 04 -> pack
  aisle traversals               11 full and part traversals
  distance travelled            412 m

optimised, sorted by location into a serpentine sweep
  start -> 01 -> 02 -> 03 -> 04 -> 06 -> 07 -> 08 -> 09 -> pack
  aisle traversals               5
  distance travelled            128 m

  saving                        284 m per order
  at 1.3 m/s                    3.6 minutes per order
  at 900 orders a shift         54 hours of walking, roughly 7 pickers

The arithmetic is the argument. Nothing about the goods changed, no equipment was bought, and seven pickers' worth of labour was recovered by sorting a list. This is why pick-path sequencing is the first thing anyone builds in a WMS and why it is scored so heavily in an interview: it is the clearest case in the domain of software producing physical throughput.

The serpentine sweep is the naive optimiser and it is usually enough. Walk up odd aisles, down even ones, never double back. It is optimal on a simple layout and within a few per cent of optimal on most real ones, which matters because the exact problem is a travelling salesman instance and you have three hundred milliseconds to answer.

Two details separate a real implementation from the textbook. The sort key must be the travel order, not the location code — if aisle 10 is physically next to aisle 1, sorting lexically sends the picker across the building. And the sequence must respect stacking: heavy and crush-resistant goods picked first, because a perfect path that arrives at pack with squashed goods has optimised the wrong thing.

The third detail is that the win compounds with batching. Sorting one order's eight lines saves 284 metres; batching twelve orders and sorting the combined ninety lines means one traversal serves all twelve, and the saving per line roughly halves again.

Slotting decides which product lives in which location, and the objective is to put the fastest-moving lines closest to despatch and at a comfortable picking height. A good slotting can halve travel without any change to the pick algorithm, because it changes the problem rather than the solution. It needs re-running because demand moves: seasonal lines, promotions, new products and discontinuations mean the ranking that justified today's layout is wrong within a quarter. The constraint is that re-slotting is itself physical work, so the real optimisation is choosing the smallest set of moves that captures most of the benefit rather than the theoretically ideal arrangement.

Cycle counting counts a small subset of locations every day, continuously, rather than counting everything once a year. It wins because a full stocktake requires stopping operations, which is expensive and often means a weekend of lost despatch, and because it detects errors within days rather than months — by which time the cause is untraceable and the stock has already been oversold. The usual scheme weights frequency by value and movement, so the fast, expensive lines are counted often and the slow, cheap ones rarely. Counting on a trigger, such as a failed pick or a zero-quantity location, catches more errors per count than any calendar-based scheme.

The number a customer can buy is not the number on the shelf, and a count changes only one of them.

SKU 4471-B, bin A-12-3, unit of measure EA

before the count
  on hand, per system                          420
  allocated to unshipped orders                180
  quarantined pending quality check             20
  in transit, inbound, not yet received         96
  available to promise = 420 - 180 - 20        220

physical count
  counted                                      398
  variance                                     -22 EA, -5.2 percent of on hand

after posting the variance
  on hand                                      398
  allocated                                    180
  quarantined                                   20
  available to promise                         198

  allocations are unchanged: the 22 missing units were already sold.
  the shortfall does not appear until whichever order picks last fails.

The first thing the block shows is that available to promise is a derived figure, not a stored one. Four separate quantities feed it, each owned by a different process, and a candidate who says "we store the stock level" has already lost the design. On-hand belongs to the warehouse, allocation to the order system, quarantine to quality, in-transit to purchasing.

The second is that the count did not fix anything. It corrected the record and left twenty-two units of already-promised demand with nothing behind it. The loss has been discovered, not resolved, and resolving it is a commercial decision: cancel, substitute, expedite an inbound, or let it fail at pick. A system that posts variances without surfacing the affected allocations pushes that decision onto a picker at the worst possible moment.

The third is the in-transit line, which is deliberately excluded from available to promise here and is included in many systems. Both are defensible and they are different products: excluding it is conservative and undersells, including it promises goods on a lorry that may not arrive. The interview answer is that the choice must be explicit and per-channel, not a side effect of whichever query someone wrote.

And the variance itself is a signal, not just a correction. Repeated negative variances in one bin point at a specific cause — a mis-slotted neighbour, a short receipt, a scan bypassed under time pressure, or theft — and treating variances as data rather than as noise to be posted is what moves accuracy.

Usually the percentage of counted locations whose quantity matches the record exactly, which is stricter and more useful than a net value comparison because offsetting errors cancel in the aggregate and never cancel in operations. A warehouse can be ninety-nine per cent accurate by value and still fail picks all day if the errors are concentrated in fast-moving lines. That is why the metric worth tracking alongside it is the failed-pick rate, which measures the consequence rather than the record, and why accuracy is reported by location and by velocity band rather than as a single site-wide number that hides everything interesting.

Moving goods straight from an inbound vehicle to an outbound one without putting them into storage. It removes putaway, storage and picking entirely, so the cost and the handling damage both fall, and it is how fresh food and store replenishment mostly work. What it demands is timing and information: the outbound load must be planned before the inbound arrives, the inbound content must be known at handling-unit level in advance, and a delay of ninety minutes turns a cross-dock into an unplanned storage problem in a building with no racking. It trades inventory buffer for schedule discipline, which is a fragile trade when carriers are late.

The flow is not the forward flow reversed. A return arrives unannounced, in unknown condition, often without paperwork, and its value depends on an inspection that has not happened yet — so the first step is grading, and the outcomes diverge into restock, repair, refurbish, liquidate, recycle and destroy. Each has a different financial treatment and a different physical route. The engineering consequence is that a return is its own entity with its own lifecycle rather than a negative shipment, because a negative shipment cannot hold a grade, a disposition or a refund decision that must sometimes be made before the goods are inspected.

Because it is a generalisation of the travelling salesman problem, so the number of possible solutions grows factorially and there is no efficient algorithm that finds the optimum. Real instances add constraints that make it worse rather than easier to prune: time windows at each stop, vehicle capacity by both weight and volume, driver hours and break rules, mixed fleets with different access restrictions, skills or equipment required at particular stops, and precedence where a pickup must precede its delivery. So production routing uses heuristics and metaheuristics that produce a good solution within a time budget, and the engineering question is never optimality but how good a solution you can find in the ninety seconds before the depot needs to load.

Four stops, one van, and the intuitive nearest-first rule produces an infeasible day.

travel minutes  depot   A    B    C    D
depot             -    15   40   20   35
A                15     -   22   18   22
B                40    22    -   45   15
C                20    18   45    -   40
D                35    22   15   40    -

stop  window          service time
A     08:00 - 09:00   10 min
B     08:30 - 09:00   10 min
C     12:00 - 13:00   10 min
D     08:45 - 09:15   10 min

greedy nearest-neighbour, departing the depot at 08:00
  depot -> A   nearest at 15   arrive 08:15, serve to 08:25
  A -> C       nearest at 18   arrive 08:43, window opens 12:00
               wait 197 minutes, serve 12:00 to 12:10
  C -> D       nearest at 40   arrive 12:50, window closed at 09:15   FAIL
  C -> B                       any order now infeasible                FAIL
  result: 2 of 4 stops served, one van, most of the morning idle

window-aware sequence
  depot -> A   arrive 08:15, serve to 08:25
  A -> B       arrive 08:47, serve to 08:57
  B -> D       arrive 09:12, serve to 09:22      window closes 09:15, just inside
  D -> C       arrive 10:02, wait, serve 12:00 to 12:10
  result: 4 of 4 stops served, one van

Greedy fails for a specific reason worth naming: distance and time feasibility are different objectives, and nearest-neighbour optimises the one that does not bind. Going to C early is the shortest hop available and it consumes the only part of the day in which B and D can be served. The cheapest move destroyed the feasible region.

The window-aware sequence is worse on raw distance and better on everything that matters. It also shows where the fragility is: D is served at 09:12 against a 09:15 close, so three minutes of traffic loses the stop. A real solver would be asked for a solution with slack, not merely a feasible one, because a schedule with zero buffer fails on contact with a road.

The waiting time at C is the second lesson. Waiting is not free — it is paid driver time — so a good objective function costs it explicitly rather than treating any feasible route as equivalent. Once waiting is costed, the solver will look for a fifth stop to fill the gap, which is what a planner does by hand.

The general shape is therefore: construct a feasible solution respecting the hard constraints, then improve it with local moves that preserve feasibility, and stop when the clock runs out. Anything that treats the windows as a post-hoc filter over distance-optimal routes will discard almost everything it generates.

Static routing plans the day before the vehicles leave and does not change it, which makes the plan cheap to compute, easy for drivers and depots to work against, and wrong the moment reality diverges. Dynamic routing re-optimises during execution as traffic, new orders, failed stops and delays arrive, so it recovers value from disruption and creates two hard problems: the plan a driver was following keeps changing, which they hate and which erodes trust, and every re-optimisation must run inside seconds on partial information. Most real operations are static with bounded dynamism — the sequence is fixed, insertions are allowed within rules — because a plan nobody follows is worse than a suboptimal one everybody does.

They turn a continuous day into a constrained one with mandatory discontinuities. Driving time is capped per day and per week, breaks are required after a set period of driving, and daily rest between shifts is prescribed — so a route is not simply a sequence of stops within a shift length but a sequence interleaved with breaks whose placement is itself a decision. The consequence is that adding a stop can force a break, which adds forty-five minutes and can invalidate every window after it. Modelling hours as a soft check applied after routing produces plans that are infeasible in law rather than merely inconvenient, and the compliance record is auditable, so the cost of getting it wrong is not operational.

Allocating a finite number of doors and yard slots to arriving and departing vehicles, so a carrier turns up at an agreed time and finds a door and labour available. Without it, arrivals cluster, vehicles queue, drivers accrue waiting charges and the labour plan collapses because the work arrived in a lump. With it, the appointment becomes a commitment on both sides, which is precisely why it is hard: a carrier that misses a slot must be handled somehow, and a policy that simply refuses late vehicles moves the problem to the yard. The scheduling system's real job is to smooth labour demand, and the metric it is judged on is turnaround time rather than door utilisation.

Deciding which consignments go on which vehicle and in what physical arrangement. The constraints come in pairs that pull against each other: weight against volume, since a vehicle can be full by either and rarely by both; axle-weight distribution, which restricts where heavy items may sit; stacking and crush limits; segregation rules for hazardous or food goods; and drop sequence, because the first delivery must be reachable at the doors. That last one is the constraint people forget, and it is the reason a volumetrically-perfect load can be operationally useless — the driver would have to unload half the trailer at the kerb to reach the first consignment.

Two ways of building the same goods into the same trailer, with the arithmetic that decides which constraint binds.

Trailer, internal 13.6 m x 2.45 m x 2.70 m = 90.0 m3
Payload limit 24,000 kg
Floor positions 33 standard pallets at 1.2 m x 0.8 m

Load A, pallets built to 1.55 m, not stackable as built
  goods volume    33 x 0.96 m2 x 1.55 m       = 49.1 m3
  cube used       49.1 / 90.0                 = 55 percent
  weight          33 x 420 kg                 = 13,860 kg
  payload used    13,860 / 24,000             = 58 percent
  binding constraint: floor positions. Neither cube nor weight is full.

Load B, same goods rebuilt to 1.30 m so two tiers fit under 2.70 m
  pallets         49.1 / 0.96 / 1.30          = 39 pallets
  floor positions 39 over two tiers           = 20 positions
  freed           13 floor positions, 26 pallet slots
  add             26 x 0.96 x 1.30            = 32.4 m3 of a second consignment
  cube used       81.5 / 90.0                 = 91 percent
  weight          approx 65 pallets x 352 kg  = 22,880 kg
  payload used    22,880 / 24,000             = 95 percent
  binding constraint: weight. The trailer is now genuinely full.

The first load is the common real-world case and it looks fine on every dashboard: the trailer is visually full, all thirty-three positions are used, and the vehicle leaves. It is carrying fifty-five per cent of its cube and fifty-eight per cent of its payload, which means nearly half the journey's cost is moving air.

What made it bad was a decision taken in the warehouse, not in transport. The pallets were built to a height that cannot be double-stacked under the trailer roof, so 1.15 metres of headroom above every pallet was lost before the load planner saw it. Pallet build height is a transport cost decision disguised as a packing detail, and it is the single most common place cube is thrown away.

The second load shows what "full" should mean: one of the two real constraints is at ninety-five per cent, and the other has no slack worth chasing. That is the answer to give when asked what good utilisation looks like — not a percentage target on cube alone, because a dense load will never fill cube and a light one will never approach the weight limit.

The metric that follows is cost per unit moved rather than fill percentage. Chasing cube on a load of bottled drinks means adding weight you cannot legally carry, and chasing weight on a load of cushions means nothing. Knowing which constraint binds for a given product is what lets you say whether a lane is badly loaded or simply carrying a light product.

Full truckload means a vehicle dedicated to one consignment, travelling point-to-point with no intermediate handling, so transit is fast, damage is low and you pay for the vehicle whether you fill it or not. Less-than-truckload consolidates several shippers' freight, which is cheaper per unit and involves terminal handling and often a hub, so transit is slower and less certain and handling damage is materially higher. The crossover is usually somewhere around half a trailer, and the interesting operational point is that LTL pricing depends on freight class and density rather than simply weight, so the same tonnage can cost very differently depending on how well it packs.

Tracking state should never be a column somebody updates; it should be a fold over an immutable event stream.

sequenceDiagram
    participant D as Driver device
    participant G as Scan gateway
    participant E as Event store
    participant P as Projection
    D->>G: ARRIVED_AT_DEPOT at 0612
    G->>E: Append, immutable, keyed by scan id
    D->>G: OUT_FOR_DELIVERY at 0840
    G->>E: Append, immutable, keyed by scan id
    E->>P: Fold in occurrence order
    P-->>P: Derived state becomes OUT FOR DELIVERY

The reason for the shape is that scans arrive late, out of order and more than once. A driver's device loses signal in a lift and uploads four scans at 09:15 that happened between 06:12 and 08:40; a depot scanner double-reads a label; a handheld's clock is eleven minutes fast. Every one of those breaks a design that writes a status column, because the last write wins and the last write is not the last event.

So the event carries two timestamps — when it occurred and when it was recorded — and the projection orders by occurrence while using the recorded time to explain why the customer saw the wrong thing for nine minutes. A scan also carries an idempotency key so a double read collapses to one event rather than two.

The derived state is then a pure function of the events, which buys three things worth naming. Any state can be recomputed, so a bug in the mapping is fixed by replaying rather than by a data migration. The history is auditable, which is what a liability claim needs. And a new consumer — customer notifications, carrier scorecards, an ETA model — reads the same stream without anyone extending a status enum.

The trap is the enum itself. Carriers use different codes with different meanings, and mapping fourteen carriers' vocabularies onto one internal milestone set is the actual work of a tracking integration. Keep the raw carrier code on the event and derive your milestone from it, because the mapping will be wrong and you will need the original to fix it.

A scan is an assertion that a specific handling unit was at a specific place at a specific time, made by a device with a known identity. It is the atom of logistics data because it is the only thing in the domain that is observed rather than inferred: quantities, states and estimates are all derived, but a scan happened. Treating the stream as the source of truth means the record of what occurred survives every change to how you interpret it, which matters because interpretation changes often — new carriers, new milestone definitions, new customer-facing wording — and the physical history does not.

A milestone is a business-meaningful point in the journey that a customer or a contract cares about: collected, departed origin, arrived destination, out for delivery, delivered. A status is the current derived state, which is a summary of the milestones reached so far. The distinction matters because milestones are a sparse, ordered, auditable set that appears in service-level agreements, while status is a projection you are free to change. Publishing every internal scan as a customer-visible milestone is the usual error: customers do not want to know that a parcel was rescanned in the outbound cage, and each exposed event becomes something you can never stop sending.

The central estimate is the easy part; the spread is what determines what you are allowed to say.

Round R-118. Departed depot 08:40. This parcel is stop 41 of 78.

component                          central     p10 to p90
---------------------------------  ----------  -----------------
travel, depot to first stop        14 min      11 to 22
service time per stop              3.2 min     1.5 to 9.0
stops completed before this one    40          40
accumulated service, 40 stops      128 min     92 to 196
accumulated travel, 40 hops        92 min      75 to 140
---------------------------------  ----------  -----------------
arrival, central estimate          12:34
arrival, p10                       11:47
arrival, p90                       14:18

The central estimate is 12:34 and it is very nearly meaningless on its own. The spread from 11:47 to 14:18 is two and a half hours: the arrival falls outside that window one time in five, and any single time quoted inside it is almost never exactly right, which is why the window rather than the point is what you display. A system that shows 12:34 has converted an honest uncertainty into a promise it will break daily.

The reason the spread is so wide is structural: uncertainty accumulates with the number of stops ahead of you. Stop 3 can be predicted to a few minutes; stop 41 inherits forty stops' worth of variance in service time, and service time is the dominant term because a stop can take ninety seconds or nine minutes depending on whether anyone answers the door.

What follows is how to communicate it, and this is the part interviewers are actually probing. Quote a window whose width reflects the actual spread, quote it as a probability rather than a fact, and narrow it as the round progresses — a two-hour window in the morning, thirty minutes once the van is four stops away, a live tracker in the final minutes. Each narrowing is honest because the uncertainty genuinely fell.

Two further points worth offering. Predict the distribution, not the mean, since a model trained to minimise squared error gives you the mean and you needed the tenth and ninetieth percentiles. And measure yourself on window hit rate rather than mean absolute error, because a customer does not experience your average; they experience whether you arrived when you said you would.

Because the ETA is the promise, and the experience is the gap between what you said and what happened rather than how long it took. A three-day delivery that arrives when predicted is judged good; a next-day delivery predicted for the morning that arrives at seven in the evening generates a complaint even though it was faster. This inverts the engineering priority: an operation that is slower and predictable outscores one that is faster and variable, so effort spent reducing variance beats effort spent reducing the mean. It also means the ETA is a product surface with a cost, since every narrow window you display is an obligation you have taken on.

That specific goods reached a specific place at a specific time, in a form that survives a dispute months later, because the dispute is what it exists for. That usually means a scan of the handling unit, a timestamp, a location fix, and some evidence of receipt — a signature, a name, a photograph of the parcel in situ, or a one-time code the recipient provides. Each has different evidential weight and different privacy consequences: a doorstep photograph is excellent evidence and captures somebody's home, so retention, access and redaction become design requirements rather than afterthoughts. Unattended delivery shifts the burden entirely onto the photograph and the geofence.

A failed attempt is not one path but a branch on the reason, and the branches have almost nothing in common.

flowchart TD
    A[Delivery attempt fails] --> B{Reason code}
    B -->|nobody in| C[Reattempt next round<br/>notify customer with a new window]
    B -->|address unusable| D[Hold at depot<br/>request a corrected address]
    B -->|damaged in transit| E[Quarantine<br/>open a claim and trigger replacement]
    B -->|refused by recipient| F[Return to sender<br/>reverse leg is a new shipment]
    C --> G[Attempt counter incremented<br/>third failure routes to return]

The reason code is the whole design. Without it there is one generic "failed" state, and every downstream decision — whether to reattempt, whether to charge, whether to claim, whether to refund — has to be made by a human reading a note. With it, three of the four branches are automatable and the fourth is routed to the right team rather than to a general queue.

The branches diverge on ownership as well as action. Nobody in is an operational retry and costs you a drop. An unusable address is a data problem whose fix lives with the merchant or the customer, so the parcel must wait somewhere without ageing out. Damage is a financial event that starts a claim against a carrier and a replacement to the customer, and those two flows must not be coupled because the claim will outlive the replacement by months. Refusal reverses the journey, and the return leg is a new shipment with its own identity, cost and tracking rather than the original run backwards.

The attempt counter is the small detail that decides whether the network stays solvent. Unbounded reattempts turn one revenue event into four drops, so the policy — usually two or three attempts, then hold or return — has to be enforced in the flow rather than left to a depot's judgement.

The point to make unprompted is that exceptions are not rare. Somewhere between five and fifteen per cent of last-mile attempts fail depending on the geography and the product, so exception handling is not an edge case bolted on at the end; it is a primary flow that deserves the same design attention as the happy path and generates most of the customer contact.

Failed delivery, where the goods and the network are fine and the recipient was not available. Damage, which is a financial event requiring evidence and a claim. Shortage, where fewer units arrived than were despatched, which needs reconciliation against the despatch scan to establish which leg lost them. Misroute, where the goods are intact and in the wrong place, so the fix is transport rather than replacement. Delay, which is the only one where nothing is wrong except the promise. They are worth separating because each has a different owner, a different remedy and a different cost, and a single "exception" flag forces every one of those decisions back onto a person.

Cold chain means the goods have a validated temperature range for their whole journey, so the shipment now carries a continuous sensor record alongside its scan events. An excursion is a period outside that range, and whether it matters depends on cumulative time and magnitude rather than a single reading — which is why the rule is stated as an allowable time above a threshold, not as a maximum. The engineering consequences are real: sensor data arrives in bursts when a logger is read, the disposition decision belongs to quality rather than operations, and the record must be retained for the product's shelf life because a recall will ask for it.

It predicts demand, which is not the same as past sales — sales are censored by whatever you had in stock, so forecasting on sales history teaches the model that demand fell in exactly the weeks you ran out. Seasonality bites because several cycles overlap: weekly patterns, annual patterns, moving holidays that shift date-to-date, and promotional spikes that are decisions rather than seasons. The consequence is that promotional and event demand should be modelled separately from baseline rather than smoothed into it, because a model that absorbs last year's Black Friday into its trend will over-forecast the following February and nobody will know why.

The formula is short and the interesting part is which variability dominates.

Item 4471-B
  average demand              200 units per day
  demand std deviation        40 units per day
  average lead time           9 days
  lead time std deviation     2 days
  target service level        95 percent, so Z = 1.65

demand variability only
  SS = Z x sigma_d x sqrt(L)
     = 1.65 x 40 x sqrt(9)
     = 1.65 x 40 x 3
     = 198 units

demand and lead time variability
  SS = Z x sqrt( L x sigma_d^2 + demand^2 x sigma_L^2 )
     = 1.65 x sqrt( 9 x 1600 + 40000 x 4 )
     = 1.65 x sqrt( 14400 + 160000 )
     = 1.65 x 417.6
     = 689 units

reorder point = demand x L + SS = 200 x 9 + 689 = 2,489 units

raising the target to 99 percent, Z = 2.33
  SS = 2.33 x 417.6 = 973 units, a 41 percent increase in buffer stock

The two calculations differ by a factor of three and a half, and the gap is the answer. Lead-time variability contributes 160,000 to the variance against demand's 14,400 — more than ten times as much — so almost all the buffer exists to absorb an unreliable supplier rather than an unpredictable customer.

That reframes the problem entirely. Forecasting effort aimed at demand will barely move this number, while getting the supplier's lead time from nine days plus or minus two to nine days plus or minus half a day would cut safety stock by roughly half. The cheapest inventory reduction in most supply chains is supplier reliability, not a better model.

The service-level line is the other thing to say aloud. The relationship between service level and stock is non-linear because Z grows faster than the probability it buys, so the last few per cent are disproportionately expensive. Going from 95 to 99 per cent costs 284 more units of permanent working capital for four percentage points of availability, and whether that is worth it is a commercial judgement about the margin on the item and the cost of a stockout.

Two caveats worth naming before an interviewer does. The formula assumes normally distributed demand, which fails badly for slow-moving and intermittent items where a Poisson or a bootstrapped distribution is closer. And it assumes the two variabilities are independent, which is exactly wrong when a demand spike causes your supplier's lead time to stretch — the case where you most needed the buffer.

Service level as used in the safety-stock formula is the probability of not stocking out during a replenishment cycle — a cycle-based measure. Fill rate is the proportion of demand actually satisfied from stock, which is unit-based. They diverge because a stockout in a low-demand week costs few units and one in a peak week costs many, so a business can hit a ninety-five per cent cycle service level and a materially worse fill rate. Knowing which one the business is managed on matters, because they imply different stocking policies and the formula you reach for encodes an assumption about which the company actually cares about.

A single, permanent ten per cent rise in consumer demand, and the same reasonable rule applied independently at each tier.

Consumer demand rises from 100 to 110 units a week, once, permanently.
Each tier's rule: order what you sold, plus enough to rebuild one week of cover
at the new rate.

tier              demand it sees   order it places              change vs before
----------------  ---------------  ---------------------------  ----------------
retailer          110              110 + 10 rebuild             120    +20%
distributor       120              120 + 20 rebuild             140    +40%
manufacturer      140              140 + 40 rebuild             180    +80%
component maker   180              180 + 80 rebuild             260   +160%

The following week, demand stays at 110 and cover is rebuilt everywhere.
tier              demand it sees   order it places              change
----------------  ---------------  ---------------------------  ----------------
retailer          110              110                          110    -8%
distributor       110              110 - 10 excess              100   -29%
manufacturer      100              100 - 40 excess               60   -67%
component maker    60               60 - 80 excess                0  -100%

Nobody behaved irrationally. Each tier saw a demand increase, ordered enough to serve it and to restore its target cover, and passed the amplified signal upstream. Four tiers of a locally sensible rule turned a ten per cent change into a hundred and sixty per cent swing, and then into a complete stop.

The second table is the part usually left out and it is where the real damage sits. The component maker builds capacity for 260 and then receives zero, so it has hired, tooled and bought material for demand that never existed. Recovery from that overshoot takes longer than the original spike, which is why the oscillation persists for months after the demand change that started it.

The causes are worth naming as a set because each has a distinct fix. Demand signal processing — forecasting from your customer's orders rather than from actual consumption — is fixed by sharing point-of-sale data upstream. Order batching, where a weekly order looks like a spike, is fixed by smaller, more frequent orders. Shortage gaming, where buyers over-order when allocation looms, is fixed by allocating on historical share rather than on current orders. And price promotion, which pulls demand forward and creates a trough behind it, is fixed commercially or not at all.

The engineering point is that visibility is the lever. Every one of those fixes is an information problem, which is why supply-chain integration work is justified on inventory reduction rather than on transaction efficiency.

Because a long but reliable lead time can be planned around: you order earlier and hold pipeline stock, and the cost is working capital rather than availability. Variability cannot be planned around, only buffered, and the buffer grows with the variance rather than with the mean — which is why it dominates the safety-stock arithmetic. A supplier at twenty-one days plus or minus one is easier to run than one at nine days plus or minus five. This is also why "reduce lead time" is frequently the wrong improvement target and "reduce lead-time variance" is the right one, and why measuring supplier performance on average delivery days rather than on variability hides the problem.

The stock level at which you place a replenishment order, set so that expected demand during the lead time plus a safety buffer is covered. It works when demand is reasonably steady and the lead time is reasonably stable, because both assumptions are baked into the number. It breaks down for intermittent demand, where most periods see zero and the average is meaningless; for items with a strong trend, since the point is calibrated on a rate that is already out of date; and around promotions, where known future demand should drive the order rather than a threshold reacting to it. Those cases want forward-looking requirements planning rather than a trigger level.

It is the monthly cycle in which commercial and operational plans are reconciled into one set of numbers: what the business intends to sell, what it intends to make or buy, and what that implies for capacity, labour and cash. An engineer cares because it is where the numbers your systems consume actually come from, and because it explains a great deal of otherwise baffling data. Forecasts arrive as monthly buckets that someone has manually overridden, consensus numbers differ from statistical ones, and both are revised retrospectively. A pipeline that treats the forecast as an immutable fact rather than a versioned, overridable, auditable artefact will be wrong in a way nobody can explain.

A commercial invoice stating what the goods are, what they are worth and who owns them, which is what duty is assessed on. A packing list describing how they are packed, which is what a customs officer checks against. A transport document — a bill of lading for sea, an air waybill for air, a CMR note for road — which evidences the contract of carriage and, for a negotiable bill of lading, title to the goods themselves. Then certificates as required: origin, phytosanitary, dangerous goods. The engineering consequence is that a shipment cannot move without a document set that is consistent across all of them, so document generation is a validation problem rather than a formatting one.

The terms allocate three separate things, and candidates almost always collapse them into one.

term  delivery happens at        main carriage paid by   risk passes to buyer
----  ------------------------   ---------------------   ----------------------
EXW   seller's premises          buyer                   at collection
FCA   named place at origin      buyer                   when handed over
FOB   on board the vessel        buyer                   once on board
CFR   on board the vessel        seller                  once on board
CIF   on board vessel, insured   seller plus insurance   once on board
DAP   named place at destination seller                   on arrival, unloaded not
DDP   named place, duty paid     seller plus duty         on arrival, cleared

FOB, CFR and CIF are sea and inland waterway terms only.

The three columns are the answer. Where delivery happens, who pays for the main carriage, and where risk transfers are independent choices, and CFR and CIF exist precisely to separate them: the seller pays the freight to the destination port and yet risk passed to the buyer back at the origin, on board. A candidate who says "CIF means the seller is responsible until arrival" has merged the payment column into the risk column, which is the single most common error and the one an interviewer is listening for.

The engineering consequences are concrete. The term determines who books the carrier, so it decides which party's TMS holds the shipment. It determines who is the importer of record, so it decides who files the customs declaration and who owes the duty. And it determines when revenue can be recognised and when title and insurable interest transfer, so it reaches into the finance system as well as the logistics one.

The trap worth pre-empting is FOB used for air or road freight, which is extremely common in purchase orders and is meaningless — there is no vessel to be on board of, so the point of risk transfer is undefined and a dispute has nothing to resolve against. FCA is the term that was meant. Saying so unprompted signals that you have read a real purchase order rather than a summary table.

The Harmonised System code is an internationally agreed classification of goods, six digits globally with further national digits, and it determines the duty rate, the import restrictions and the licensing requirements for a product. It causes trouble because classification is genuinely ambiguous — a garment's code depends on fibre content, knit or woven, and gender, and a device's code depends on its principal function — so two competent people classify the same item differently. The consequence for systems is that an HS code is master data with an owner, an effective date and an audit trail, not a field a merchandiser types freely, because a wrong code is either underpaid duty recoverable years later or a shipment held at the border.

Because the authority, not you, decides when each transition happens, and it can hold, query, inspect or release on its own schedule. Your system submits a declaration and then waits, receiving asynchronous responses that may be an acceptance, a request for documents, a physical inspection notice or a release. That shape has specific implications: there is no synchronous call to model it with, timeouts mean nothing because a hold can last days, and the shipment's state must represent "submitted and waiting" as a first-class condition rather than an in-flight request. It also means clearance status has to be visible to customer-facing ETAs, since a held container has no meaningful delivery estimate at all.

The goods value, the freight, insurance, duty, import taxes, brokerage and any handling or terminal charges — that is, everything required to get the goods to their destination and cleared. It matters because the goods price alone is a poor basis for a sourcing decision: a cheaper supplier further away with a higher duty rate frequently lands more expensively, and the difference is routinely ten or twenty per cent. For systems, the awkward part is timing. Several components are not known until after the goods have shipped, so landed cost is an estimate that is later trued up, and the reconciliation between estimated and actual is a real accounting process rather than an edge case.

It is checking the parties to a transaction — customer, consignee, intermediary, sometimes the vessel — against sanctions and restricted-party lists before goods or money move. It cannot be a nightly batch for two reasons. The lists change without notice, so a party cleared last night may be listed by the time you ship, and the obligation attaches to the transaction rather than to a periodic review. And the check must block, because shipping to a listed party is a criminal matter, not a compliance ticket. That makes screening a synchronous gate on order acceptance and again on despatch, with fuzzy name matching, a human review queue for possible matches, and an auditable record of who cleared what and when.

Most integration arguments in this domain are really disputes about which system is the record for a given fact.

system  system of record for                        does not own
------  -----------------------------------------   ----------------------------------
ERP     financial inventory value, purchase and     bin locations, pick tasks, routes,
        sales orders, supplier and customer         real-time stock movement
        master data, costing
OMS     the customer promise, order state,          where stock physically sits,
        allocation across nodes, sourcing rules     how it is picked
WMS     bin-level stock, tasks, labour, handling    the customer relationship,
        units, receipts, despatch confirmations     freight rates, financial value
TMS     loads, routes, carrier rates, tendering,    bin-level stock, order promises,
        freight audit and settlement                inventory value

Read it as a set of boundaries and the common failures become obvious. The ERP holds an inventory value and the WMS holds an inventory position, and they will not agree at any given instant because one is updated on a financial event and the other on a physical one. Trying to make them agree continuously is the integration project that never finishes; agreeing a reconciliation cadence and a tolerance is the answer.

The OMS boundary is the one most often missing altogether. Without it, promise logic ends up split between the web front end and the ERP, and multi-node sourcing — deciding which warehouse or store fulfils an order — has nowhere to live. That decision needs stock positions from every node, carrier transit times from the TMS and margin rules from the ERP, which is precisely why it deserves its own system rather than a query in a checkout controller.

The TMS boundary matters for cost. Freight audit — checking that the carrier invoiced what it quoted for the service it actually delivered — recovers a few per cent of freight spend and requires the rate, the tender, the actual execution and the invoice in one place. Scatter those and nobody ever checks.

The interview point is that "we will integrate the WMS and the ERP" is not a design. Naming which facts flow in which direction, at what latency, and what happens when they disagree is the design, and the disagreement case is the one candidates skip.

Between the sales channels and the fulfilment systems, and what it decides is the promise. It takes an order, works out which node should fulfil each line — weighing stock availability, transit time to the customer, capacity at the site, shipping cost and margin — reserves the stock, and publishes the promise the customer sees. That single decision is where availability, cost and speed are traded, so it is the highest-value logic in a retail supply chain and the hardest to test. Splitting an order across nodes to fill it completely doubles the shipping cost, and choosing not to is a lost sale, and the OMS is where that trade is expressed as policy rather than accident.

Because it works, it is universal in the industry, and the cost of changing it falls on the wrong party. A carrier with four thousand trading partners has no incentive to adopt your API, since every partner would need to change; the network effect that made EDI standard also makes it immovable. It is also more capable than its reputation suggests — the message set covers ordering, despatch, status, invoicing and settlement, with agreed semantics that took decades to negotiate. So the realistic engineering position is not replacing EDI but wrapping it: an internal event model with EDI as one transport among several, rather than EDI structures leaking into your domain.

The same fact — a carrier reporting a status event — in the two formats you will have to support simultaneously.

EDI X12 214, transportation carrier shipment status message

ISA*00*          *00*          *ZZ*CARRIER123     *ZZ*SHIPPER99      *260727*0912*U*00401*000000001*0*P*>
GS*QM*CARRIER123*SHIPPER99*20260727*0912*1*X*004010
ST*214*0001
B10*4938201*SHP0001192*ACME
L11*ORD-88213*OQ
AT7*X6*NS***20260727*0910*LT
MS1*LEEDS**GB
SE*6*0001
GE*1*1
IEA*1*000000001

{
  "shipmentId": "SHP0001192",
  "carrierScac": "ACME",
  "references": [{ "type": "customerOrder", "value": "ORD-88213" }],
  "event": {
    "statusCode": "X6",
    "reasonCode": "NS",
    "occurredAt": "2026-07-27T09:10:00+01:00",
    "recordedAt": "2026-07-27T09:12:00+01:00",
    "location": { "city": "Leeds", "country": "GB" }
  }
}

The information content is nearly identical, which is the first point: EDI is not less capable, it is less readable. AT7*X6*NS carries a status code and a reason code exactly as the JSON does; B10 carries the carrier's reference and the shipper's shipment identifier; L11 with qualifier OQ carries the customer order number. Every field is positional, and the qualifiers are what make an untyped segment meaningful.

The real differences are operational rather than semantic. EDI is batch and file-based, arriving by FTP or a value-added network on a schedule, so latency is measured in tens of minutes and a failure is a file nobody processed. The envelope layers — interchange, group, transaction — exist to batch and acknowledge, and the functional acknowledgement is a separate message, so delivery confirmation is asynchronous and must be reconciled.

The trap in the JSON version is thinking the problem was the format. It was not. Both need the same mapping from a carrier's status vocabulary to yours, and that mapping is where the bugs live: X6 means "in transit" for one carrier and something narrower for another, and reason codes are frequently used inconsistently by the depots that key them.

So the design that survives is the same for both: parse to a canonical internal event, keep the raw payload, and treat the transport as a detail. Teams that model their domain on the EDI segments end up with a shipment table that has a column called L11_OQ, and teams that model it on one carrier's JSON discover the second carrier disagrees.

Addresses and product dimensions. Addresses because they are free text that must resolve to a real deliverable location with a postcode, an access constraint and sometimes a geocode, and because the same place arrives spelled six ways from six channels. Dimensions and weights because everything downstream depends on them — cube utilisation, carrier rate selection, load planning, duty — and they are typically entered once by someone with no reason to be accurate. A product recorded as ten centimetres tall when it is a hundred silently corrupts every load plan it appears in, and the error is invisible until a trailer is half empty or a carrier surcharges you for a remeasure.

It assumes a carrier integration is a client library, when it is a long-lived relationship with a system you do not control and cannot test against properly. Carriers differ in status vocabularies, label formats, rate structures, cut-offs, cancellation windows and how they behave when they are wrong. Their sandbox does not reproduce their production behaviour, their rate limits are undocumented, and their status feed is eventually consistent with reality rather than authoritative. So the design question is not how to call the API but how to normalise many carriers behind one internal model, how to hold state when a carrier is unreachable, and how to reconcile when their view and yours differ.

Because "how many do we have" resolves into at least five different quantities with different owners: physically on hand, allocated to orders, quarantined, in transit inbound, and available to promise. Each is maintained by a different process, updated at a different moment, and correct for a different question. Add to that the fact that the physical count is itself an estimate between cycle counts, and the honest answer is that inventory is a set of reconciled figures with a known error rate. Candidates who model stock as one integer produce systems that oversell, and the oversell is discovered by a picker at a bin rather than by a check at checkout.

That the interviewer is not testing recall of the eleven terms; they are testing whether you know the terms allocate cost, risk and delivery point separately. The trap answer treats them as a spectrum from "buyer does everything" to "seller does everything", which handles EXW and DDP and gets CFR and CIF exactly wrong — in both, the seller pays the freight to destination while risk passed to the buyer at the origin port. The second half of the trap is stating a term without noticing it is being used for the wrong mode, which happens constantly with FOB on air freight and is the detail that shows you have seen real paperwork.

Whether you understand that the question is about uncertainty rather than prediction. A strong answer decomposes the estimate into its components — order cut-off, pick and pack capacity, carrier collection, line haul, depot sort, position in the delivery round — and identifies which carry the variance, which is almost always the last mile and the number of stops ahead. It then says what the model should output: a distribution rather than a point, so a window can be quoted with a stated confidence and narrowed as the day progresses. It names the metric as window hit rate rather than mean error, because the customer experiences the promise and not the average. And it names the cases where the honest output is no estimate at all — a customs hold, a missed cut-off, a failed first attempt.

A weak answer calls the carrier's tracking API and displays what it returns, delegating the hard part to a system that does not know your pick capacity, then adds a safety margin. That margin is the tell: padding every estimate protects the metric and loses the sale, because a customer choosing between two retailers reads the padded window as the slower option.