Predicted, planned and promised must never share a field

A predicted ETA is the system's current best estimate of when a vehicle will reach a stop, computed from where it is now, how the roads ahead are behaving, and how much work remains before it gets there. It changes without anyone touching it. That single property makes it a different kind of value from the other 2 arrival times most operations carry, and it is why all 3 need their own column.

The planned arrival is an output of the route plan: the optimiser fixed a sequence, added travel and service time, and produced a time the vehicle was expected at each stop. It is frozen when the plan is published. The promised window is a commercial artefact — 2 clock times, say 08:00 to 12:00, that somebody sold or agreed. It moves when a person moves it, not when traffic does. Keeping the 3 apart is the foundation of ETA prediction and shipment visibility.

Where each of the 3 numbers comes from

3 values give 3 subtractions, and each answers a question the others cannot. Predicted minus promised is the lateness a customer feels, and it is the only one worth an alert. Predicted minus planned is execution variance: it says whether the day is running as the plan assumed, which is a signal about service times rather than about a driver. Planned minus promised is slack, and almost nobody computes it. If it is minus 25 minutes at 06:00, that promise was never going to be kept and no amount of live tracking will rescue it.

A prediction is allowed to change itself. A promise may only be changed by someone who can be named.

Who is allowed to see which number

• The customer. The promise always, with the prediction shown inside it rather than instead of it. A page showing a bare live estimate has replaced a commitment with a guess, and the customer will hold you to the guess.
• The driver. The plan as a sequence, plus their own predicted arrival at the next 1 or 2 stops. A promised window for a stop 3 hours out is an invitation to resequence, and that trade-off belongs to selling a slot versus showing a live ETA.
• Goods-in at the receiving site. The prediction only. A team staffing a dock needs to know when a vehicle turns up; the commercial window is another company's contract and the planned time went stale at 07:00.
• The exception desk. All 3 side by side, each stamped with when it was last computed. This is the 1 screen where the 3-column model visibly earns its keep.

What it costs to store them in one column

Collapse the 3 and the write path becomes ambiguous. A traffic feed overwrites a commitment; a replan overwrites a slot the customer chose. Nobody notices, because the field always holds a plausible time. 6 weeks later somebody asks what share of deliveries hit their window, and there is no honest answer: the column holds whatever was written last, which for an on-time delivery is close to the actual arrival and for a late one is a prediction made 20 minutes before the door opened. The measured hit rate comes out flattering and wrong.

The clean version keeps the 3 as separate fields and treats arrival itself as an event rather than a 4th number — the discipline in the milestone vocabulary a shipment moves through. Fields hold expectations, events hold facts, and only the event is immutable.

The record shape that can answer "was it late"

1. Give the shipment 4 named fields, not 1: planned_arrival, predicted_arrival, promised_from, promised_to. No job writes to more than 1 of them.
2. Attach provenance to each: plan_version for the planned time; model_version and computed_at for the prediction; changed_by and change_reason for any movement of the promise. A promise with no changed_by is an unaudited commitment.
3. Append every material change of the prediction to a history table. Without it you can only score the last estimate before arrival — the estimate the customer never saw, and the one that flatters a model most.
4. Record arrival as an event carrying its own source: geofence crossing, driver confirmation, or a scan at the door. Derive lateness from that event against the promise.
5. Keep the width of the window, and the share of arrivals it is meant to catch, as properties of the promise itself. That is a separate claim with its own arithmetic, in the interval around an ETA.

Most of the work in keeping the 3 apart is plumbing. A customer emails "any chance after 2?", and something has to turn that into a promise change with a name on it rather than a note in a thread. A job recomputes predictions every 60 seconds and must touch nothing else. That is ordinary operations automation under the constraints any automated step carries in a live system — narrow scope, a human on anything that alters a commitment, 1 audit line per change — the argument in running AI agents in production. It is also what separates a logistics and mobility platform whose on-time figure can be audited from one whose figure can only be believed.

• ETA
• shipment visibility
• data modelling
• delivery promises