Why predictive maintenance dies at the last mile.

Every OEM deck has the same slide. Sensors, cloud, a brain icon, and the words predictive maintenance. Almost every fleet has the same reality. A pilot that impressed the innovation team, a press release, a green milestone, and not one maintenance decision changed.

The gap is rarely accuracy. It is the last mile, the distance between a correct prediction and a crew that acts on it. Most systems die somewhere in that mile, between the proof of concept and the people on the tools. Rarely because the mathematics is wrong. Usually because trust was never part of the product.

I have spent the last four years in that mile, building equipment-health and failure-prediction products for marine and energy systems. This is what it taught me.

In most engine organizations, failure prediction is not missing. It is a person. One senior expert who reads trends the way a doctor reads blood pressure, sees a drift weeks before any alarm, and carries the method in his head and his spreadsheet.

Take a crankcase slowly losing its seal. The pressure drifts for weeks before a conventional threshold would fire. The expert does not look at the value. He looks at the rate of change, projects it forward, and tells the fleet how many operating days remain before someone must act.

The knowledge is real, proven, and completely unscalable. He cannot watch every engine. He cannot be awake every hour. And one day he retires.

The standard play is to replace him. Collect everything, train a model, ship the dashboard.

It fails three times over. There are no labels, because failures are rare and what the workshop found is written down poorly or not at all. There is no trust, because a service organization will not act on a black box, and acting is the entire product. And there is no feedback loop, because without service confirmations the model never learns whether it was right.

The expert's skepticism, which the project plan calls resistance, is actually the domain's immune system. It is doing its job.

The sequence that works is almost the reverse.

First, automate the existing method faithfully. Same signals, same logic, the expert's judgment running every hour of every day. Not an AI. His method, at fleet scale.

Second, put it in front of the service organization as exactly that. Trust transfers from a person to a product far more easily than it forms around a model.

Third, build the feedback into the daily workflow, so that every confirmed warning and every dismissed one becomes a label as a by-product of normal work.

Only then let models grow past the heuristics. By that point they have labels to learn from, a baseline to beat, and an organization that already opens the tool on a normal Tuesday.

Four things decide whether that sequence survives contact with a real fleet. I think about them with a lens borrowed from ecological psychology, James Gibson's tradition, in which perception and action form one loop and information only counts if an actor can pick it up and act on it.

Start from the action, not the sensor. A warning nobody can act on is noise with a timestamp. Think of the chief engineer at sea, the superintendent planning the next yard stay, the coordinator with two technicians and the right part on another continent. What each of them can do, and in what window, decides what is worth predicting at all. A precise warning that lands inside a window where no action is possible is worth less than a rough one that arrives with room to plan. Crews plan in operating days, not probabilities. Precision is not the target. Actionability is.

Respect what the data can and cannot contain. No model recovers information that the sampling already threw away. If the interval is coarser than the phenomenon, the event happens between two samples and leaves no trace. And the fight for better data is rarely technical. It is commercial. Who pays for the link, who owns the data, who signs off the installation. Before asking what a model could predict, ask whether the answer is in the data at all.

Treat mapping as a first-class problem. Ask an engine what its cylinder temperature is called and you get several correct answers, across generations, vendors and yards. One wrong column and years of history are quietly false, and nobody notices until a diagnosis is wrong. The tempting fix is one canonical schema imposed on everyone, and it breaks on contact with a real fleet, because no two installations offer the same information. The working fix accepts many routes to the same diagnostic outcome. Solve mapping and a surprising number of other problems stop being problems.

Close the loop in the workshop. The prediction is graded when the unit is opened, and the workshop rarely writes the grade down. What was found, what was replaced, what was fine. That record is the ground truth, and it usually lives as free text, in one person's memory, or nowhere. Until the system reads back what actually happened, every warning stays a hypothesis forever.

The failure-prediction work I lead went through exactly this sequence, and it is deployed and in daily diagnostic use today, rolling out across a service organization. What made the difference was none of the things the industry celebrates. It was time-to-alarm expressed in operating days. State transitions a diagnostician can argue with. A backbone boring enough to be trusted with somebody's night watch.

And one metric above all, the only one I have found worth steering by. How many maintenance decisions changed this month because of the product.

A day of unplanned downtime on a working vessel is measured in tens of thousands of euros. Fleets are aging. The experts who hold the failure knowledge are retiring faster than they are being replaced. The winners in this market will not be whoever owns the biggest platform or cites the most connected assets. They will be whoever crosses the last mile first.