A visual quality management system that learns from every flagged part

At 3 am on line 2 a stamped panel comes off the press with a scratch running diagonally across the face. The camera over the outfeed boxes it, and within a few seconds the shift lead's phone shows the frame with the scratch drawn on it, the line, and the batch number the panel belongs to. The lead walks over, pulls the panel, and finds the same scratch on the next four. A roller on the transfer has picked up a burr.

The detector did its part in the first second. Everything that made the 3 am scratch worth catching happened after it.

The alert carries the frame, the line and the batch

The alert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a scratch on any panel on line 2, high, one alert per line every fifteen minutes. What arrives is the frame with the defect boxed, which line, and which batch, and that is enough for the shift lead to act without opening anything else. The alert written as a sentence is the same rule the plant uses for every other camera, with the class and the line swapped.

The cooldown matters more on a quality line than almost anywhere. A burr on a roller scratches every panel, and without a cooldown the lead's phone shows the same scratch four hundred times before the end of the shift. With it, the first alert is the page and the rest are a count in the morning digest.

The night shift calls the roller scratch the comet, because of its tail.

Every flagged frame is a record tied to the line and the batch

The frame does not disappear after the alert. It is stored with the line, the batch, the shift and the time, and that record is what the plant reaches for when a customer returns a panel in March and wants to know what else was in that batch. Without it, the answer is a search through a shift log. With it, the answer is every flagged frame from that batch, with the boxes.

That record is also what LexInsight answers questions from. "How many scratches on line 2 this week, by shift" comes back with the count and the frames. The night shift's number is higher than the day shift's, which is a conversation about the roller and about who changes it, and not about the model.

My own view is that an alert channel is never the quality record. The channel is for the person on shift. The record is the log, and a plant that has to scroll a chat history to answer an auditor has the two confused.

Recall comes first, and the alert layer absorbs the false alarms

On a quality line the two mistakes are unequal. A scratch that ships to a customer costs a return and possibly a recall. A clean panel flagged as scratched on line 2 costs a quality engineer a glance and a dismissal. So the threshold is set to catch, and the false alarms that come with catching are handled in the alert layer rather than tuned out of the model.

That means the cooldown, the digest, and a review queue where a dismissed alert is a labeled frame. A plant that tries to reach zero false alarms by raising the threshold reaches it by missing scratches, and finds out from the customer.

The flagged frame is reviewed, corrected, and trains the next version

The quality engineer on days opens the night's flagged frames with a coffee. Most are scratches. A few are oil residue that caught the light, and one is a reflection off the press guard. Each gets a verdict, and each verdict is a label: the scratch confirmed, the oil marked as no defect, the reflection marked as no defect. Those corrections are the next version's training frames.

LexData takes the line 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 outfeed camera the plant already has, in the cloud, on your 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. Across the manufacturing lines we run that is 99%+ accuracy maintained in production, and the maintaining is the engineer with the coffee.

The correction rate is also the plant's early warning. When the engineer is overriding more frames than last month, something on the line has changed, and the batch numbers on the overridden frames will usually say what.

Most computer vision projects stop at the model, and that is where they fail

A detector that works on a validation set in June is a demonstration. It becomes a quality system when the alert reaches a person who can pull a panel, when the frame is a record with a batch number, when the dismissed alerts train the next version, and when someone owns the threshold. Most computer vision projects in plants end at the demonstration, sometimes for a year, and the quality costs they were meant to reduce do not move, because nobody on the floor was ever wired into the result.

The plant that treats the model as one component in a system it already runs, with the same discipline it applies to a gauge calibration, is the plant whose scratch rate actually falls.

A change in the defect rate is a threshold problem before it is a model problem

Six months in, the alert count on line 2 doubles in a week. The first reaction is that the model has broken. It has not: each flagged panel really is scratched. A new coil supplier's steel is marking more easily, and the thresholds and cooldowns tuned around the old rate are now wrong for the new one.

The drift catalog calls this the defect rate changed: per-detection accuracy holds while the counts swing. The cheapest place to see it is alert volume on line 2 against its own history, week by week, and the fix is a conversation with purchasing before it is a retrain. When the plant adds line 5 with a different press and a different camera, the same discipline applies in reverse: its own labeled window, its own thresholds, and its own history to compare against, because a fleet average would let line 2 hide it.