“We put a defect-detection camera on the line, so our OEE should go up.” We hear a version of this constantly, and the disappointment that follows is almost always the same: the quality-loss column moved a little, the overall number barely twitched, and nobody can explain why. The gap is not a modelling failure. It is a definitional one. Overall Equipment Effectiveness is not a single lever. It is the product of three factors — availability, performance, and quality — multiplied together. A computer vision system that only flags defects touches one of those three, and only partially. If your line is losing OEE to micro-stops and slow cycles, a defect detector can be perfectly accurate and still leave the headline number roughly where it was. Improving OEE with computer vision starts with knowing which of the three factors you are actually trying to move, and then verifying the model holds accuracy under the same conditions that break vision systems elsewhere. What does “improve OEE” actually mean when you decompose it? OEE multiplies three ratios, each bounded between 0 and 1: Availability — the fraction of scheduled time the line is actually running. Eroded by unplanned stops, changeovers, and jams. Performance — actual throughput against the theoretical maximum speed. Eroded by micro-stops and reduced cycle rates. Quality — the fraction of produced units that pass first time. Eroded by defects and rework. Because they multiply, a line at 90% availability, 90% performance, and 95% quality lands at roughly 77% OEE — not 92%. This is the first thing that trips teams up. A five-point gain in quality on that line adds only about four points to OEE, because the other two factors dilute it. A vision system that targets the wrong factor delivers a fraction of the improvement the business case assumed. The practical consequence: before you scope a vision project, you need a loss Pareto that attributes lost OEE to specific factors and specific causes. Only then can you ask whether a camera can address the top losses — or whether the top losses are mechanical, scheduling, or supply problems that no model will touch. Which of the three OEE factors can computer vision actually influence? Quality is the obvious target, and the one most teams reach for first. But vision earns its place across all three factors when the task is chosen deliberately rather than by default. OEE factor What CV can plausibly do What it cannot do alone Availability Detect jams, misfeeds, and part-presence faults early enough to shorten unplanned downtime; verify changeover completeness Fix root-cause mechanical failures; replace PLC interlocks Performance Flag micro-stops and slow-cycle patterns by monitoring station state; detect starvation/blocking upstream Speed up a cycle that is mechanically rate-limited Quality Classify and localise defects; catch them before value-added downstream steps; reduce escapes to the customer Guarantee a gain if defect rates are already low, or if the true bottleneck is elsewhere The framing that matters here is the same one that governs retail shelf analytics: a vision system is only as useful as the specific decision it feeds. In shopping basket analysis with retail computer vision, the model output is worthless unless it connects to a replenishment or layout decision. On a production line, a defect classification is worthless unless it maps to an OEE loss someone is accountable for reducing. Retail and manufacturing share the same discipline problem: our retail computer vision work taught us that a detection is not an outcome. How do you map an OEE loss category to a concrete vision task? This is the step most POCs skip, and skipping it is why they fail to move the number. The mapping is not “we have defects, so we need a defect detector.” It is a chain: named loss → the physical event that causes it → the visual signature of that event → the vision task that captures the signature → the accuracy threshold at which capturing it changes a decision. Consider a worked example. A packaging line loses roughly six OEE points to a “seal integrity” quality loss (attribution from the line’s loss Pareto — an operational measurement, not a benchmark). The physical event is an incomplete heat seal. Its visual signature is a discontinuity in the seal band, sometimes only a few pixels wide against a visually similar background. The vision task is fine-grained defect segmentation, not whole-image classification, because the defect is small and localised — the same reasoning behind crack segmentation for industrial inspection. The accuracy threshold is set by the cost asymmetry: a missed bad seal escapes to the customer, while a false reject becomes scrap. That last point is where quality-loss estimates get inflated. If the model’s recall on the rare “partial seal” class is weak, the POC — evaluated mostly on the common “good seal” class — still looks excellent on aggregate accuracy. The rare-class failure is invisible in the headline metric and only surfaces at line scale when the defects it misses show up as customer returns or when operators are quietly re-inspecting by hand. Reading object detection metrics like precision, recall, and mAP correctly is not a nicety here; it is the difference between an attributable OEE gain and a phantom one. Why does a CV model that passes a POC still fail to improve OEE at line scale? The divergence point is measurement discipline. A POC runs on a curated set, often balanced, often captured under favourable lighting, often with a defect distribution that does not match the line. Three forces — the same ones that break retail computer vision — pull line-scale performance below POC numbers. Visual similarity. When a defect class looks almost identical to an acceptable variation, the model’s decision boundary is thin. A scuff that is cosmetic on one product is a reject on another. Aggregate accuracy hides how often the model lands on the wrong side of that boundary, because the confusable cases are a small slice of the evaluation set. Understanding how the model expresses that uncertainty — its confidence score and what it actually means — is part of setting a defensible reject threshold rather than a POC-tuned one. Class imbalance. Real defect rates are often well under a few percent. A model that predicts “good” every time can score above 95% aggregate accuracy while catching almost no defects. This is not a hypothetical; it is the default failure mode of any imbalanced classification problem, and it is why per-class recall on rare defects — not overall accuracy — is the metric that predicts OEE impact. In our experience across inspection engagements, the rare-class recall gap between POC and line is the single most common reason a quality-loss estimate turns out inflated (observed pattern across TechnoLynx engagements; not a benchmarked rate). Edge-hardware constraints. A model validated on a workstation GPU behaves differently after it is quantised and compiled for the edge device that will actually run it at line speed. Quantisation to INT8 or lower, kernel fusion in a runtime like TensorRT or ONNX Runtime, and the throughput ceiling of the target accelerator all shift the operating point. The foundations of how a 2D CNN works for production inspection explain why small-defect sensitivity is exactly what degrades first when you trade precision for latency. A model that must keep pace with a line running dozens of parts per minute cannot be the same one that scored well offline unless someone verified the edge build holds its rare-class recall. A readiness rubric before you attribute OEE gains to a vision system Use this as a gate. A vision task should clear all five before its OEE contribution is booked as real rather than assumed. Loss attribution exists. The target loss is quantified in the line’s OEE Pareto, and its factor (availability / performance / quality) is named. No Pareto, no target. Task-to-signature mapping is explicit. The vision task captures the physical event’s visual signature, and the required decision (reject, alert, stop) is defined with its cost asymmetry. Per-class recall meets threshold on rare classes. Evaluation reports recall on the defect classes that drive the loss, not just aggregate accuracy, on a distribution that matches the line. Edge build is validated. The quantised, compiled model has been measured on the target device at line speed, and its rare-class recall survived the precision trade. Manual-burden check. If detection accuracy fails, the fallback is not silent re-inspection by operators. A degradation that shifts work back to manual inspection is an OEE loss, not a neutral outcome. The fifth criterion is the one that quietly sinks projects. A vision system that misses defects does not leave OEE unchanged — it adds a manual inspection task and erodes the performance factor it was never scoped to touch. FAQ What does working with improve OEE involve in practice? OEE is availability multiplied by performance multiplied by quality, each a ratio between 0 and 1. Because they multiply, a gain in one factor is diluted by the other two — a five-point quality gain on a line already losing availability and performance adds only a few points to the headline number. Improving OEE in practice means attributing losses to specific factors first, then acting on the largest ones. Which of the three OEE factors — availability, performance, quality — can computer vision actually influence? Quality is the most direct target through defect detection, but vision can also support availability (early jam and misfeed detection to shorten downtime) and performance (flagging micro-stops and slow-cycle patterns by monitoring station state). What it cannot do alone is fix mechanical root causes or speed up a cycle that is rate-limited by the machine itself. How do you map a specific OEE loss category to a concrete vision task? Follow the chain: named loss from the OEE Pareto, the physical event that causes it, that event’s visual signature, the vision task that captures the signature, and the accuracy threshold at which capturing it changes a decision. A small, localised defect implies fine-grained segmentation rather than whole-image classification; the reject threshold is set by the cost asymmetry between a missed defect and a false reject. Why does a CV model that passes a POC still fail to improve OEE at line scale? POCs typically run on curated, balanced sets under favourable conditions, so aggregate accuracy looks strong even when rare-class recall is weak. At line scale, visual similarity, class imbalance, and edge-hardware constraints pull performance below POC numbers, and the missed defects surface as customer returns or quiet manual re-inspection. The headline metric hides the failure that matters. How do visual similarity, class imbalance, and edge-hardware constraints inflate quality-loss estimates? Visual similarity thins the decision boundary between defects and acceptable variation, so confusable cases — a small slice of the evaluation set — are mispredicted. Class imbalance lets a model score high on aggregate while catching almost no defects. Edge quantisation and compilation shift the operating point so a model validated on a workstation loses small-defect sensitivity first. Each effect makes the estimated quality gain larger than what the line actually realises. What accuracy and stability criteria should a vision system meet before you attribute OEE gains to it? Require per-class recall on the rare defect classes that drive the loss, measured on a distribution matching the line — not aggregate accuracy. Validate the quantised, compiled model on the target edge device at line speed and confirm its rare-class recall survived the precision trade. Finally, check that a detection failure does not silently push work back to manual inspection, which is itself an OEE loss. The gap this leaves for the next evaluation The honest version of “computer vision improves OEE” is narrower and more useful than the pitch: vision moves OEE when a specific loss is named, the vision task captures that loss’s visual signature, and the model holds its rare-class recall after it is quantised for the device that runs it at line speed. Everything else is a POC number waiting to disappoint. If you are scoping a line before deployment, the four compound-failure axes in our A2 Production CV Readiness Assessment double as a filter for which OEE loss categories a vision system can reliably improve — and which will quietly shift burden back to manual inspection. That filter, not the OEE dashboard, is where the real decision gets made.
