An inference pool for a container terminal
A container terminal is a large outdoor site where vehicles, cranes, and inspection cameras all need models they cannot carry. One pool in the terminal's own building serves them, and the feeds stay on site.
· 4 min read
IN SHORT
A container terminal installs its inference pool as Czar nodes in the terminal's own building, joined as one Grid, and serves perception and decision models to automated vehicles, cranes, and inspection points over the terminal's own network. Feeds from the quay, the stacks, and the gate stay on the terminal. Each machine keeps its own reflexes, and its stops and limits stay where its vendor set them.
A container terminal is the largest kind of facility an inference pool serves, and the one with the most weather in it. Automated vehicles cross the yard between the quay and the stacks. Cranes lift boxes off ships, out of stacks, and onto trucks. Cameras at the gate and along the lanes read numbers, seals, and damage on steel that has crossed an ocean. All of it is outdoors, in salt air, rain, glare, and fog, and all of it is on a site the terminal operator secures as a perimeter.
Each of those machines has a vendor, a fleet system, and an on-board model. Each is now asking for models it cannot carry: perception that handles a wet container face in low sun, decisions about a lane blocked by a stalled truck, language that lets a controller ask the system a question in words. The pool is where those models run, and on a terminal the pool belongs in the terminal's own building.
One site, several kinds of machine
Terminals are not homogenous fleets. The automated vehicles came from one vendor, the crane automation from another, the gate system from a third, and the inspection cameras from whoever installed the lanes. Each system keeps its own software and its own fleet management. The pool replaces none of it.
What the Czar Grid does is serve inference to every one of those consumers over the terminal's own network, within each one's latency budget. A vehicle needing a decision about a crossing and a crane needing a read on a twistlock are drawing from the same pool. Neither is sending its frames out of the gate to be understood.
The quay and the stacks
At the quay, the perception load is on the crane. Landing a spreader on a container on a moving ship, confirming the lock, lifting through a wind gust. The crane automation has its own tight control loop, and that loop is not the pool's business. What the pool serves is the heavier perception around it: whether the box in the cell is the one expected, whether its doors are damaged, whether a person is somewhere they should not be.
In the stacks, the automated vehicles and stacking cranes carry the load. Vehicles need decisions about routing, about an obstruction, about whether what the camera sees is a chock or a dropped lashing bar. The pool serves those decisions. The vehicle's own stops and speed limits remain the vehicle's, set by its vendor, and the Grid has no path to change them. A pool that fails leaves a vehicle that stops in its lane.
The gate
The gate is the terminal's reading problem. Every truck arriving or leaving presents containers, seals, placards, license plates, and paperwork, and the terminal has to confirm all of it before the gate opens. On-board and lane-side models do the clean reads. The pool does the hard ones: the number half-covered in rust, the seal at a bad angle, the placard faded by sun.
Those gate images are of the terminal's customers' cargo, and they stay on the terminal. The models that read them run on the pool, the record of the read stays on the pool, and the adapted weights the terminal builds from its own gate footage stay with the terminal.
Weather, light, and the terminal's own footage
No perception model arrives knowing this terminal's light. Morning glare off the water, afternoon shadow from the cranes, night under sodium lamps, winter fog. Substrate adapts the models on the pool using the terminal's own captures, taken by its own cameras and vehicles across its own seasons. Nothing leaves. The adapted model is evaluated and recorded before it is served, and the record shows which version was in use on any given shift.
Posture at the perimeter
A terminal is a connected site with a hard perimeter. The terminal system has to know where every box is. The vendors' fleet software has to see its machines. Local Bridge permits those declared routes and denies egress by default. Camera feeds, captures, task records, and the record of every decision stay on the operator's hardware inside the operator's network.
Site tasks for vehicles and inspection are authored in Agency Studio, bounded by zone, speed, and distance, approved by named roles, and recorded run by run. The commercial form is one subscription for the configured Grid, which does not move as the terminal adds vehicles. For the wider picture, see Solutions for ports. For the inland site with rail and trucks but no quay, see An inference pool for an intermodal yard.
Questions this raises
- Where does the pool physically sit on a terminal?
- In the terminal's own building, in its own rack, in a conditioned space the terminal already secures. The terminal network carries inference to the vehicles, cranes, and gate systems outdoors.
- Can the pool serve an automated vehicle fleet and the crane systems at the same time?
- Yes. The Grid is one pool for the whole terminal, serving each machine within its own latency budget. The vehicles, the cranes, and the gate are separate consumers of the same pool.
- What happens to a vehicle when the pool is unavailable?
- It falls back to its own on-board model or stops, according to the behavior its vendor built. The pool serves perception and decisions and has no authority over the vehicle's stops or speed limits.
KEEP READING