Most inspection AI is trained to recognize defects. The trouble is that the defect which matters most is usually the one nobody has seen yet. There is a simpler way to build inspection. Train the system on good product instead, and let it flag anything that deviates from it.
Automated visual inspection is no longer novel. Most manufacturers are already exploring AI inspection of some kind, and a pilot on a single station is not hard to stand up. Far fewer have inspection running across the plant, on every variant, and still trusted by the operators two years later. The distance between those two positions is where most of the disappointment in this field sits.
When we are asked to look at a project that stalled somewhere in that gap, the cause is usually not the model. It is that the system was taught a list of faults, and sooner or later the list ran out.
01. Two ways to teach a machine what to look for
There are two ways to build an inspection model, and the choice between them decides almost everything that follows. It sets what the system costs to bring up, what it is capable of catching, and what happens the first time the line produces something nobody anticipated.
01Learn the defects
Object detection is trained on labelled examples of every fault you want to catch. It needs hundreds of images per defect class, it finds the faults on its list, and it can tell you which one it found. Anything not on the list reads as a good part.
02Learn the good part
Anomaly detection is trained on good product, with a few defects to calibrate and test. It flags whatever deviates, whether or not it has seen that fault before. What it does not do on its own is name the fault it found.
A model trained on a list of defects does not tell you when it sees something new. It tells you it saw nothing it recognized, which looks exactly like a good part.
There is a second consequence, and it is the one most often missed. A missing screw is a deviation from a good part. So is the wrong component, and so is the right one fitted in the wrong place. A system that has learned good flags all of them without ever being told to look for any of them, which means presence checking and defect checking stop being two separate jobs with two separate budgets. A labelled model needs a trained class for each of them. What it gives you in exchange is the name of the fault it found.
02. The cost everyone underestimates
Teaching a model a defect catalogue begins with collecting and labelling images of every fault on it. This is the line in the plan that gets underestimated, and it is worth being blunt about why. It is rarely the model that sinks an inspection project. It is the data the model needs before it can do anything at all, and the published implementation guidance gives a sense of the scale involved.
The awkward part of that arithmetic is that a process which runs well produces very few defects. Collecting several hundred examples of a single class therefore means waiting months for them to occur naturally, making bad parts on purpose, generating synthetic ones, or accepting a thin dataset and the accuracy that comes with it. The hardest examples to gather are the rare and intermittent faults, and those are exactly the ones that reach the customer and turn into a return or a lost qualification.
A system trained on the defects you have already collected is, by construction, best at the ones you were already catching.
The catalogue is never finished either. Each new fault means another collection campaign and another validation cycle, and a single product revision can invalidate a set of images you spent months gathering. Where variants arrive faster than campaigns can finish, inspection stays permanently behind the process it was installed to guard.
03. Train on good, calibrate with a few defects
The alternative inverts the problem. A running line produces good parts continuously, so the training material for this approach already exists and more of it is created every shift. A small number of defect examples is still needed, not as a catalogue to be memorized but as calibration. They establish how far from normal a part has to sit before the system calls it bad.
That threshold is worth setting deliberately, because it decides the scale of defect you are setting up to catch. Tighten it and escapes fall while false calls rise. Loosen it and the reverse happens. Nothing removes the tradeoff, and the consequence of getting it wrong is practical rather than theoretical. A station that over rejects rebuilds the manual inspection point it was installed to remove, and the operators quietly stop trusting it. Reducing false calls is a research subject in its own right for that reason [2], and leaving the threshold as a detail to settle after installation is an expensive habit [3]. Because the output is a distance from normal rather than a verdict against a fixed list, that dial can be set per station and moved as the process matures.
04. Camera agnostic, and one platform instead of many
How the inspection runs matters as much as what it learns. The properties below are what separate a system that works on one station from one that is still working across a plant several years later, and none of them are visible in a pilot.
The hardware stays your choice. Inspection logic should outlive any particular camera. When the software is independent of the hardware, the optics can be picked for the task, the compute sized for the throughput, and either one replaced on your own cycle rather than a vendor’s. Lighting and lens choice do more for results than most people expect, so the freedom to change them matters a great deal, and the capability is not stranded when a hardware generation is discontinued.
One platform instead of many. Being agnostic to the image type and the part means a single system covers different products, stations, and imaging modalities. The alternative accumulates quietly. Each purpose configured unit arrives with its own interface, its own update path, and operating knowledge that walks out of the building when one person leaves. A plant full of inspection systems is a plant full of things to patch and result formats to reconcile.
Capacity grows by adding nodes. Inspection volume rises with production, and new lines and use cases come online over time. The right architecture absorbs that incrementally, with each additional node taking a share of the work, so capacity grows in step with the business and every node stays simple and replaceable.
The imagery stays on site. Process images reveal yield, methods, and defect signatures, which makes them some of the more sensitive data a plant produces. Running inspection on infrastructure you control keeps all of it inside the building, and that is the argument we made at length in our paper on edge and sovereign AI.
05. Where anomaly detection wins
Anomaly detection is not the right answer for every station. It is the right answer for a recognizable set of them. If several of the following are true of a station, learning good is the right place to start.
A labelled model still wins where the fault has to be named rather than simply caught, because the class is what drives whatever happens next. A missing clip routes to one rework cell and a surface flaw to another, and fault types get attributed back to the process parameters that produced them. A gap or a tolerance is a different case again. It is deterministic, and rule based vision with proper fixturing answers it more precisely than either model would. But for inspection that has to flag when something is off no matter what that something turns out to be, anomaly detection is usually the better foundation.
06. Averian’s view
We build solutions that move the business forward, and in inspection that means being clear about what the line actually needs before anything is built. Our position is straightforward. Catching that something is wrong and naming what is wrong are two different jobs, and the second one costs far more to deliver. Most of the stalled projects we are asked to look at had paid for the second when the line only ever needed the first.
What we have learned building AI Validator is that the hard part is rarely the model. It is the data that has to exist before the model can do anything, and the fault that nobody thought to put on the list. AI Validator learns good rather than memorizing a catalogue, because that is what makes it deployable where defects are scarce, products change, and the fault that matters is the one nobody has seen yet.
Not sure which question your line is asking?
If you have an inspection problem, a stalled pilot, or a defect you keep missing, we are happy to look at it with you, from a straight assessment of which approach fits to optics, integration, and deployment.
References
- SmartDev, Computer Vision Cost in Manufacturing: Complete CV System Pricing Breakdown, 2026. https://smartdev.com/computer-vision-cost-manufacturing-complete-cv-system-pricing-breakdown/
- Surface Mounting Production Line Automatic Optical Inspection False Call Classification with Machine Learning Algorithms, Springer, 2026. https://link.springer.com/chapter/10.1007/978-3-031-74482-2_2
- Automation Magazine, When the camera gets it wrong: the cost of optical compromise in automated inspection, 2026. https://www.automationmagazine.co.uk/when-the-camera-gets-it-wrong/
This paper is intended as general perspective for enterprise leaders and technical teams. Cost and timeline ranges are drawn from third party implementation guidance and vary substantially with the inspection task, optics, and defect complexity. They are cited for context rather than as measured averages. Performance figures for Averian AI Validator reflect results measured in specific customer deployments and will vary with the inspection task, input quality, and volume. They are not a guarantee of results in any particular environment.