Scaling a computer vision operating model from one camera on one line to twenty across five plants

The pilot worked. One camera over the outfeed of line 2 at the Leeds plant catches the scratches, the shift lead gets the frame, and the scrap rate on that line is down enough that the plant manager mentions it in the monthly. The request from the other four plants arrives the following week. The engineer who built the pilot is the only person who knows why the threshold is where it is, why the camera sits at that height, and what happens when the belt speed changes.

Twenty cameras across five plants is not twenty copies of the pilot. It is a programme, and a programme needs three things the pilot never did.

One metric, reported monthly, that nobody can hide behind

The first decision is a number that stands for the whole programme, reported every month by one person. The one that works is the time from a plant asking for a camera to that camera producing something a shift lead acts on. Median, in days, across every request in the programme.

There is a temptation to report three numbers, accuracy and latency and cost, and it should be resisted. With three numbers a team reports whichever looks best that month. With one, the conversation is about why the Manchester request took twice as long as the Leeds one, and that conversation is where the programme learns. Cost per deployment is the other candidate, and it is a fine second metric to track quietly, but only one goes in the monthly.

The first month's number is the baseline. Nobody should try to make it look good.

The pilot's decisions have to be written down before anyone copies it

The Leeds engineer's head holds the threshold, the camera height, the cooldown on the scratch alert, the reason the label guide says a scuff under a certain length is not a scratch, and the belt speed at which the tracks start breaking. None of it is written anywhere, and the second plant will make every one of those decisions again, differently.

So the pilot ends with a document. What the classes are and what the label guide says about the edges. Where the camera sits and why. What the rule sentence is, with its severity and cooldown. What the threshold was set to and what the plant saw at the settings either side of it. Who reviews the doubted frames and how long they take. It is a boring document and it is the most valuable artifact the pilot produced, because it is the template the next nineteen cameras start from.

Vision AI across five plants is a rollout, and every plant is a new site

The mistake that stalls most programmes is copying the Leeds model to Manchester. Manchester's line has a different press, a camera mounted a foot higher, warmer lights and a different coil supplier, and the Leeds model finds half the scratches on its first day. The plant concludes the model is bad. It is doing exactly what a model trained on one site does at another.

The drift catalog calls this a new site came online: the same task and the same definitions on a different input, arriving all at once. The tell is that the new plant's detection profile is different from day one rather than degrading into it. The fix is the one the catalog names: a labeled window of frames from Manchester's own camera, folded in before Manchester goes live. Each plant is then compared against its own history rather than a programme average, because the good plants carry the bad one.

Vision AI at programme scale is that step repeated with discipline: a window per site, a review per site, and a rollout per site, on the same template.

The loop runs the same at plant five as it did at plant one

What does not change between plants is the mechanism. LexData takes each plant's model through its whole life. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the cameras the plant already has, in the cloud, on the plant's servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime.

The platform is the same at every site, which is the point. What the programme adds is who reviews Manchester's doubted frames, how their verdicts are compared with Leeds's, and what the correction rate per plant looks like on one chart. A plant whose rate is climbing while the others hold is the plant whose world changed, and the programme lead sees it before the plant does.

The easy use case goes first so the process fails where it is cheap

Five plants have more than one thing they want watched. Scratches on the outfeed, people inside a robot zone, pallets on a dock, a label check at the packer. The programme tiers them: the easy one, with clean visuals and a clear pass or fail, goes first at every plant. The hard one, a subtle defect in a patterned surface, stays visible in the backlog and is not started until the easy one has run through the whole template at Leeds, Manchester and one more.

My own view is that the order matters more than the choice. The first use case is the one that finds out whether the request process works, whether the label guide is readable by someone who did not write it, and whether the review queue gets emptied. Those failures should happen on a scratch detector and not on the robot zone.

Two roles exist before the second camera goes in

The pilot had an engineer. The programme has a sponsor with a budget and the ability to remove a blocker at another plant, and a working group that meets every fortnight and owns the number. The group is small: the engineer who built the pilot, a lead from each plant that is live or next, and whoever answers for the review queues.

The sponsor does not need to understand the model. The sponsor needs to care about the number, and to be the person the Manchester plant manager cannot say no to when the labeled window is asked for. The programme at Leeds started with a camera. The programme across five plants starts with a calendar invite that recurs.