Logistics & Supply Chain
Fleet Maintenance Prediction API
A roadside breakdown costs several times what the same repair costs in a workshop on a Tuesday morning. The difference is almost entirely scheduling.
- Fleet operators
- Telematics providers
- Leasing and rental companies
- Fleet maintenance software
- Bus and coach operators
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Fleet maintenance sits between two bad options. Fixed-interval servicing replaces parts that had plenty of life left and misses the ones that failed early, because a schedule written for an average vehicle fits very few actual vehicles. Running to failure is cheaper on paper until the first roadside incident, which brings recovery, a driver stranded, a load that did not arrive and a workshop slot taken at short notice.
Most modern commercial vehicles emit enough data to do better. Fault codes, exhaust and coolant temperatures, battery voltage behaviour, brake wear, fuel consumption drift, and the duty cycle the vehicle actually experiences rather than the one the schedule assumed. A tipper on short urban runs ages nothing like a tractor unit on motorway line-haul, and the maintenance interval rarely reflects it.
Where this goes wrong is in overselling. Some components fail with observable degradation over weeks — batteries, brake pads, injectors, turbochargers — and those are genuinely predictable. Others fail abruptly with little warning in the telematics data, and a model asserting a 30-day horizon on those is producing noise. A useful product is explicit about which components it covers and which it does not.
Who buys this
Fleet operators, Telematics providers, Leasing and rental companies, Fleet maintenance software, Bus and coach operators
What the API returns
What comes back
- Failure risk per component with a horizon and confidence
- Remaining useful life estimates where the degradation signal supports one
- Recommended maintenance actions with urgency bands
- Expected downtime and workshop time per recommended action
- Duty cycle classification per vehicle, driving interval adjustment
- Fault code interpretation with historical outcome statistics
- Workshop scheduling suggestions that group work and respect vehicle availability
- Explicit coverage statement: which components are modelled and which are not
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/vehicles/{id}/risk | Component failure risk for one vehicle |
| GET | /v1/vehicles/{id}/recommendations | Recommended actions with urgency and downtime |
| POST | /v1/telemetry | Post telematics and fault code data for scoring |
| GET | /v1/fleet/risk | Fleet-wide risk ranking for planning |
| POST | /v1/schedule/suggest | Suggested workshop schedule across the fleet |
| POST | /v1/outcomes | Report actual failures and repairs for recalibration |
Request and response
illustrativeRequest
{
"vehicle_id": "veh_4412",
"make_model": "tractor_unit_4x2_euro6",
"odometer_km": 412880,
"window": { "from": "2026-09-22", "to": "2026-10-22" },
"include": ["components", "recommendations", "duty_cycle"]
}Response
{
"vehicle_id": "veh_4412",
"scored_at": "2026-10-22T03:00:00Z",
"duty_cycle": { "class": "motorway_linehaul", "idle_share": 0.09,
"avg_trip_km": 384 },
"components": [
{ "component": "starter_battery", "risk_30d": 0.44,
"remaining_useful_life_days": { "p50": 38, "p20": 17 },
"signal": "cranking_voltage_drop_trend", "confidence": "high" },
{ "component": "front_brake_pads", "risk_30d": 0.21,
"remaining_useful_life_days": { "p50": 71, "p20": 44 },
"signal": "wear_sensor_and_duty_cycle", "confidence": "high" },
{ "component": "turbocharger", "risk_30d": 0.08,
"remaining_useful_life_days": null,
"signal": "boost_deviation_mild", "confidence": "low" }
],
"not_modelled": ["clutch_assembly", "gearbox_internal", "injector_seals"],
"recommendations": [
{ "action": "replace_starter_battery", "urgency": "within_3_weeks",
"expected_workshop_hours": 0.8,
"expected_downtime_hours": 1.5,
"rationale": "Cranking voltage falling 0.4V over 30 days under similar ambient" }
],
"fault_codes": [
{ "code": "P0401", "occurrences_30d": 6,
"historical_outcome": "egr_valve_replacement in 61% of fleet cases" }
]
}Where the data comes from
| Vehicle telematics | CAN bus and telematics streams from your own units or your telematics provider — the primary signal and the main integration work |
| Fault code history | Diagnostic trouble codes with timestamps, which become useful when paired with what the workshop subsequently did |
| Workshop and repair records | Completed jobs, parts replaced and failure descriptions — the labels, and usually the messiest data in the project |
| Vehicle specification data | Make, model, drivetrain and fitted components, so a model is not trained across incomparable vehicles |
| Manufacturer service schedules | Published intervals as a baseline the predictions adjust rather than replace |
| Operational records | Routes, loads and gradients, which define the duty cycle the vehicle actually experiences |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Component-level models rather than one vehicle health score, because a battery and a brake pad share no degradation physics
- Explicit coverage boundaries: components without a usable degradation signal are reported as not modelled instead of given a fabricated risk
- Duty cycle classification from telematics, used to adjust intervals — the same odometer reading means different wear on urban stop-start than on line-haul
- Remaining useful life as a distribution, with the lower quantile being the number a planner actually schedules against
- Fault code interpretation grounded in your fleet's own historical outcomes rather than the generic code description
- Survival models with censoring handled properly, since most components in the training data have not yet failed
- Workshop scheduling as a constrained grouping problem: batching work on a vehicle, respecting availability and bay capacity
- Continuous recalibration against reported outcomes, with per-component accuracy published and components dropped when they do not validate
What it changes for the business
Planned instead of roadside
Work moves into booked workshop slots, which costs a fraction of a recovery and a missed load.
Intervals that fit the vehicle
Duty-cycle-adjusted servicing stops replacing good parts on easy-duty vehicles and catches hard-duty ones earlier.
Grouped workshop visits
Batching predicted work into one visit reduces total downtime more than any single prediction does.
Honest coverage
Naming the components that are not predictable keeps trust in the ones that are.
How it fits into your product
How it embeds
- Telemetry ingested from your telematics provider's API or pushed directly from your own units
- Daily fleet scoring with on-demand endpoints for a single vehicle before dispatch
- Webhooks on urgency escalations into your maintenance planning or workshop system
- Scheduling suggestions that respect your bay capacity and vehicle availability windows
- Outcome posting from workshop job cards, which drives recalibration
- Deployment inside your infrastructure where telematics data cannot leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Which components can you actually predict?
Those with an observable degradation signal in the available data: starter batteries, brake wear, EGR and aftertreatment issues, some injector and turbo conditions, tyre wear where sensors exist. Clutches, gearbox internals and many abrupt mechanical failures are not reliably predictable from telematics, and the API reports them as not modelled. A product that returns a risk figure for every component is giving you noise with a decimal point.
How much history do you need?
At least a year of telematics paired with workshop records, and enough failure events per component to learn from — in practice a few dozen. A fleet of thirty vehicles will not have that for most components, and the sensible approach there is pooling across similar fleets if the data is available, or starting with the components where the signal is strong enough to work on physics rather than history.
Our workshop records are a mess. Is that fatal?
It is the usual situation and it is the main cost in the project. Free-text job descriptions, inconsistent part naming and repairs recorded days after the fact all have to be reconciled before anything can be trained. We scope that work explicitly in discovery rather than discovering it in week six, and sometimes the honest finding is that the labels will not support a model for a particular component.
Will it reduce our maintenance spend?
It should shift spend rather than only reduce it — fewer roadside incidents and fewer premature replacements, but also some components replaced that a fixed schedule would have run longer. The clearer saving is in downtime and recovery, which is usually the larger number. We would measure it against your own historical baseline rather than quote a figure.
Does this replace statutory inspections?
No. Legally mandated inspections and maintenance remain exactly as they are, and the predictions sit alongside them. Nothing in the API should be read as permission to extend a regulated interval.
Related blueprints
Supplier Reliability Scoring API
Punctuality, quality incident and disruption risk scoring per supplier, for procurement and supply chain software.
Route Risk Intelligence API
Disruption, weather exposure, security and delay indicators along a planned route, for transport planning and freight software.
Delivery Time Prediction API
Estimated delivery windows and delay probabilities per shipment, as the promise engine behind a commerce or carrier product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.