Over the weekend a planner pulled up the inbound list and counted forty-one containers due into Los Angeles and Long Beach across the next three weeks. Every record carried the same destination stamp. Not one of them named a terminal. Around 250 ILWU watchmen at the two ports had voted to authorize a strike, and the terminals those watchmen staff handle roughly 85% of Long Beach's cargo but only about a third of the cargo moving through Los Angeles, according to figures from the employers' association. The deadline slid from the first of November toward the fourth while mediated talks continued. The planner could not say which of the forty-one boxes were exposed.
That gap is the problem worth fixing, and it has nothing to do with the strike. A labor unit representing about 2% of the workforce at a port complex can gate most of the cargo on one side of the harbor and a minority on the other. The two ports face each other across the same water. On a map they read as one place. Operationally that weekend they were two very different places, and the terminals inside each one were different again. When your shipment records resolve to "Los Angeles / Long Beach" and stop there, you are left with two bad options: treat all forty-one boxes as at risk and spend money you did not need to spend, or treat none of them as at risk and find out which ones mattered a week later.
A port code names a gateway, not a place
Most shipment records carry a UN/LOCODE: USLAX, USLGB, NLRTM, DEHAM. The code was built for routing and customs declarations, and it does that job well. It was never built to tell you where a box physically sits or who is handling it.
A port is closer to a landlord than an operator. Inside it, terminals are run by different companies, on different gate systems, with different labor arrangements, chassis pools and clocks. Rotterdam is a dozen terminals. Los Angeles and Long Beach together are more than a dozen. Treating any of them as a single unit works right up until something stops at one of them, which is the same granularity problem that makes a port closure at origin so hard to scope while it is happening.
The constraint almost always lives at the terminal
Walk through what actually changes when cargo is late at a gateway, and nearly all of it is set at terminal level.
Appointment systems are terminal-specific, and so is how far ahead slots open. Gate hours and weekend shifts differ between terminals in the same harbor. Chassis pools are tied to terminals. Free time starts on the terminal's clock, which is why container dwell time only becomes comparable once you know whose rules each box sits under. Congestion is terminal-specific too: one berth can run fluid while the one beside it is four days deep.
So the operational questions your team actually asks, which boxes can we pull this week, where will demurrage start first, what do we tell the plant, all resolve at terminal level. The port code cannot answer any of them.
Three parties already know your terminal
Nobody has to go find this information. It exists in three places, in three shapes, on three clocks.
The ocean carrier knows the terminal from the berth assignment and carries it on the booking and the arrival notice. The forwarder knows it too, usually on the arrival notice or the delivery order. The terminal itself publishes availability against the container number, the most authoritative source and the last to arrive.
The reason teams still cannot query by terminal is not missing data, it is unreconciled data: three sources that name the same facility three different ways, arriving at three different moments, none of them in a field. This is the same join problem that makes carrier and forwarder tracking disagree on a rollover, and it is solved the same way. A command center like Orkestra exists to sit above the systems that already hold these records, normalize what each one calls the same terminal, and keep the result in one place your team can actually sort by. Pre-built connectors matter here for an unglamorous reason: the terminal field is worth very little unless it arrives on every box automatically, every day, without anyone opening a PDF.
Store the terminal as a field, not as a sentence
Most teams technically have the terminal somewhere. It is in an arrival notice attachment, or in an email, or typed into a free-text note by whoever happened to read the notice. That is storage, not data.
Make the terminal a first-class field with three properties: a normalized value, a timestamp for when you learned it, and a source so you know who told you. Those three turn a scattered fact into something you can filter, group and alert on. The test is simple: can someone on your team produce, in under a minute and without opening an attachment, the list of every inbound container currently assigned to one named terminal? If not, the field does not really exist yet.
Terminal assignment is a moving value
The field is not static, and this is where teams who do capture it still get caught. Vessels get reassigned. Berth windows shift under congestion. A port omission moves the whole call. Transshipment changes the discharge terminal entirely, often after you have planned around the first answer.
So treat a terminal change as an event, not an attribute that quietly overwrites itself. A box that moves terminals has changed its exposure, its free time clock and possibly its drayage provider, and somebody should be told the day it happens rather than the week the invoice arrives. This is ordinary exception management work: detect the change against what you previously believed, judge whether it matters, route it to whoever owns the consequence. It is worth doing properly, because across the industry 62% of supply chain exceptions are still caught only after they have reached the customer, and a silent terminal reassignment is exactly the kind that hides until the demurrage lands. The same logic applies further inland, where tracking a container after it arrives at the port depends on knowing which gate you are actually working against.
Turn the terminal into exposure, not trivia
Knowing the terminal is only useful if it changes a decision, and that means weighting it. Group the inbound list by terminal, then rank each group by what is behind the box: order value, the customer commitment it covers, whether a production line is coupled to it, how much recovery time the lane leaves you.
Now the output is not a count of exposed containers, it is a ranked list of exposed commitments. Twelve boxes at a gated terminal are not twelve problems: two hold components a plant needs on Thursday, and the other ten can wait a week at no real cost. That shift from counting units to ranking consequences is what a disruption playbook runs on, and it only works at a granularity that matches where the constraint sits. One grocery store supplier working with Orkestra got to carton-level traceability across its entire supply chain for the first time, and took 15% out of its costs in the process. The pattern holds: the useful granularity is almost always one level finer than the one your systems default to.
What to do Monday
Pull your current inbound list and check whether the terminal appears as a field on every row. If it appears on some rows and not others, find out which source populated the ones that worked, because that is the feed to standardize on. Then pick your three highest-volume discharge ports and write down, per terminal, who tells you the assignment and how early. That takes an afternoon and exposes the real gap, which is rarely the data and almost always the shape it arrives in.
The strike deadline at Los Angeles and Long Beach may pass quietly, and the next one will land somewhere else. Neither outcome changes the work. Disruption keeps arriving at a finer grain than the port code your systems were built around, and teams that can sort cargo at terminal level answer in minutes what everyone else spends a week assembling. If that sorting is the slow part for your team, fix that piece first. See what full visibility looks like when every box already carries the field you need to sort by.
