The Milestones Dictionary: What “Arrived,” “Discharged,” “Available,” and “Gate-Out” Actually Mean

In ocean logistics, most disagreements aren’t about where the cargo is. They’re about what a milestone really proves—and whether it’s actionable.

One carrier says “arrived.” A terminal says “available.” Someone else says “released.” Meanwhile, ops is asking the only question that matters: what can we do next?

This post is a practical milestones dictionary you can use across teams (ops, customer service, finance) to reduce confusion, prevent premature customer updates, and build a shared “truth set.”

Why milestone language breaks ops (even when the data is correct)

Milestones are not just status labels. They’re operational claims that can mean different things depending on:

scope (vessel vs container vs shipment)
location (port limits vs berth vs terminal yard)
proof level (forecast vs confirmed event)
process stage (ocean leg vs terminal handling vs inland pickup)

Industry standards exist to reduce this confusion by standardizing definitions and event models for track & trace, but day-to-day operations still require a clear translation into “what this means for us.”

Two rules that eliminate most confusion

Rule 1: Separate forecasts from evidence

ETA is a forecast.
A milestone event is evidence that something happened.

If a label changes your plan (expedite, rebook, update customer delivery), you need evidence-grade milestones—not “hope-grade” timestamps.

Rule 2: Always ask: “What’s the next actionable milestone?”

A milestone is only useful if it triggers one of these:

a decision (reroute, reallocate, change appointment)
a handoff (broker, drayage, warehouse)
a financial exposure check (storage, D&D, penalties)
a customer update (state change that won’t be retracted)

Milestone definitions that stay useful across carriers

This table is intentionally “ops-first.” It focuses on what a milestone proves, who acts, and what teams often misread.

Milestone term	What it usually means (plain language)	What it proves	Who should act	Common misread	Safe internal stance
Arrived	The vessel has reached the destination location where cargo operations can begin (often tied to being berthed/ready to work)	The transport leg is at its destination stage	Ops planning, customer service	“Cargo is already discharged”	Treat as “port call phase started” unless discharge is confirmed
Berthed	Vessel is alongside the berth (a stronger form of “arrived” in many port contexts)	Handling can start (subject to terminal operations)	Ops planning	“Discharge is imminent / complete”	Watch for discharge confirmation, not just berth status
Discharged	Container/cargo has been taken off the vessel	Cargo is physically off the ship and in terminal control	Destination ops, broker	“Pickup is possible now”	Discharge ≠ released/available for pickup
Available	Cargo is ready for pickup under the terminal/carrier’s conditions (often after discharge + internal processing)	Pickup may be possible if release prerequisites are met	Destination ops, drayage	“Customs/billing is cleared”	Confirm release artifact + appointment feasibility
Released	A release condition is met (customs release, carrier release, or both—depends on context)	One blocking gate is cleared	Broker/ops depending on release type	“We can gate-out today”	Confirm which release gate cleared and what still blocks pickup
Gate-in	Container entered terminal gate	Terminal has physical custody at origin	Origin ops	“Loaded soon”	Gate-in is necessary, not sufficient for loading
Loaded	Container is loaded onto the vessel	Container is physically on board the intended vessel	Ocean ops, customer service	“Departed already”	Loaded is stronger than ETA changes; still watch for departure confirmation
Departed	Vessel has departed from port	The ocean leg is in motion	Ops planning	“No more changes will occur”	Expect ETA drift; treat this as evidence start point
Rolled / Rollover	Container was not loaded as planned and is moved to a later sailing	The original plan is invalid	Ocean ops, customer service	“Minor delay”	Treat as a plan failure; trigger rebooking/priority review
Gate-out	Container exited the terminal gate	Physical custody transferred out of terminal	Destination ops, drayage, finance	“Delivered”	Gate-out ≠ delivered; it starts inland exposure tracking
Delivered	Cargo reached the delivery location (varies by contract/inland leg)	Customer receives cargo (or final handoff completed)	Customer ops, finance	“Paperwork is done”	Closeout still needs POD, charges, claims checks
Empty returned	Empty container returned to depot/yard (where tracked)	D&D exposure may stop (depending on terms)	Ops, finance	“All charges stop automatically”	Confirm stop points in your contract/terms

How to use this table:
Create one internal rule per milestone: “When we see X, we do Y.”
That’s how you prevent the same debate from repeating in every shipment thread.

A clean “truth set” format for internal updates

If you want ops, sales, finance, and data to agree, stop sending screenshots and start sending a structured truth set:

Last confirmed milestone: what happened
Timestamp + location: when/where it happened
Next expected milestone: what should happen next
Stance: Wait / Work / Escalate (one word)
Owner + next action: one accountable party

This forces clarity without overpromising.

The four milestone confusions that cause the most rework

1) “Arrived” vs “Discharged”

Arrived is often about the vessel and port call phase. Discharged is about the container leaving the vessel.

Fix: treat discharge as the first “cargo is off ship” proof point.

2) “Discharged” vs “Available”

Discharged means the container is in terminal control. Available means the terminal/carrier considers it pickup-ready under their processes.

Fix: don’t trigger drayage pickup based on discharge alone.

3) “Released” vs “Pickup-ready”

Release can mean different gates (customs vs carrier vs terminal readiness). Pickup-ready requires all gates plus practical execution readiness.

Fix: always specify which release cleared.

4) “Gate-out” vs “Delivered”

Gate-out starts the inland leg. It’s not delivery.

Fix: stop using gate-out as a customer delivery promise.

How to operationalize this (without a big systems project)

You can implement a milestone dictionary with three lightweight moves:

1) Define the 10–12 milestones you will act on
Don’t try to standardize everything. Standardize what drives decisions.

2) Attach an owner to each milestone
Example: discharge/available = destination ops; rollover = ocean ops; D&D exposure points = finance + ops.

3) Create “customer-visible states” that are less volatile than raw milestones
Example: Planned → Confirmed Sailing → Arriving → Available → In Delivery → Closed → Needs Attention
This reduces retractions and keeps communication credible.

The Milestones Dictionary: What “Arrived,” “Discharged,” “Available,” and “Gate-Out” Actually Mean

Why milestone language breaks ops (even when the data is correct)