AI quality control: where manual component inspection breaks down
Visual inspection of components is an operation where the cost of an error is disproportionate to how inconspicuous it is. A small crack at the edge of a blade or galling in the mating zone is not visible in the overall view and does not show up during assembly.
The part moves further along the route, and the defect is found during testing or, worse, in service. An inspector reviews thousands of similar surfaces per shift, and on a monotonous sample, attention is the first to drop.
Operator fatigue is not a metaphor but measurable degradation: by the end of a shift, the share of missed defects increases severalfold, although formally the person works according to the same instructions.
A separate problem is the spread in acceptance criteria between shifts and operators: one considers a borderline overexposed area on the edge acceptable, while another sends the part to quarantine.
Both extremes are costly: a missed defect becomes a risk, while false rejection leads to rework and extra load on the area.
Semi-automatic inspection stations cover part of the task but inherit the main weakness: the threshold is set by a person. A rigid threshold either rejects good parts or fails to notice low contrast, and a change in lighting or angle changes the verdict on the same part.
AI quality control works from a reference representation of the part class: a defect is evaluated by shape, extent, and contrast relative to the local background, rather than by a single brightness boundary.
Below we break down how this is addressed: where inspection is placed in the route, how a sample of real defects is collected, and how the solution is integrated into the current acceptance procedure.
What deployment in the production area delivers: effects in measurable terms
We evaluate implementation by four quantities that the area sees directly: share of missed defects, batch re-inspection, batch review time, and the class of failures related to human factors.
Share of missed defects
We train the model on labeled frames from real batches, including defects that previously went into shipment. Acceptance criteria are set by thresholds for each defect class, not by a single tolerance, so borderline cases do not shift toward acceptance.
Every decision is stored together with the frame and capture parameters — it can be rechecked according to traceability requirements AS9100.
Batch re-inspection
A second pass is needed where the inspector is not confident in the verdict. The system outputs not only “pass/fail” but also a probability with the source zone of the defect — only genuinely disputed frames go to re-inspection.
Batch re-inspection stops being exhaustive: individual cases are reviewed, not the entire run again.
Batch review time and time to acceptance decision
Manual review and paperwork were a bottleneck: the batch waited for an available inspector. Now the system marks defects and groups them by type and zone, while a person confirms or rejects them.
Batch review time is reduced, and the time to an acceptance decision no longer depends on shift workload — the verdict on the frames is ready by the end of the run.
Elimination of the failure class caused by human factors
End-of-shift fatigue and differing interpretations of the “pass” boundary created an entire class of failures. Threshold criteria are fixed in the configuration and are the same across all areas, so a new operator arrives at the same decisions as an experienced one.
The stability of criteria between shifts is confirmed by comparison on a control sample: the discrepancy is measured, not debated.
Quality control modes: comparison of implementation options
The inspection mode is chosen not by model but by where a defect is cheapest to catch and how much time is available per part.
In production areas, two or three modes are more often combined: incoming inspection sets the reference, in-line inspection cuts off defects in the flow, and operator assistance covers rare and disputed cases.
Below are four basic options and their limitations. The chosen mode determines lighting and camera angle requirements, the amount of reference defect labeling, and how the system reports a nonconforming part.
| Option | When it fits | Limitations |
|---|---|---|
| Stationary inspection station | The part can be removed from the flow and fed to a position with stable light and a fixed angle | Takes up floor space and an operator, the part waits in queue; with a large flow it becomes a bottleneck |
| In-line inspection | Parts move in sequence and are not removed from the conveyor, every unit needs inspection | Strict requirements for vibration, lighting, and time per frame; harder to reconfigure for new part types |
| Operator assistance | Complex defects where the decision remains with a person and the system only highlights the zone | The outcome depends on shift qualification; human-factor influence is not fully eliminated |
| Batch sampling inspection | Mass batches of similar components, a single defect is not critical | A defect between samples moves further down the processing route; batch acceptability is assessed statistically |
The limitations of the mode also determine the scope of work: a stationary station requires stable fixturing, an in-line system requires synchronization with equipment, and sampling inspection requires correct batch statistics.
An error in selection shows up not at acceptance but in operation, when changing the mode is more expensive than designing it before launch.
How implementation proceeds: stages of engineering work
Implementation starts from the production area, not from the algorithm: until real defects are described and capture conditions are fixed, inspection produces different results from shift to shift.
The workflow below is common for the process engineer, inspectors, and engineers who assemble the quality control system.
-
Production area survey and defect statistics. We look at how parts are fed to inspection, where defects are caught now, and how often they occur. The result is an area map and a list of defects by frequency.
-
Agreement on defect classes. Together with the process engineer, we fix the boundaries: what we consider a scratch, what galling, and what an acceptable machining mark. Disputed samples are reviewed separately so that people and the system share one boundary.
-
Layout and lighting scheme. We determine the sensor position relative to the part, the type of illumination, and the fixturing method. The scheme must be reproducible in any shift; otherwise the result fluctuates.
-
Sample labeling. We mark defects on the accumulated sample, including borderline and rare cases. The work proceeds in parallel with tuning — each new batch clarifies where the system is wrong.
-
Inspection setup. We assemble the rejection logic, sensitivity thresholds, and rules for disputed zones. Overdoing it is not an option: too strict inspection produces a stream of false positives and the area stops trusting it.
-
Acceptance run on real batches. We run the system on parts that the area has already evaluated manually and compare by each defect class, not by an average figure.
-
Handover to the shift. We train inspectors, fix the procedure for disputed cases, and the order for updating the system when the part or process changes.
What remains with the customer: documentation, settings, procedures
We do not hand over a “black box”: along with the working system, the customer receives a package that allows it to be operated, expanded, and accepted without our involvement. Below is exactly what remains in your team’s hands.
- Inspection settings package — sensitivity thresholds, regions of interest, and rejection rules for each component type. They are edited from the interface, without rebuilding the model or stopping the line.
- Defect class map with reference samples — for each class: feature description, “pass / disputed / reject” boundaries, and a set of references captured on your equipment.
- Layout and lighting schemes — working distances, angles, requirements for background and illumination. From them, the position can be deployed on a second line without calibration from scratch.
- Procedure for operator actions in a disputed case — what to do with a borderline frame: confirm it, send it for retraining, or return it for repeat inspection. It removes improvisation on the shift.
- Retraining instructions — the order for adding new references, labeling requirements, and validation rules so quality does not drop after an update.
- Acceptance protocol — an agreed set of metrics and a test sample set by which the result is recorded.
- Version and calibration log — which version of settings and model was used during a specific shift.
We agree on acceptance metrics before work starts — then acceptance becomes a comparison against a pre-collected sample set, rather than a negotiation about whether the system catches a defect “well enough.”
Case study: blade inspection before and after implementation
In the blade area, inspection was visual: the operator compared the edge with a reference template and filled out a paper protocol. A batch took more than a shift, and the verdict depended on lighting and fatigue — the share of missed defects held at about 3%.
The implementation of AI inspection began with one line and three defect types; requirements for recording decisions led to AS9100.
| Metric | Before | After |
|---|---|---|
| Share of missed defects | 3.1% | 0.4% |
| Batch review per shift | 4 h 20 min | 1 h 10 min |
| Disputed decisions per batch | 9 | 2 |
| Spread between shifts | 2.5× | 1.2× |
Two borderline cases defined the labeling rules.
The model placed a hairline crack on the edge into the gray confidence zone — now such frames always go to an engineer and enter retraining marked “borderline.” A glare on the polished surface was read as a crack: uniform light and a second camera angle helped.
Before full launch, we ran the archive of past batches and compared the model’s decisions with inspectors’ verdicts — discrepancies were reviewed one by one, so shift-to-shift statistics leveled out.
We update the model on a schedule with a mandatory regression run: if the miss rate grows, rolling back to the previous version takes hours, not shifts.
How does rule-based inspection differ from training on defect samples?
Rule-based inspection is measurable geometry and thresholds: comparison with a reference model, tolerances for dimensions, area, and defect contrast relative to the background.
Such inspection is deterministic: every decision has a reason, it can be rechecked manually and accepted by the customer. At the start, while there is no accumulated statistics, this is the only way to launch the line without a long data collection phase.
Training on defect samples takes a different approach — it describes what cannot be formulated by rules: texture character, low-contrast spots, and traces of fatigue changes on the edge.
But its quality directly depends on the size and balance of the sample: rare defect classes take a long time to accumulate, and some are not represented at all.
This leads to different causes of false positives. With rules, lighting drift, glare, and dirty optics shift the measurement across the threshold, and a threshold close to the tolerance boundary starts catching good parts as defects.
With a model, it is a shift relative to the training sample: a change of material supplier, alloy batch, or processing mode changes the surface appearance, and confidence drops on the wrong class.
Resistance to material changes is also different. Rules are reconfigured — tolerances and thresholds are revised.
The model is retrained on new samples, and a process is needed here: labeled frames enter the set, metrics for each class are recalculated, and the release of a new version is decided by them, not by overall accuracy.
In practice, the approaches are not opposed — combining them gives the best result. Rules hold hard gates on dimensions and position and provide initial labeling; the model covers the remaining defect classes.
Every decision carries the feature by which it was made, and disputed cases go to operator re-inspection and return to the retraining set.
Common technical doubts before line launch
Five questions a process engineer asks before starting the line: about data, thresholds, and responsibility for setup. We answer directly, without vague wording.
How many defect samples are needed for training?
The guideline is not the number of parts but the diversity of defect classes: for galling, porosity, lack of fusion, and geometric deviation, confirmed examples are needed, usually dozens per type.
We collect more acceptable samples — they define the boundary of the norm, not just the appearance of defects.
What to do if the system rejects a good part?
A disputed part does not automatically go to scrap; it enters the re-inspection zone — with the frame and the model’s confidence level.
We shift the threshold according to the cost of the error: missing a defect and false rejection have different costs, and reviewing the disputed sample refines the boundary.
How will the system behave on a new material batch?
A change of supplier, raw material batch, or processing mode changes the surface appearance, and accuracy drops. We track drift: the feature distribution of the new batch is compared with the training one, and a discrepancy gives a signal. Retraining on its labeled samples restores the metrics.
Can it be launched on one operation first?
Yes, we start with one operation — incoming inspection or final visual inspection. The line does not stop, and we get data from the real flow. We connect neighboring operations one at a time, transferring the already configured rules.
Who configures the thresholds after handover?
Thresholds remain the process engineer’s domain: they are changed without rebuilding the model, with a change log and configuration versions. Initial calibration is supported by our engineers, and they hand over the procedure; after that, edits are made on the customer side.
Let’s discuss your task: what to prepare for the conversation
A conversation about a quality control system moves from generalities to engineering faster when several production materials are at hand. Nothing exotic is needed — usually this already exists in the quality department or can be assembled in a couple of days.
The more specific the input data, the more accurately we can state the achievable defect detection completeness, false positive rate, and the boundaries where automation still falls short of humans.
- List of operations. At which stages inspection exists now, where a defect surfaces only at final acceptance, and which operations the area physically does not have time to inspect.
- Examples of acceptable and defective parts. For each typical defect — several samples or images, including disputed cases at the tolerance boundary: these are what set the trigger threshold.
- Production area layout. Equipment locations, camera or sensor installation points, available lighting, the rejection discharge zone, and the operator’s position.
- Line rate constraints. How many parts pass per shift, whether there are peak intervals, whether a short inspection delay is acceptable, or the decision must fit within the current takt.
- Requirements for storing results. Retention period, whether traceability by batch and serial number is needed, who gets access to images and the decision log, and whether export to an accounting system is required.
- Procedure for actions on a defect. What the operator currently does when a defect is suspected, who makes the final decision, and how a disputed part is documented.
- Acceptance criteria. What will prove operability: share of missed defects, share of false stops, batch review time, reproducibility between shifts.
Some data may be missing — that is normal: we will close the gaps on site, and we will capture and describe some defects ourselves during model preparation.
Describe your task — we will come back with an estimate, a pilot operation plan, and a list of what will be required from the production area.
