We had a condition-based monitoring system installed about eight months before this happened, the kind that ingests vibration data, exhaust gas temperature spreads across cylinders, turbocharger speed, and boost pressure, and runs it through a model trained to flag deviations from expected behavior. Vendor-installed, reasonably well regarded in the industry, the kind of system more and more vessels are carrying now as part of a push toward predictive rather than purely scheduled maintenance.

At 0340 ship’s time, it generated an alert. Turbocharger speed had drifted roughly two and a half percent above the expected value for the current load and ambient conditions, and the deviation had been building gradually over about eleven hours rather than appearing as a sudden spike. The system flagged it as an anomaly requiring investigation, not an alarm requiring immediate action. That distinction matters, and I will come back to it.

I looked at the alert on my cabin display. I checked the actual engine parameters manually, exhaust temperatures looked normal, no unusual vibration reported by the watchkeeper, boost pressure within range. I concluded, in under a minute, that this was the system being oversensitive to a load transient, closed the alert, and went back to sleep.

Here is the honest accounting, because I think the sanitized version of this story, where I simply made a careless mistake, is less useful than the real one.

In the eight months that system had been running, it had generated something like sixty anomaly alerts across various machinery on the vessel. I had personally investigated maybe forty of them at the time this happened. Of those forty, thirty-six had resolved to nothing, sensor drift, a load transient the model had not seen enough examples of yet, a calibration issue with one of the vibration sensors that took the vendor three weeks to properly diagnose and correct. Four had pointed to something genuinely worth adjusting, none of them urgent. My actual, if unspoken, mental model by that point was something close to “this system flags things I do not need to worry about roughly ninety percent of the time.” That is not an irrational conclusion. That is what the data I had personally experienced was telling me. The problem is that a ninety percent false positive rate, from the system’s actual underlying accuracy, still means the ten percent it gets right can be the one that costs you a turbocharger.

I also want to be honest about the human factor. It was 0340. I had been up since 0600 the previous day dealing with an unrelated generator issue. The alert came through as an anomaly, not a critical alarm, meaning it did not require the kind of immediate physical verification that a critical alarm does under our procedures. Every incentive in that moment, tiredness, a track record of false positives, a classification that explicitly did not demand urgent action, pointed toward exactly what I did.

After the failure, I spent a significant amount of time with the vendor’s technical support team going through exactly what the model had detected, because I wanted to understand whether this had genuinely been predictable or whether I was simply looking for a story that made me feel better about missing it.

It had genuinely been predictable, and understanding why taught me something about how these systems actually work that I wish I had understood before, not after.

The two and a half percent turbocharger speed deviation was not, on its own, the important signal. What the model had actually detected was a specific correlation pattern: turbocharger speed drifting upward while exhaust gas temperature at that specific cylinder bank stayed essentially flat, a combination that does not happen under normal load transients, where you would expect both to move together in the same direction. That decoupling between the two parameters was the actual anomaly, and it is a pattern consistent with early-stage turbocharger bearing degradation, where increasing rotor imbalance and internal friction starts pushing the turbine to work slightly differently than the combustion process alone would explain.

I had checked exhaust temperatures manually that night and seen nothing alarming, because I was looking at whether the temperatures themselves were high, not whether the relationship between temperature and turbocharger speed had changed. The model was not seeing a single parameter out of range. It was seeing a relationship between two parameters quietly breaking down in a way that 25 years of my own experience reading gauges had never trained me to look for, because that specific correlation is not something a human being can track by eye across a shift, but it is exactly the kind of pattern a properly trained model is good at catching.

Three days after the alert, during a period of sustained higher load on a longer passage, the turbocharger bearing failed. Not a clean shutdown. The rotor assembly suffered damage severe enough that fragments made their way into the turbine housing, which meant the repair was not a straightforward bearing replacement but a full turbocharger overhaul with the housing itself needing inspection and partial replacement.

Eleven days alongside waiting for parts and a specialist technician. A repair bill that came in just over ninety thousand dollars once you accounted for parts, labor, and the specialist’s travel and standby time. And the operational disruption of running at slow speed with the main engine for those eleven days, which is its own quiet risk that does not show up on any invoice.

The alert I dismissed at 0340 had been generated roughly seventy-two hours before that failure. Seventy-two hours is not a narrow window. That is enough time to schedule a borescope inspection at the next reasonable opportunity, enough time to reduce load on that unit preemptively, enough time to at minimum brief the watchkeepers to monitor that specific turbocharger more closely. I had all of that time, and I spent eleven seconds on it instead.

The obvious lesson, the one everyone expects me to have learned, is “always investigate every AI alert immediately and thoroughly.” I want to be honest that this is not actually what I changed, because it is not sustainable advice. If I treat every anomaly alert with the same urgency as a critical alarm, I will burn out my watchkeeping team and myself within a month, and the whole point of a tiered alert system, distinguishing anomalies from alarms, will have been defeated.

What I actually changed is more specific and, I think, more useful.

• I stopped treating “false positive” and “not urgent” as the same category. Most of those thirty-six earlier alerts that resolved to nothing were still telling me something true about sensor drift or calibration issues, even when they were not predicting imminent failure. I now log every anomaly with a brief note on what it actually was, building my own track record instead of relying on a vague memory of “this thing cries wolf a lot.”
• I asked the vendor to show me, specifically, which parameter correlations the model weights most heavily for each type of failure it is trained to detect, rather than treating it as a black box that occasionally beeps. Understanding that turbocharger degradation shows up as a speed and temperature decoupling, not as either parameter individually crossing a threshold, changed how I read every alert since.
• I built a specific escalation rule for correlation-type anomalies versus single-parameter anomalies. A single sensor drifting gets logged and monitored. A relationship between two parameters breaking down, the kind of pattern a human cannot easily track manually, now gets an actual physical inspection within one watch, not deferred to the next convenient opportunity.
• I stopped evaluating the system’s usefulness by its overall alert volume and started evaluating it by the cost-weighted outcome of the alerts I could have acted on. Thirty-six low-stakes false positives and one ninety-thousand-dollar miss is not a system with a bad hit rate. It is a system that was right exactly when it mattered most, and my filtering process failed to distinguish the one that mattered.

I have talked to enough colleagues since this happened to know I am not alone in this pattern, and I think the industry conversation about AI-based monitoring focuses too much on model accuracy and not enough on this specific human failure mode.

Alarm fatigue is an old problem in engine rooms, well understood long before anyone put a machine learning model on a vessel. Too many alarms, not enough differentiation, and crew learn to filter almost everything. What is different, and what I underestimated, is that an AI system’s false positives feel different from a sensor alarm’s false positives. A sensor alarm that cries wolf is usually a calibration problem you can diagnose and fix. An AI system’s false positives often come from the model genuinely not having seen enough examples of a legitimate but unusual operating condition yet, which means the false positive rate can improve over time as the model sees more data, but in the meantime it produces exactly the kind of pattern that trains a tired engineer to stop trusting it at precisely the moment it starts getting good.

Nobody explained that dynamic to me when the system was installed. I was told it would get better over time. Nobody told me that the specific danger period was the middle of that improvement curve, where the system has enough false positives behind it to have earned my skepticism, but has also gotten good enough to start catching real, subtle failures that my own eleven years of manual gauge-reading had never been trained to see.