Two of the world's largest machine vision companies couldn't solve this problem
A metal fabricator runs 8,000+ product variants across 6 lines, 11,520 units per day, with automated PLC changeovers driving recipe switching between SKUs. Two of the largest hardware-locked vision platforms evaluated the account. Neither could deliver. That is not a competitive slight. It is an architectural observation. Their systems are built for bounded SKU environments. This production environment is unbounded by design. The failure was structural, not technical.
The current state on this account: HyperQ AI Vision deployed across 6 lines, 8,000+ product variants inspected at 99% detection rate, zero per-recipe configuration. Same camera infrastructure on the line. Different decision architecture sitting behind it.
Why hardware-locked vision platforms hit a ceiling at scale
Rule-based vision is a per-recipe configuration model. A human engineer teaches the system what each product variant looks like: defines the regions of interest, sets the thresholds, calibrates against good samples, validates against defective ones. At 30 SKUs that is manageable. At 40, practitioners running multi-variant lines describe the problem as one that "balloons." At 8,000+ with automated changeovers, the math is impossible before the project begins.
The vendor capability ceiling is named directly by engineers running these tools in production: parametric inspection that requires per-part database lookups is impossible with the drag-and-drop packages built around hardware-locked platforms. The tools can hold a finite library of fixed recipes. They cannot perform conditional logic that resolves "what is this part" against a database before deciding "what defines a defect for this part." When the PLC drives a recipe change every few minutes across 8,000+ variants, the human-in-the-loop becomes the bottleneck. The bottleneck is not the camera, the optics, or the algorithm. It is the architecture itself.
The configuration overhead math
The numbers practitioners report on hardware-locked deep-learning vision are public:
- 40-60 hours to rebuild one deep-learning vision program from scratch
- 8+ hours per change or compilation cycle once the program is running
- 6 months to get one weld-specific profiler working correctly on a single weld type
- 200+ samples required for deep-learning validation under the incumbent stack, versus 30 for traditional rule-based
Multiply by 8,000 SKUs. Even at a notional 1 hour per recipe, far below the deep-learning figure for any non-trivial configuration, that is 8,000 engineering hours before the line produces a part. Six months per weld profiler across the variants this fabricator actually welds is a multi-decade project before it touches first article.
This is the moment automation breaks the per-recipe model. As long as a human operator could manually load the right recipe between part runs, the vendor architecture worked. The moment the PLC switches recipes automatically, without an engineer in the loop, the architecture exposes its assumption: that someone will always be there to teach the next part.
The weld-specific physics layer
Weld seam inspection on metal fabricated parts is one of the harder vision problems in manufacturing, for reasons specific to the substrate.
Reflective metal surfaces destabilise general-purpose detection. Reports from engineers detecting scratches and seams on reflective metal show overlapping predictions for the same defect, false detections of engraved text as features, and predictions flickering between frames. A general-purpose model handed reflective metal often performs worse than a smaller, task-specific model trained on the exact substrate. Parameter count is not the limiting variable. Training distribution is.
Weld appearance changes with process conditions. Heat input, wire feed speed, shielding gas mixture, and travel speed all affect the visible color and texture of the seam. Two welds passing the same structural spec can look meaningfully different. A threshold-based system has no way to distinguish process-driven appearance variation from a real defect. It rejects both, or it tolerates both. Either failure mode breaks the line.
Access geometry constrains what cameras can see. Complex fabricated parts have weld locations that physical cameras cannot reach in standard configurations. A vision system that requires perpendicular alignment to the seam works on flat panels and breaks on bracketry, weldments, and assemblies. The cosmetic-versus-structural gap is real: visual match does not guarantee structural integrity, and vice versa. Practitioners working in multi-variant fabrication have stated that on some part families, automated inspection has zero place because of access constraints alone.
A working solution on 8,000+ welded variants is not a marginal improvement on the incumbent stack. It is a different inspection architecture.
What "software-native" means in this deployment
The phrase "software-native AI vision" is doing real work here. The architectural difference, named precisely:
Hardware-locked vision platforms bind inspection logic to camera hardware. The decision rules live inside a controller designed for one platform's cameras and one platform's tooling. Adding a new product variant means programming the controller, which means buying time on a hardware-vendor configuration cycle. The model and the camera cannot be decoupled.
Software-native AI vision separates the decision logic from the capture hardware. The camera produces images. The model, running on standard compute, decides what they mean. When the PLC sends a recipe change, the software receives the context (product code, expected weld profile, tolerance band) and resolves which model to apply per part. No controller reprogramming. No hardware-vendor support ticket. No 6-month profiler build per weld type.
For Client A's 8,000+ SKU environment, this matters in a specific way. The 8,000 products are not 8,000 separate inspection programs. They are entries in a database that the model resolves against, using shared learned features across the part family. New SKUs added to the line do not require a new configuration cycle. They require labeled samples added to the training set and a retraining pass, which the line owner triggers, not the vendor.
That is the architecture the incumbents could not match. Not because their detection accuracy is poor on a single SKU. Because their decision logic does not live in a place where it can be retrained by the customer at the cadence high-mix production demands.
The "enterprise-grade" inversion
Hardware-locked vision platforms are enterprise-grade for the production environments they were designed for. High-volume, bounded SKU, stable processes, single-product lines: their architecture remains hard to beat. A single SKU running 24/7 with one recipe is exactly where their per-recipe model is most efficient.
The inversion happens at scale. At 8,000+ SKUs with automated changeovers, the "enterprise" systems require more manual engineering work, not less, than a software-native deployment. The premium that buys stability in a bounded environment becomes the constraint that prevents the system from operating in an unbounded one.
The practitioner community is already at the crossover point. The framing in production-engineering discussion has shifted from "rule-based versus AI" to "rule-based handles predictable checks, custom models fill the variability gaps." That is the architectural admission. The incumbents are excellent at predictable. High-mix production is, by definition, the variability gap.
What the deployment looks like
Across the 6-line build-out for Client A, HyperQ AI Vision delivers:
- 8,000+ product variants with zero per-recipe configuration after initial training
- 11,520 units inspected per day at production cadence
- 99% defect detection rate at the welded-assembly level
- 30-50% hardware cost savings versus the equivalent build on hardware-locked ecosystems, because the camera layer is not the constraint
- 60-80% false positive reduction versus the prior threshold-based check
Hardware reused: existing line cameras, existing PLC integration. New: the model layer, the database that resolves product code to expected profile, and the line-side retraining workflow that the customer's quality team owns.
The reason both incumbent vendors said no on this account, after evaluation, was not the capability of the underlying detection algorithms. It was the time and engineering cost to stand up 8,000+ recipes inside their architecture. That cost is not improving with software updates. It is fixed by the architecture.
The question worth asking before the next vision RFP
The question is not which vision vendor is best. The question is whether the production environment is bounded or unbounded.
Bounded: single product family, ≤30 SKUs, stable process, predictable defect catalogue. Hardware-locked platforms remain excellent. Stay with them.
Unbounded: multi-product, automated changeovers, growing variant count, defect classes that change with material or process. Per-recipe architecture cannot follow the line into this environment. Software-native inspection is the working alternative. Not because the model is "better AI," but because the decision logic is in a place where it can change at the cadence the line changes.
Hardware-locked vision had its decade. It is still the right call on the lines it was designed for. It is the wrong call on the lines that don't fit that shape.