Submitted Sep 21, 2026
Ask a vendor how their yard computer vision works and you will hear about models. Detection accuracy, training data, the architecture behind the plate read. All of it real, and none of it the reason deployments fail.
The models are largely a solved problem. Recognising a trailer, reading a container ID, classifying a vehicle type: this is well-trodden ground and has been for years. What separates a system that works at one site from one that works at forty is almost never the machine learning.
Chris Duncan, VP of Engineering at Terminal Industries, puts it plainly: "The vision side is under control. The physics is the hardest part."
That is an unusual thing for a technology vendor to say out loud, and it is the most useful thing anyone can tell an operator evaluating this category.
What "the Physics" Actually Means
In yard computer vision, the physics is everything about the real-world installation that determines whether a model can perform: where a camera can physically be mounted, how far it sits from the object it must read, what angle that produces, what power and network are available at that position, and what weather does to the lens between visits.
Every one of those is site-specific, none of them is improved by a better model, and collectively they decide whether a deployment succeeds.
Duncan describes the range operators should expect. "You can go to one site where the road layouts are perfect. You can put a camera in a perfect position where you've got a repeatable distance to your object, you've got a perfect field of view. You go to the next site where you can only put a camera on a bend and the distance is double or triple."
That second site is not a harder version of the first. It is a different engineering problem. "At that point you need maybe better sensors, better cameras, higher resolution, which means higher network bandwidth that you require. And yeah, that's the headache."
Then there is weather, which is not an edge case. "Before you get weather," Duncan says, "and how do you then assign a maintenance task when your lens is covered in snow. They're the biggest problems in terms of scaling a computer vision system in this domain."
A lens covered in snow is not a model failure. It is an operations failure, and a system that cannot detect and dispatch against it will silently degrade until someone notices the data stopped making sense.
Why Most Yard AI Demos Do Not Survive Deployment
The gap between a demo and an ROI is enormous
Duncan is candid about the state of the category, in a way that is worth quoting at length because it comes from someone building in it.
"The challenge is taking core technology and taking that next step into creating real-world applications that provide meaningful ROI for customers, that aren't just gimmicks. Because a lot of this stuff can feel a bit gimmicky. And that's the, it's a much bigger challenge than people think."
A controlled demo removes precisely the variables that break production systems. It is filmed at a good site, in good weather, at a good angle, on a good day. None of that is dishonest. It is just not evidence.
Models degrade even when nothing appears to change
There is a specific failure mode that operators rarely ask about and should.
"There's a concept called domain drift," Duncan explains, "and a lot of that actually is physics as well. But we have some very good closed-loop ML ops systems that deal with domain drift. What is that, he asks. That's, we can detect if our models aren't performing well. And actually most of the time our models aren't performing well because of the physics."
Domain drift is what happens when the world the model sees stops matching the world it was trained on. Vehicle types change. Carriers refresh their fleets and the markings change. New identifier formats appear. A camera shifts two degrees after a maintenance visit. Nothing broke, and accuracy falls anyway.
The question to ask a vendor is therefore not "how accurate is your model" but "how do you know when it stops being accurate, and what happens then". A system without closed-loop monitoring will not tell you it is failing. It will simply be wrong, quietly, until an operator loses trust in it.
Edge or cloud is a site-by-site decision, not a product decision
Where the processing happens is the other variable operators are rarely told is variable.
Duncan's summary: "Most mature architectures are usually hybrid." Neither wins outright, and the right answer depends on the deployment.
Edge processing gives lower latency, because inference happens next to the action, and better offline resilience, since decisions continue when the connection drops. Cloud gives elasticity, easier upgrades and centralised orchestration, plus the ability to run much larger models. On the edge, Duncan says, "you have to box clever with optimisation and squeeze as much out of it as possible."
The constraint that usually decides it is uplink. "We would like to do as much in the cloud as possible, but that means you need superior networking, and you need 24/7 uninterrupted upload. If you don't have that, what do you do? Well then you have to analyse what is your uplink. Is it 3G, 4G, 5G, Starlink. If it's something really low bandwidth, then your hand is forced."
At which point the architecture has to move toward the camera: an embedded device on site, compressing what it sends while still delivering the capability the customer bought.
The practical question for an operator is whether that split can be adjusted per site. Duncan's answer is yes, provided it was designed for. "If you've a well-architected system from the off, then you should be able to bisect your pipeline and just shift things around as you like."
Ask any vendor whether their edge-cloud split is fixed. If it is, every site you own has to meet the requirements of their architecture rather than the other way round.
Why You Cannot Just Point an LLM at the Yard
It is the obvious question, and Duncan raises it before anyone else can.
"People, if they don't ask the question, they're thinking it: why don't we just hook this all up to ChatGPT?"
His answer is a distinction between two different classes of system. Large language and vision-language models are reasoning systems. What runs at a gate is a perception system: what is in the image, where is it, what are the bounding box coordinates, what type of object is it, is that a trailer or a container, what is the container ID.
Those are narrow, high-volume, low-latency questions, and a purpose-trained model answers them faster, cheaper and more reliably than a general one. Reasoning models have their place further up the stack, but not in the loop that decides whether a gate arm lifts.
Underneath sits the constraint that governs the whole category. "Most operational or real-world AI is constrained by economics," Duncan says. "There is no free lunch in computer vision applications."
Generalised models cost more per inference. Customised models cost more to build and maintain. Quality, latency and operating cost pull against each other, and the job is landing somewhere on that triangle that still produces ROI. A vendor who claims no trade-off is either not running at volume or not counting the bill.
A Diagnostic: Questions to Ask a Yard Computer Vision Vendor
These are the questions that separate a production system from a pilot.
At how many of my sites can you achieve your stated accuracy, and what specifically disqualifies the others?
What is your minimum viable camera position, and what happens at a site where I can only mount on a bend?
How do you detect that a model has started underperforming, and how quickly?
What is the process when a lens is obscured by snow, dirt or glare? Is a maintenance task raised automatically?
Is your edge and cloud split fixed, or configurable per site based on my available uplink?
What uplink do you require at minimum, and what capability degrades if I cannot provide it?
Which parts of the pipeline use purpose-trained models and which use general-purpose ones, and why?
If a vendor answers all of these in terms of model accuracy, they have not deployed at scale yet.
What This Means for Buyers
There is a broader point buried in the engineering detail, and it goes to the difference between AI that is claimed and AI that is running.
Anyone can integrate a vision API. What is hard, expensive and slow is the unglamorous layer around it: site surveys, mounting strategy, power and connectivity, model monitoring, retraining pipelines, maintenance dispatch when a lens is dirty. That layer is invisible in a demo and it is the entire difference between a system that works on day one and one that still works in year three.
It is also, usefully, difficult to fake. A vendor who can describe their domain drift detection in detail has one. A vendor who cannot will discover the problem at your site.
Terminal's computer vision runs the gate automation and load verification modules of its Yard Operating System, and the company is a featured vendor in the 2025 Gartner Market Guide for Yard Management. For the applied version of the technology described here, see how OCR reads the plate and computer vision runs the yard.
Frequently Asked Questions
Why is computer vision hard in a yard? Because the constraints are physical rather than algorithmic. Camera position, distance to the object, field of view, available power and network, and weather all vary site to site, and none of them is improved by a better model. Detection itself is largely solved. Installing it reliably across dozens of dissimilar sites is not.
What is domain drift in computer vision? Domain drift is the gradual decline in model accuracy that occurs when the real-world conditions a model sees stop matching those it was trained on: new vehicle types, changed carrier markings, different identifier formats, or a camera that has shifted position. It requires closed-loop monitoring to detect, because the system does not otherwise announce that it has become unreliable.
Should yard computer vision run at the edge or in the cloud? Most mature architectures are hybrid. Edge processing gives lower latency and offline resilience; cloud gives elasticity, easier upgrades and the ability to run larger models. The deciding constraint is usually available uplink bandwidth at the site, so the split should be configurable per location rather than fixed by the vendor.
Can you use ChatGPT or an LLM for yard computer vision? Not for the perception layer. Language and vision-language models are reasoning systems, whereas identifying what is in an image, where it is, and what its identifier reads are narrow perception tasks that purpose-trained models perform faster, more cheaply and more reliably. Reasoning models have a role higher in the stack, not in the real-time decision loop.
What should I ask a yard computer vision vendor? How many of your specific sites they can achieve stated accuracy at and what disqualifies the rest, how they detect model underperformance, what happens when a lens is obscured, and whether their edge-cloud split is configurable to your available connectivity.
Where to Start
If you are evaluating yard computer vision, weight the site survey more heavily than the accuracy claim. The models will be comparable. The deployment engineering will not.
Terminal's Yard Operating System runs computer vision across gate and yard operations as part of one platform. Explore the platform and walk through gate automation yourself with no sales call.
This article draws on Lights-Out Yard Episode 4, "Lights-Out, Cameras, Action!" with Chris Duncan, VP of Engineering at Terminal Industries.
