Skip to content
LexDataLexData
PlatformIndustriesCustomers
DocsThe Field GuideBlogWhy models drift
AboutCareersSecurityContact
Log inStart now
← All posts

Operations · 6 min read

Deploying a computer vision model to a second plant, beyond the weights file

What the second plant needs beyond a weights file: recorded thresholds and the test set behind them, the alert template, acceptance criteria, its own frames.

Summary

This post lists what travels with a surface defect model when it moves from the first plant to the second, from thresholds with the test set behind them and the alert sentences to acceptance criteria and the new line's own frames. It concludes that a weights file alone stalls the second plant, and that the package gets better with every plant whose frames flow back into it. It is for engineering leads rolling one model across several sites.

Andreas Ohrvall · CTO · Sep 23, 2026

Edge box beside the recorder in a plant cabinet, generated scene with detections from our model

The surface defect model worked at the first plant. It ran on line 2 for a quarter, the line lead trusted it, and the plant manager asked for it at the second plant. So the weights file went across in a Friday email, an engineer spent a week getting it to run on the box beside the recorder, and three weeks later the second plant's line lead had quietly gone back to the inspector.

Nothing was wrong with the model.

Everything was wrong with what was shipped. A weights file carries what the model learned. It does not carry the thresholds it was tuned at, the frames it was measured on, the rule that paged the first plant's lead, or any definition of what it means for the second plant to be done.

A weights file carries what the model learned and nothing else

Start with what the first plant actually had. A model, and also a threshold per class that somebody tuned against line 2's own base rate. A test set of frames from that line, held out by time, that the accuracy figure was measured on. An alert rule that said which defects were critical and who they went to. An adapter that turned the alert into a tag for the line's controller. A month of corrections from the review queue that the second version had been trained on.

The second plant received the first item on that list. Each of the others is something the engineer at the new site had to rediscover, guess, or skip, and skipping is what happened to most of them.

The Friday email had a subject line that said "model" and no body at all. Most engineers have received one like it, and most have sent one.

Precision and recall travel with the test set they were measured on

An accuracy figure without its conditions is a rumour. What travels with the model is precision and recall per class, at the operating threshold, on a named test set. Beside it goes a sentence about where that set came from: which line, which camera, which months, whether the March frames after the lighting change were in it. The set is held out by time and by camera rather than as a random slice, because a random split leaks frames from the same hour onto both sides and reports memorisation as accuracy.

Written down this way, the figure becomes something the second plant can check. If the new line's held-out frames score lower, that is a finding about the new line. The whole method is in retraining without starting over, and the part that matters here is the bookkeeping: every version names the exact dataset that trained it, so a plant running version four can say what version four saw.

The alert sentences and the webhook template are part of the deliverable

At the first plant, the alert was a rule written as a sentence with a severity and a cooldown. A crack on the post-stamping camera is critical and goes to the line lead in Slack with the frame attached; a scuff is routine and goes to the shift channel. That sentence is the operating knowledge of the deployment. It says what the plant cared about and who acted on it.

So the sentences travel. So does where they land, and the webhook template that turned them into a tag for the controller and a record for the execution system. The second plant edits names and channels; it does not rediscover which defects are worth waking someone for.

Acceptance criteria are written for the local line

The most useful page in the package is a definition of done that the second plant can test, and it is usually the page that gets written last, if at all. Three parts. A window of the new line's own frames, labeled and checked, that the model must score against before anyone signs. An integration check: the tag reaches the controller, the record reaches the execution system, the alert reaches the person. And the operator's word: the line lead who will live with it says it fits the shift.

The first of those is the one that gets skipped, and it is the reason the second plant stalled. The drift catalog calls it a new site coming online: same task, same definitions, a different line, and the model does exactly what a model trained on one site does. A fleet average hides it, because the plant that works carries the plant that does not. The 99%+ accuracy maintained in production that our manufacturing work holds is a per-line figure, checked per line, and that is the only kind worth writing into an acceptance sheet.

The new line's frames go in before sign-off

The fix for a new site is a window of the new line's frames, a week of shifts is usually enough to start, labeled, added to the set line 2's version was trained on, and a retrain on both. Keep the old frames; a model trained only on the new line swaps which line it fails on. A model that has seen two lines transfers to the third far better than one that has seen a single line very thoroughly, which is why the package gets better with every plant it visits, provided each plant's frames flow back into it.

That flow is the thing to protect. Local teams adjust thresholds and add classes, and if those changes stay local, the package on the shelf stops matching the thing deployed. The corrections and the new frames belong to the shared version.

The third plant is the test of the package

LexData takes the defect 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, on a runner beside the recorder so the footage stays on site, or on your servers. 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. Versions keep what they were trained on, so the second plant's version can name the first plant's frames and its own.

The measure of the package is whether the third plant passes acceptance on the first attempt. If it does, the thresholds, the test set, the alert sentences and the acceptance sheet were right. If it does not, the gap is in the package, and the fix goes into the package rather than into a one-off at the site. The platform is where those pieces live together, which is what makes the third plant a copy rather than a project.

See it on your own footage.

Start with your footage

More in Operations

Operations · 6 min read

Turning a detection into an OPC UA tag the PLC can read

A count, a presence flag and a confidence value as OPC UA variables, written on change from the alert webhook, while the reject decision stays with the PLC.

Stephen Biswas · Sep 23, 2026

Operations · 7 min read

Integrating machine vision with PLC, SCADA, MES and ERP systems

A cracked weld is a bit for the PLC, a thumbnail for the HMI, a record for the MES and a yield figure for the ERP. Shape it once, beside the recorder.

Andreas Ohrvall · Sep 23, 2026

Operations · 7 min read

Getting a defect detection to the PLC over MQTT

One webhook from the alert into the plant's broker, a topic per line and camera, and the PLC and the SCADA screen subscribe like any other client.

Andreas Ohrvall · Sep 23, 2026

LexData
LexData

Product

  • Platform
  • Industries
  • Use cases

Resources

  • Docs
  • The Field Guide
  • Blog
  • Why models drift

Industries

  • Energy & utilities
  • Oil & gas
  • Agriculture
  • Manufacturing
  • Insurance
  • Retail
  • Robotics

Company

  • About
  • Customers
  • Careers
  • Contact

Trust

  • Security
  • Privacy
  • Terms

Stay updated

What we learn running vision models in production.

See everything.
Miss nothing.

Stay updated

What we learn running vision models in production.

Terms of use & Privacy policy

© 2026 LexData Labs · All rights reserved