Why Learning-Based Perception Fails in Industrial Products

There is a pattern that repeats across industrial product development teams that have attempted to build perception using machine learning. The system works well in the lab. It performs acceptably in early field trials. Then, six months into production, a customer reports that detection is inconsistent in one of their facilities. The environment looks slightly different from the training data. The model was never exposed to that combination of lighting, dust density, and object geometry. Performance degrades in ways that are difficult to predict and harder to explain to a customer. It is a structural property of how learning-based perception systems work, and it has significant consequences for any OEM building a product where reliable, consistent detection is a requirement.

How learning-based systems are built, and where that creates problems

1. A learning-based perception system derives its detection and classification behaviour from a dataset of labelled examples. The model learns statistical patterns from that data and applies them to new inputs. When the new inputs are sufficiently similar to the training distribution, performance is good. When they are not, performance degrades in ways that are difficult to anticipate.

2. In controlled environments with stable, well-characterised inputs, this can be managed. In industrial settings, it is a fundamental challenge. No two industrial sites look the same. Lighting conditions vary by season, time of day, and facility layout. Dust levels change with production intensity and ventilation. Object types, sizes, and movement patterns differ between customers and between different areas of the same site.

3. Building a training dataset that covers this variation adequately requires a significant and ongoing commitment. Sensors must be deployed, data must be collected across the full range of conditions the product will encounter, images or point clouds must be labelled by annotators who understand what they are looking at, and the model must be trained, validated, and tested before any update reaches production. For a single product targeting multiple industries, this process does not happen once. It is a recurring operational burden.

The hidden cost is in the edges

The cases that cause the most damage in practice are not the obvious failures. They are the edge cases: scenes that fall just outside the training distribution and produce confident but incorrect outputs.

A model that has learned to detect people in mining environments may struggle with operators wearing non-standard PPE. A system trained on forklift traffic in a European logistics facility may behave differently in a Southeast Asian port where vehicle types and movement patterns differ. The model does not know that it is operating outside its reliable range. It continues to produce outputs. Those outputs may look plausible while being wrong.

In consumer applications, edge case failures are an acceptable cost. In industrial products where detection outcomes are connected to machine control, safety zones, or operational decisions, they are not. A false negative in a safety-critical zone is not a product quality issue. It is a liability.

Overfitting is not just a training problem

Overfitting is typically discussed as a model training failure: a model that has memorised its training data rather than learning generalisable patterns. But in industrial product deployment, the more common problem is operational overfitting, where a system that performed well in validation continues to perform well on sites that resemble the validation environment and degrades on sites that do not.

This is difficult to detect during development because the development environment is, by definition, well-represented in the training data. It becomes visible in production, at customer sites, in conditions that were not anticipated during development. At that point, the remediation path is to collect new data, annotate it, retrain, validate, and redeploy, a cycle that takes time and resources and leaves the customer with a product that is not performing to specification in the interim.

What a deterministic approach avoids

1. A parameter-based detection system derives its behaviour from explicit rules rather than learned patterns. Object classification is defined by configurable parameters: size, speed, position relative to defined zones. The system applies those rules consistently to every scene it processes.

2. There is no training data requirement. There is no distribution shift problem. There is no edge case where the system produces a confident incorrect output because the scene resembles training data it has overfit to. The system behaves according to its configuration, and that configuration can be inspected, understood, and adjusted by the product team directly.

For OEM manufacturers, this changes the product development and maintenance equation significantly. Validation is straightforward: the same configuration produces the same outputs under the same conditions, every time. Customer-specific adjustments are made through configuration rather than retraining. A new site with different environmental conditions does not require a new model. It requires setting appropriate detection parameters for that environment, a process that takes hours rather than weeks.

The argument for industrial applications specifically

Learning-based perception has clear advantages in domains where the input space is genuinely too complex for explicit rules: natural language, image recognition across open-world categories, driving in unstructured urban environments. These are problems where the variation is too high and the relevant features too numerous for a human to specify directly.

Industrial stationary perception is not that kind of problem. The objects of interest are defined. The relevant measurements are spatial: position, size, speed, zone membership. The environmental variation, while real, is bounded by the operational specifications of the product. These are exactly the conditions where explicit, parameter-based rules are a better fit than learned models.

A product built on deterministic perception is a product that behaves predictably across the full range of conditions it was designed for, without requiring ongoing model maintenance, without accumulating edge case risk as the installed base grows, and without the validation complexity that learning-based systems introduce at every update cycle.

For industrial OEMs, that predictability is not a nice-to-have. It is a product requirement.

Flasheye’s detection and classification engine is fully parameter-based. Detection behaviour is deterministic, configurable, and consistent across operating conditions from the first installation. No training data, no model updates, no distribution shift.