Fleet management software has been around since the early 1990s. The core architecture — telematics hardware on vehicles, a server that ingests the data, a dashboard for fleet managers, rules that trigger alerts when thresholds are exceeded — has been incremented over the years but hasn't fundamentally changed. The rule engine at the center of most fleet management systems is the same logical structure it was twenty years ago: if speed exceeds threshold, alert. If engine temperature exceeds threshold, alert. If hours since last maintenance exceeds interval, schedule service.
Rule engines are good at known, enumerable conditions. They are systematically bad at three things: detecting anomalies that don't match any predefined rule, modeling the interactions between multiple signals that individually look normal, and adapting to the specific operational patterns of a particular fleet without manual reconfiguration. These three limitations are exactly where the value of fleet intelligence is sitting right now.
The enumeration problem in rule-based systems
A rule engine can only flag conditions that someone anticipated when writing the rules. This seems obvious, but the implication is non-trivial: a rule engine operating on fleet telematics data will systematically miss failure modes that haven't been explicitly specified. In a fleet of 50–200 vehicles operating in varied conditions, the space of possible failure precursors is large. Brake wear patterns vary by driver behavior and route characteristics. Transmission stress is affected by load profiles. Fuel consumption anomalies correlate with dozens of variables — driver style, vehicle age, route grade profile, ambient temperature, load weight — in ways that are difficult to capture in threshold rules.
The category of failure that ML models catch that rule engines miss is most clearly illustrated by a maintenance scheduling example. A rule engine schedules preventive maintenance at fixed intervals — every 20,000 km, every 6 months. An ML model trained on historical failure data can identify which vehicles in a fleet are showing early warning signals of specific failure types — based on subtle changes in fuel consumption patterns, unusual vibration signatures in telematics data, or correlations between driver behavior scores and stress indicators — and schedule maintenance at the optimal point: before failure is likely, but not wastefully early. The result is fewer unexpected breakdowns and lower total maintenance cost.
Optimal Dynamics is doing this for heavy-haul and long-haul trucking fleets. Their approach uses a combination of real-time telematics data, historical fleet data, and contextual operational data (route profiles, load characteristics) to build vehicle-specific predictive models rather than fleet-average rule sets. Each vehicle gets a model tuned to its specific operational pattern. The maintenance recommendations are specific to that vehicle's history, not the fleet average.
Multi-signal interaction is where rules break
The second limitation of rule engines — inability to model signal interactions — matters most in complex operational environments. Consider a scenario where a fleet manager sees: (1) slightly elevated idle time for three vehicles on a specific route, (2) marginally lower fuel efficiency than fleet average for those same vehicles, and (3) higher than average driver input corrections on that route. Each signal individually looks like it might be within normal variation. A rule engine evaluating each signal against its threshold doesn't trigger any alerts. An ML model that has been trained to recognize the interaction pattern across these three signals recognizes them as a compound indicator of suboptimal driver behavior on a specific route segment, and surfaces a coaching recommendation.
This isn't a hypothetical — it's the kind of compound pattern detection that separates fleet intelligence products from fleet monitoring products. Monitoring tells you what crossed a threshold. Intelligence identifies patterns that thresholds can't capture. The practical value of this distinction for a fleet manager is significant: driver coaching interventions targeted at specific route-behavior patterns reduce fuel consumption more reliably than generic driver scoring, because the intervention is specific to the identified problem rather than a ranking-based generalization.
Fleet-specific model adaptation without manual configuration
The third limitation of rule engines — inability to adapt to specific operational patterns without manual reconfiguration — is where the user experience difference is most visible. A rule engine deployed on a new fleet starts with generic thresholds. Getting it properly calibrated for the specific operating conditions of that fleet — the routes, the load types, the driver pool, the climate — requires manual configuration work. That work is typically done at deployment and then rarely revisited, which means the rule engine's calibration drifts as operational conditions change.
An ML-based fleet intelligence system, by contrast, can start with generic priors and adapt to the specific fleet's operational patterns over the first weeks of deployment as it observes real data. The model for a fleet of 3.5-tonne vans doing urban last-mile delivery in Gothenburg should look different from the model for a fleet of 18-wheel long-haul trucks doing Gothenburg-to-Hamburg runs. The model calibrates to the operational reality of each deployment automatically, based on what it observes.
This adaptation capability is a practical advantage that reduces the professional services burden on fleet intelligence companies and accelerates time-to-value for customers. A customer who can go live with a product in two weeks and see fleet-specific recommendations within the first month — rather than spending three months on calibration configuration — is much more likely to convert from pilot to production contract. The technical advantage (adaptive models) translates directly to a commercial advantage (faster deployment, faster value demonstration).
What rule engines are still better for
I want to be clear that this is not a case that rule engines are obsolete in fleet management. They're not. For compliance and regulatory requirements — hours of service logging, driver license verification, mandatory rest period enforcement — rule-based systems are exactly the right tool. The consequences of a compliance failure are specific, the rules are externally defined, and the behavior you want is precisely enumerable. ML models are not appropriate for compliance enforcement because you need auditability and deterministic behavior.
The case for ML is specifically for the operational optimization layer: predictive maintenance, fuel efficiency improvement, driver coaching, dynamic dispatch optimization. These are domains where the value comes from detecting subtle patterns and adapting to specific operational conditions — exactly what rule engines are bad at and ML models are good at. The right architecture for a mature fleet intelligence product is likely a combination: rule engines for compliance and threshold alerts, ML models for operational optimization. Companies that are trying to displace rule engines entirely in compliance contexts are solving the wrong problem.
The data required to make this work
None of this is possible without high-quality telematics data. The ML models for fleet intelligence require: GPS position at high frequency (ideally sub-minute), vehicle CAN bus data (engine parameters, fuel consumption, brake application, acceleration profiles), driver identification per trip, and load data when available. Most modern commercial vehicles generate this data — the constraint is whether it's being reliably captured, cleaned, and ingested into a system that can use it.
The companies building in fleet intelligence that we find most credible are the ones who have solved the data ingestion problem first — who have built reliable connectors for the major telematics hardware providers and have a data normalization layer that handles the variation in how different hardware captures the same underlying signals. The ML model matters. The data pipeline is what makes the ML model work in production.