The model is rarely the problem. Decisions made about capture, lighting, labeling and acceptance criteria determine whether an inspection system can succeed long before anyone opens a training script.
Automated visual inspection has a reputation for being harder than it looks. Demonstrations work beautifully; production deployments stall. In our experience the cause is almost never the neural network. It is a set of decisions, or non-decisions, that happen upstream of training and quietly make the problem unsolvable. Here are the ones that matter most.
The defect was never defined
Ask three quality inspectors to mark the same batch of parts and you will often get three different answers at the margin. A scratch that one inspector rejects, another accepts because it is outside the visible face. If humans disagree, a model trained on their labels will learn the disagreement. Before any data is collected, defect categories need written definitions, example images for each, and an explicit boundary between acceptable and rejectable. This document is the real specification of the system.
Capture was treated as an afterthought
A detector cannot find what the camera cannot see. Inspection imaging is a lighting problem first and a modeling problem second. Low-contrast surface defects on glossy or metallic parts need controlled, often angled or diffuse lighting to become visible at all. Motion blur from a fast conveyor needs short exposures and sufficient light. Ambient daylight varying across a shift introduces drift that no amount of augmentation fully removes.
- Fix the geometry: camera distance, angle and field of view should be stable and repeatable.
- Control the light: enclosed or shielded illumination removes the biggest source of variation.
- Trigger deterministically: encoder or sensor triggers put the part in the same place in every image.
- Check the image before the model: if a human cannot see the defect in the captured image, stop and fix capture.
Rare defects, abundant good parts
On a well-run line, defects are rare by design. A week of collection may produce thousands of good images and a handful of each defect type, with some types never appearing at all. Training a supervised classifier on this directly produces a model that learns to say "good" and achieves impressive accuracy while catching nothing.
There are established responses. Anomaly detection learns the appearance of good parts and flags deviations, which handles defect types never seen in training. Supervised models handle the known categories engineers want tracked by name. Deliberately produced defect samples and targeted augmentation extend coverage. The point is that the approach has to be chosen with the data distribution in mind, and that choice should be made before collection so the right samples are gathered.
Nobody agreed what good enough means
Every inspection system makes two kinds of mistake: missing a defect, and rejecting a good part. They have different costs. A missed defect that reaches a customer may be very expensive; a false reject costs a few seconds of operator review. The acceptable balance depends on the product and the process, and it should be stated as explicit targets before development so the team can tune thresholds toward a real goal. Projects without agreed targets end in open-ended arguments about whether the system is ready.
The line changed and nobody told the model
Inspection models are trained on the line as it was. New suppliers, new film, replaced lamps, worn conveyor belts and seasonal lighting all change the images. A system without monitoring will degrade silently. The design should include tracking of reject rates and confidence distributions over time, a workflow for operators to flag disagreements, and a plan for periodic retraining using those flagged examples. This is operational work, and it needs an owner on the plant side.
If the defect is not defined, the image does not show it, or nobody has agreed what success means, no model will rescue the project.
None of this is glamorous. It is also where the outcome is decided. Teams that spend their first weeks on definitions, capture and acceptance criteria tend to find that the modeling, when it finally starts, is the straightforward part.