Visual inspection is where AI meets physical reality, and physical reality wins every argument. These are the scoping lessons that decide these projects — mostly settled before any model is chosen.
1. The camera and lighting matter more than the model
A mediocre model on a well-lit, well-positioned, vibration-controlled image stream beats a state-of-the-art model on a bad one — every time, by a wide margin. Optics, lens choice, exposure control, and lighting geometry are engineering decisions, not procurement details. When a vision project underperforms, we look at the images before we look at the network.
2. Write down the defect taxonomy before collecting data
"Detect defects" hides a dozen decisions. Which defect types? At what minimum size? Do two adjacent scratches count as one defect or two? Does surface texture variation count at all? Every ambiguity you leave open becomes an inconsistent label, and inconsistent labels become a ceiling on accuracy that no model can break through. An afternoon with your quality engineers, writing the taxonomy down with example images, is the highest-leverage afternoon in the project.
3. The rare defects run the project
The defects that matter most are usually the ones you have the fewest examples of. This asymmetry shapes everything: how long data collection takes, whether synthetic augmentation genuinely helps or just inflates metrics, and how you evaluate a model on twelve real examples of the critical failure. Any proposal that does not address the rare-defect problem explicitly has not engaged with your actual line.
4. Agree the operating point before training
Every detector trades false alarms against misses; the dial has to be set somewhere, and where it sits is a business decision, not a technical one. How many false alarms per shift will operators tolerate before they stop trusting the system? What miss rate can quality accept? Fix those two numbers with the people who own them, and development becomes an engineering problem with a defined target instead of a negotiation after the fact.
5. Operators decide whether it survives
A system operators distrust gets bypassed within a month, whatever its metrics say. Trust is built with mundane features: showing why something was flagged, a fast way to correct mistakes (which doubles as training data), statistics they can check against their own experience, and a manual override that is respected. We design the operator's screen with the same care as the model — the model is only as good as the human's willingness to act on it.
6. Plan for the edge, literally
Production lines rarely tolerate round-trips to a cloud API — latency, connectivity, and data policies all push inference onto hardware at the line. GPU-on-the-edge deployment, calibration workflows, and PLC integration deserve a line in the plan from day one; retrofitting them later costs more than designing for them early.