The demo-to-deployment gap

A robot laying film across a quarter panel makes a good video. The video is usually true. It is also, in a specific and expensive way, not evidence.

The gap between a system that works in a demonstration and one that works in a service bay is the single most underestimated distance in applied robotics. It is not a funding gap. It is an engineering problem with a particular shape, and the shape is worth describing precisely, because it determines what you should build first.

A demo optimises the wrong variable

A demonstration is built to show the best case. One vehicle, prepared. One lighting condition. One operator who knows where to stand. One pass, and if the pass goes badly you run it again before anyone films.

A working installation is judged on the worst case it will meet this week. Those are different engineering targets, and a system tuned for the first can be structurally unable to reach the second. You do not get from one to the other by iterating. You get there by designing for variance from the beginning, which usually means building something narrower than the demo implied.

Three things that break

Variance in the workpiece

Two vehicles of the same model and year are not identical by the time they reach a bay. Panel gaps differ. One has had a repair with filler that changed a contour by a millimetre. Another carries aftermarket trim, a different mirror housing, a dealer-installed accessory nobody recorded. Surfaces arrive with contamination that is invisible until material is applied.

A person compensates for all of this continuously and does not notice doing it. They feel resistance and adjust pressure. They see a reflection break and change angle. None of that compensation is written down anywhere, which means none of it exists in your system until you put it there explicitly.

Tolerance stacking

Every subsystem is accurate enough on its own. The vision estimate is good to a millimetre. The arm repeats to a fraction of that. The fixture holds to a known tolerance. The material behaves predictably under tension within a temperature band.

Stack them and the errors compose. The result can exceed the tolerance the finished job is actually judged by — which, for surface work, is a human eye looking down a panel in daylight. Demos conceal this because a demo is one pass under one condition, and tolerance stacking is a distribution problem. You cannot see a distribution in a single sample.

The cost of being wrong

In a warehouse, a failed pick drops a box and the system retries. On a customer vehicle, a failure consumes material, time, and sometimes the surface underneath. The asymmetry is severe, and it changes the engineering: you are not designing for average performance, you are designing for the tail. A system that is excellent on average and occasionally catastrophic is worth less than one that is merely good and never catastrophic.

This is also where most of the real cost sits. Handling the common case is a prototype. Handling the uncommon case is the product.

Why more money does not fix it

Capital buys iterations, hardware and people. It does not change the shape of the problem, and it cannot substitute for contact with the actual variance. You only learn the distribution by running against real work, in the condition the work arrives in, for long enough to see the tail.

That is why the useful early question is not how capable the system can be. It is how narrow you are willing to make it.

What actually closes the gap

• Pick a sub-task, not a job. A job is a sequence of operations with different failure modes. One operation, done reliably, is a product. A whole job, done unreliably, is a liability.
• Constrain what you are allowed to constrain. Fixturing, intake condition, lighting and surface preparation are inputs you control. Every constraint you impose removes variance you would otherwise have to model.
• Instrument for the tail. Average cycle time tells you very little. The distribution of outcomes, and specifically the worst decile, tells you whether you have a business.
• Keep a person at the point of highest variance. Not as a failure of automation — as a design decision. The human handles the long tail while the system handles the volume, and the boundary moves as the data improves.
• Widen only when the tail is boring. If the worst case still surprises you, scope is not ready to grow.

The first robots to earn their keep in a service bay will do one narrow thing extremely reliably and hand everything else back. That is not a compromise. It is the only version that ships.

The part that is genuinely hard

None of the above is about making a robot move well. Motion is largely a solved problem and improving quickly. The hard part is building a system that knows what it is looking at, knows when it is uncertain, and does something safe when it is.

Perception under real variance, and honest uncertainty estimation, are where the remaining work is. Everything else is integration — demanding, unglamorous integration, but integration.

That is the gap. It closes by narrowing scope until the variance is bounded, proving the tail is dull, and only then widening. It does not close by making the demo more impressive.