Automated inspection fails on rare defects and false rejects, not on model choice. Here is how we scope, light, and price a real inspection station.

The hardest problem in automated visual inspection is not the model. It is that you do not have enough defects.
A line running at 2% scrap produces 98 good parts for every bad one, and the bad ones are bad in different ways. You want to detect cracks, and you have eleven examples of cracks, four of which were photographed under a light that no longer exists because maintenance replaced the fixture in March. This is the actual starting position on most inspection projects, and it shapes every decision that follows.
More inspection projects are rescued by a $200 light than by a better architecture. This is not a joke and it is the single most useful thing we can tell you.
Consistent, controlled illumination turns a hard vision problem into an easy one. Backlighting makes edges and holes trivial to measure. Diffuse dome lighting removes the specular glare that makes a polished surface unreadable. Low-angle grazing light makes a surface scratch that is invisible under flat light jump out. Choosing the right one is a physical experiment that takes an afternoon and saves weeks.
The same goes for the mechanics. Fix the camera rigidly. Fixture the part so it presents the same face in roughly the same position each time. Shield the station from changing ambient light. Every degree of freedom you remove from the physical setup is variance the model no longer has to learn to ignore, and it is far cheaper to remove it with a bracket than with training data.
We treat the rig as part of the deliverable, not as site prep somebody else handles.
With eleven crack examples you cannot train a crack classifier and you should not try. Two approaches work better.
Anomaly detection learns what normal looks like, which you have tens of thousands of examples of, and flags departures from it. It does not tell you the defect is a crack. It tells you this part does not look like the others, which is often all the line needs in order to divert it. This is the right default when defects are rare and varied.
Targeted supervised detection earns its place once a specific defect is both common enough to collect and important enough to name. Most projects end up with anomaly detection as the net and one or two supervised detectors for the failures that actually recur.
Either way, start collecting and archiving defect images now, before the project starts, with the part and the shift logged. The single most valuable asset on an inspection project is a well-organised library of real defects, and it can only be accumulated over time. Teams that begin collecting on day one of the build have already lost the months they could have had.

Everyone scopes an inspection system around catching defects. What determines whether the operators keep it switched on is how often it stops a good part.
A system that catches 99% of defects and falsely rejects 5% of production is, on a line running 10,000 units a day, throwing 500 good parts into a review bin daily. Within two weeks somebody will find the override, and after that you have an expensive camera and a process that is not actually inspected.
Set the acceptable false reject rate with the plant manager before you tune anything, and report it as prominently as the catch rate. On safety-critical work the answer may genuinely be that a high false reject rate is acceptable, because a missed defect is catastrophic. On cosmetic sorting it almost never is. This is the precision and recall trade in its most concrete form, and getting it wrong is how inspection systems get quietly abandoned rather than loudly rejected.
A line moving at 60 parts a minute gives you one second per part, including capture, inference, decision, and the signal to the reject mechanism. That budget rules out a large class of models regardless of how accurate they are.
Decide the cycle time first and let it constrain the model, rather than picking a model and discovering later that it cannot keep up. In practice this pushes work to the edge: inference on a small industrial PC or a camera with an onboard accelerator, close to the line, not a round trip to a cloud region. Latency is one reason. The other is that a plant network having a bad afternoon should not stop production, and a cloud dependency in a control path eventually will.
An inspection system that displays results on a screen is a demo. One that pushes a reject signal to the PLC, logs the result against the part serial, and surfaces trends to quality engineering is a system.
That integration is usually where the schedule goes. Plant systems are older and less documented than the vision work, the people who understand them are busy, and the change window is a weekend six weeks out. We plan the integration as its own workstream from the start, because treating it as the last two days of the project is the most reliable way to miss a go-live.
Log every decision with the image that produced it. When quality disputes a call two months later, and they will, the argument ends in thirty seconds if you can show the frame.
A single inspection station checking one defect class on one part family sits at $4,000 to $10,000 across three to four weeks, assuming the lighting and mounting are workable. A full station with anomaly detection, PLC integration, logging, and a quality dashboard runs $10,000 to $22,000 across five to seven weeks. A multi-station or multi-site rollout runs $22,000 to $30,000 and up, phased across eight to twelve weeks, and should be phased because the second station always teaches you something the first one did not.
Those are our standard fixed-price bands. Running cost is small, typically $50 to $2,000 a month, and much of an edge deployment's compute is a one-off hardware line rather than a recurring one.
If the defect is not reliably visible to a human looking at a photograph of the part, a camera will not find it either. Sub-surface flaws, internal voids, and material composition problems need a different sensor, not a better model. If the part presentation cannot be controlled, meaning parts arrive in a heap at random orientations, the honest answer is fix the handling first.
And if the line's scrap rate is already low and the cost of a missed defect is modest, the arithmetic may simply not work. We have told plants that. It is a short conversation and it saves everyone a quarter.
Fewer than you would think if you use anomaly detection, which learns from good parts and needs only a handful of defects to validate against. A few dozen real defect images is enough to measure honestly. For a supervised detector aimed at one named defect, plan on a few hundred examples of that specific defect, which is why anomaly detection is usually the right starting point.
Yes, and on a production line it generally should. We deploy inference on local hardware at the station so that inspection continues through a network outage. Results sync when the connection returns.
By making the false reject rate low enough that overriding is not rational, and by giving operators a fast way to flag a disagreement that feeds back into the evaluation set. A system people can argue with, and win against occasionally, gets trusted. One that cannot be questioned gets bypassed.
It needs re-evaluation, and often re-baselining rather than full retraining. A new supplier's surface finish shifts what normal looks like, which anomaly detection notices immediately as a rise in flagged parts. That is the monitoring working, not failing, and it usually means adding the new normal to the reference set.
Written by the Codestreaks team. The price bands and running cost figures are our own published fixed-price tiers, from 30+ projects delivered to production since 2024. The lighting-before-model argument, the false-reject failure mode, and the log-the-frame practice come from vision and automation work on real production environments, retold without naming clients. We are an agency that has advised plants against building this, which is worth weighing accordingly. Drafting is AI-assisted with a human editing pass over our own project record.
If you can send photographs of a good part and whatever defect examples you have, even bad phone pictures, that is enough to tell you whether this is a lighting problem, an anomaly detection problem, or not a camera problem at all. Free 30 minutes, reply within two business days.
More on how we build these on our computer vision development service page, or start a project.
Related reading: why your demo's accuracy is not your accuracy, what the shop floor does to your assumptions, and where supply chain automation pays off.