You have three years of vibration data and eleven recorded failures. What can you honestly build from that?

Eleven is the number that decides the project

The temptation is to treat this as a modelling problem with an unfortunate class imbalance, and the answer that impresses treats it as a sample-size problem that governs what may be claimed at all. You have eleven independent observations of the thing you want to predict. Every statement about how well anything works must survive being restated as a fraction of eleven, and any method that needs to learn a rich mapping from signal to time-to-failure has roughly one example per parameter it would like to fit.

That reframing kills a particular proposal immediately. Regressing remaining useful life in weeks, trained on eleven degradation trajectories, will produce a model that fits those eleven beautifully and generalises to nothing, and its outputs will be quoted to a maintenance planner as though they were a date. Saying so early, and saying what you would build instead, is the single most useful thing a candidate does in this conversation.

It also changes the shape of the split. Eleven events cannot be divided into a train and test set that both support conclusions, so the honest structure is either a leave-one-event-out evaluation or a strict time-ordered holdout in which the most recent events are never used for any decision about features or thresholds. Random row-wise cross-validation is not merely weak here, it is actively misleading, because consecutive samples from the same machine minutes apart are near-duplicates and will appear on both sides of the split.

What the maintenance record actually says

Before any of that, the eleven have to be interrogated, because they are not labels, they are work orders. A work order records that a technician was dispatched, that a component was replaced, and when the paperwork was closed. It does not record when the fault began, and the closure date is often days after the intervention and sometimes weeks. If you take the closure timestamp as the failure time, your labels are systematically late by an unknown and variable amount, and a model trained against them learns to fire after the event.

So each of the eleven needs reconstructing as an interval rather than an instant: when did the machine's behaviour first depart from its own normal, when was the problem noticed, when was the work done, and when was the record closed. That reconstruction is done with the technician, in front of the trend, and it is the most valuable half-day in the project. It also tends to disqualify some of the eleven. A bearing replaced because it was accessible during unrelated work is not a failure. A failure caused by a foreign object is not a degradation process and cannot be predicted from vibration. Coming out of that exercise with seven usable events and a clear statement of what the other four were is a better position than starting with eleven of unknown quality.

The free-text field is where the useful information hides, and it is also where the same fault has been described nine ways. Building a small controlled vocabulary of failure modes, agreed with the maintenance team, is what makes it possible to say later that the model detects outer-race bearing degradation and does not detect coupling misalignment. A model that "predicts failure" without naming which failures is not deployable, because the people receiving its alerts need to know what to go and look at.

Every preventive replacement is a failure that did not happen

The subtler data problem is censoring, and it is the one that separates candidates who have done reliability work from those who have done classification work. A plant on a preventive schedule replaces components before they fail. Those intervals end without an event, which means the component's life is known only to have exceeded the interval, not to have equalled it. Treating those periods as healthy examples is defensible; treating them as evidence that the machine was nowhere near failing is not, and it will bias any model of time-to-event towards optimism.

This is why survival framing is worth naming even when you do not use it. The question "what is the probability this asset survives the next thirty days given it has run this long and looks like this" handles censored observations natively, whereas a binary classifier over fixed windows quietly discards the information. With eleven events you are not going to fit an elaborate hazard model either, but the framing tells you which quantity to report and stops you asserting a point estimate you cannot defend.

The same care applies to what happened after each intervention. A replacement resets the component's age and does not reset the machine's, and a poorly executed repair introduces its own fault, so the period immediately following maintenance is often the least normal data you have. Whether that window is excluded, flagged or modelled is a decision to make explicitly rather than by omission.

Build a deviation model, not a failure classifier

What three years of data does support, generously, is a model of each machine's own normal behaviour under comparable operating conditions, plus a health index derived from features that are known to relate to the physics rather than learned from eleven examples.

Vibration is unusually generous here because the relationship between defect and frequency is derivable rather than empirical. Rotating machinery produces energy at the shaft rate and its harmonics, gear meshes produce energy at tooth-passing rates, and rolling-element bearings produce characteristic frequencies computable from the bearing geometry and the shaft speed. So the feature set is not a bag of statistics from a raw waveform, it is band energies at the frequencies where the failure modes you care about live, plus envelope or demodulation analysis for the impulsive early signatures, plus overall level trends against published severity guidance for the machine class. Those features carry meaning, they can be explained to a reliability engineer, and they need almost no labelled data to justify.

Conditioning is what makes deviation usable. A pump's vibration signature depends on speed, load, product and temperature, so an alert that fires whenever the machine works hard is a load detector. Comparing like with like, either by restricting to defined operating states or by normalising against the operating point, is the difference between a health index and a duty-cycle chart. Where a fleet of identical machines exists, comparing each against its own history and against the fleet gives you two independent signals, and disagreement between them is informative in itself.

Evaluate per event, and price the false alarms

Row-wise metrics on this problem are vanity. With three years of continuous data and eleven events, a model that never alerts is right almost all of the time, and area under the curve computed over samples will look impressive because the negatives dominate. There are two numbers that matter, and both are stated in operational terms.

The first is per-event detection with a lead-time window: of the events that remain after cleaning, how many were flagged early enough to be actionable and not so early that the alert would have been dismissed, where the definition of early enough comes from the planner and depends on spares lead time and the next available maintenance window. A detection twelve hours before seizure is a nuisance; a detection eight months ahead is indistinguishable from noise to the person receiving it. Ask what window is useful before you tune anything.

The second is the alert rate expressed as alerts per machine per month, and whoever owns the maintenance team's time should be asked how many they will accept. That converts threshold selection from a statistical exercise into a capacity decision, and it is the number that determines whether the system is still being used in a year. A model catching nine of eleven at one alert per machine per month is a success; the same model at fifteen alerts per machine per month is an abandoned dashboard.

Both figures need reporting with their uncertainty, and with eleven events the uncertainty is wide. Saying that plainly, and proposing that the deployment's first purpose is to accumulate properly labelled events so that the next model can be better, is a more credible plan than a headline accuracy figure.

With eleven events you cannot learn what failure looks like in general, but you can learn what this machine looks like when it is well. Those are different projects, and only one of them is supported by the data on the table.