Why Rare Failure Modes Break Predictive Maintenance Models and How Synthetic Data Fixes It
Why Rare Failure Modes Break Predictive Maintenance Models and How Synthetic Data Fixes It
Part of our GenAI-Augmented Predictive Maintenance for Jet Engines series — picking up directly where our RUL 101 primer left off, at the exact point where a good regression model quietly stops being trustworthy.
1. Hook
The engines most worth predicting a catastrophic failure for are, by definition, the ones your training data has almost no examples of — because jet engines are engineered specifically not to fail catastrophically, and the rare cases where they do are exactly the events every safety regulator, airline, and maintenance planner cares about most. This isn't a data-collection inconvenience to work around later; it's a structural contradiction sitting at the center of predictive maintenance, and understanding exactly why it breaks standard models — and what synthetic data generation can and can't do about it — is the difference between a benchmark-friendly RUL model and one that's actually trustworthy in the tail cases that matter.
2. Core Explanation
2.1 The Class Imbalance Problem, Restated for Time Series
Most people who've worked with any classification problem have encountered "class imbalance" in its simplest form: a fraud-detection dataset where 99.9% of transactions are legitimate, or a medical-screening dataset where the disease of interest affects a small fraction of patients. Predictive maintenance has this same imbalance, but it shows up in a subtler, more consequential form because RUL prediction (as covered in our companion RUL 101 primer) is fundamentally a regression problem over trajectories, not a simple binary classification over static rows.
The imbalance in predictive maintenance isn't just "few failure rows versus many healthy rows" — it's specifically an imbalance in degradation trajectory shapes. The overwhelming majority of any real or simulated fleet's run-to-failure histories follow a broadly similar, gradual wear pattern: slow, roughly monotonic decline across a comparable number of cycles, following a comparable set of sensor trends. A small minority follow a qualitatively different trajectory shape — a sudden, steep, non-linear decline triggered by a distinct fault mechanism (a bearing seizure, a blade liberation event, a rapid seal failure) that unfolds over a much shorter window and with a different sensor signature entirely. A model trained predominantly on the first pattern doesn't just have "less data" on the second — it has almost no exposure to what that trajectory shape looks like at all, which is a fundamentally harder problem than simply having fewer rows of an otherwise-familiar pattern.
This is precisely why the standard fix for tabular class imbalance — oversampling the minority class, or reweighting the loss function to penalize minority-class errors more heavily — only partially transfers to this setting. Reweighting can tell a model "pay more attention to these few severe trajectories," but it can't manufacture trajectory shapes the model has never seen a full example of. If your dataset genuinely contains only three or four examples of a bearing-seizure trajectory, no amount of reweighting those three or four examples teaches the model the general shape of that failure mode — it just teaches the model to memorize those specific three or four instances, which is a recipe for overfitting, not generalization.
2.2 Why Physical Systems Are Structurally Built to Make This Worse
It's worth pausing on why this imbalance is so severe in predictive maintenance specifically, compared to other machine-learning domains, because the answer isn't a data-collection failure — it's the system working as intended. As one patent filing on GAN-based failure prediction puts it plainly: physical equipment and systems are engineered not to fail, and as a result, failure data is inherently rare, difficult, and often prohibitively costly to collect — it is simply not feasible to deliberately run a fleet of operating aircraft engines to catastrophic failure in order to gather more training examples. Every certification standard, every maintenance interval, and every safety margin an aerospace engineer designs into an engine exists specifically to suppress the frequency of the exact event a rare-failure-mode model is trying to learn to recognize.
This creates a genuine paradox worth sitting with: the better the underlying engineering and safety culture of an industry, the worse the class-imbalance problem becomes for anyone trying to build a data-driven model of its rare failure modes. A domain with sloppier safety practices would, perversely, generate more abundant failure-mode training data. Predictive maintenance for aerospace is attempting to model exactly the events an entire century of aerospace engineering has been optimized to make as rare as possible.
2.3 What Happens When You Ignore This and Train Anyway
If you train a standard RUL regressor (of the kind covered in our RUL 101 primer — gradient-boosted trees, LSTMs, or transformers) on a dataset with this trajectory-shape imbalance without any specific countermeasure, the failure mode is predictable and well-documented in the literature: the model learns to predict RUL accurately for the dominant, gradual-wear trajectory pattern, because that's what the vast majority of its training gradient updates are shaped by, and it performs poorly — often dangerously overconfidently poorly — on the rare, severe trajectory shapes it barely encountered.
The "dangerously overconfident" part deserves emphasis, because it's the part that makes this a safety issue rather than just an accuracy issue. A model that has never really learned what a rapid-onset failure trajectory looks like doesn't typically respond to one by outputting a wide, uncertain RUL estimate — it responds by applying the only pattern it has learned well, the gradual-wear pattern, to a trajectory that is actually behaving completely differently. The result is a confidently wrong prediction: the model reports a comfortable, gradually-declining RUL estimate right up until the point of an actual rapid failure, because it is pattern-matching the early cycles of the rapid trajectory against the gradual-wear pattern it knows, rather than recognizing it as a different phenomenon entirely. This is functionally the worst possible failure mode for a safety-critical prediction system — not "doesn't know," but "confidently doesn't know that it doesn't know."
2.4 The Standard Toolkit for Imbalanced Data — And Where Each Tool Runs Out of Road
Before turning to generative synthetic data specifically, it's worth walking through the established toolkit for imbalanced learning, because generative modeling isn't a replacement for these techniques so much as the next escalation once they stop being sufficient.
- Random oversampling — simply duplicating existing minority-class examples until the dataset is more balanced. Cheap and simple, but it adds no new information; it just makes the model see the same handful of severe trajectories more times per epoch, increasing overfitting risk on those specific instances without teaching any generalizable pattern.
- Random undersampling — discarding majority-class examples until the classes are more balanced. This avoids the overfitting risk of duplication, but at the direct cost of throwing away real, informative healthy-trajectory data, which can hurt the model's ability to characterize normal operation well.
- Cost-sensitive learning — modifying the loss function to penalize errors on minority-class (severe-trajectory) examples more heavily than majority-class errors. This is often a genuinely useful first step and is comparatively cheap to implement, but it still can't manufacture shape diversity — it just tells the model to try harder on the few examples it already has.
- SMOTE (Synthetic Minority Oversampling Technique) and its variants — rather than duplicating minority examples exactly, SMOTE generates new synthetic points by interpolating between existing minority-class examples in feature space. This is a genuine step toward synthetic data generation, and remains a common, well-established baseline, but its core mechanism — linear interpolation between existing points — struggles specifically with time-series trajectory data, since a naive interpolation between two different degradation sequences doesn't necessarily produce a physically plausible sequence in between; it can easily produce trajectories that violate the temporal and physical coherence real degradation data has.
A recent comparative study on the AI4I 2020 predictive maintenance dataset tested exactly this progression — cost-sensitive learning, random undersampling, SMOTE oversampling, single-generator GAN augmentation, and a specialized multi-generator GAN architecture — against each other using precision/recall-oriented metrics, finding that generative approaches, and particularly failure-type-aware multi-generator architectures, produced more realistic minority-class samples and better recall on rare cases than the traditional resampling methods. This progression — from simple resampling, through cost-sensitive reweighting, through SMOTE-style interpolation, to full generative modeling — is essentially the field's collective answer to "when do you need to escalate to a genuinely generative approach," and the answer converges on: once trajectory shape diversity, not just point count, is what's missing.
| Technique | Core Mechanism | Adds New Information? | Handles Sequence/Shape Coherence? | Typical Role |
|---|---|---|---|---|
| Random oversampling | Duplicate existing minority examples | No | N/A (unchanged sequences) | Cheap first pass, high overfitting risk |
| Random undersampling | Discard majority examples | No (loses information) | N/A | Simple, but wastes healthy-trajectory data |
| Cost-sensitive learning | Reweight loss function | No | N/A | Good first step, doesn't create shape diversity |
| SMOTE / variants | Interpolate between existing minority points | Partial | Poor — can break temporal/physical coherence | Established baseline, weak on sequences |
| GAN-based generation | Adversarial generator/discriminator learns to synthesize new sequences | Yes | Good, when architecture is sequence-aware | Standard generative baseline for time-series augmentation |
| Diffusion-based generation | Iterative denoising process learns the data distribution | Yes | Strong — better mode coverage, more stable training | Emerging state-of-the-art for time-series synthesis |
2.5 How GANs Actually Learn to Generate Realistic Failure Trajectories
A Generative Adversarial Network (GAN) consists of two neural networks trained in opposition: a generator, which takes random noise as input and tries to produce synthetic data realistic enough to pass as genuine, and a discriminator, which is trained simultaneously to distinguish real training examples from the generator's synthetic output. The two are trained in a competitive loop — the generator gets better by learning to fool an increasingly discerning discriminator, and the discriminator gets better by learning to catch an increasingly sophisticated generator — until, ideally, the generator produces samples the discriminator can no longer reliably distinguish from real data.
For time-series degradation data specifically, plain GAN architectures need adaptation to handle sequence structure, which has produced several purpose-built variants referenced in recent predictive-maintenance research: Convolutional Recurrent GANs (CR-GAN), which combine convolutional layers for local pattern extraction with recurrent layers for temporal coherence, have been used specifically to address C-MAPSS data scarcity by generating realistic synthetic run-to-failure sequences that capture both the non-cyclic (long-term trend) and cyclic (short-term fluctuation) components of engine degradation. CPI-GAN goes a step further by integrating physics-informed constraints directly into the generation process, meaning the generator isn't just learning statistical patterns from data but is explicitly constrained to respect known physical degradation behavior, reducing the risk of generating trajectories that are statistically plausible but physically nonsensical. WGAN-GP (Wasserstein GAN with Gradient Penalty) has emerged in comparative literature reviews as a particularly well-suited architecture for time-series generation in predictive maintenance specifically because it directly addresses one of the classic GAN failure modes described below.
The persistent challenge across all GAN variants, however, is training instability and mode collapse — a well-documented failure pattern where the generator, rather than learning to produce the full diversity of the true data distribution, collapses onto producing a narrow subset of outputs that reliably fool the discriminator without actually covering the real variety of the underlying data. For a rare-failure-mode augmentation task, mode collapse is a particularly insidious risk: since you're already working with a small number of true minority examples, a generator that collapses onto reproducing near-duplicates of just one or two of those examples can create a false impression of successful augmentation — the loss curves may look fine, but the "new" synthetic data isn't actually adding the shape diversity the whole exercise was meant to provide.
2.6 How Diffusion Models Take a Fundamentally Different Approach
Diffusion models work on a completely different principle from GANs, and understanding the mechanism explains why they've become an increasingly popular alternative for exactly the training-stability reasons described above. Rather than a single generator network trying to directly produce a realistic sample in one shot, a diffusion model is trained in two conceptual stages: a forward process that gradually adds random noise to real training examples over many small steps until the data becomes indistinguishable from pure noise, and a reverse process — the part that's actually learned — where a neural network is trained to reverse this process step by step, gradually removing noise from a random starting point until a realistic sample emerges.
This iterative, step-by-step denoising formulation gives diffusion models several properties that matter directly for rare-failure-mode augmentation. Multiple comparative studies converge on the same core finding: diffusion models exhibit substantially more stable training than GANs, because there's no adversarial min-max game between competing networks to balance — the training objective is a comparatively well-behaved denoising loss rather than a fragile equilibrium between generator and discriminator. They also tend to show better mode coverage — meaning they're less prone to the mode-collapse problem described above, since the gradual denoising process is inherently less likely to converge onto reproducing only a narrow subset of the training distribution than an adversarial generator is.
The tradeoffs are real, though, and worth stating plainly rather than presenting diffusion models as a strict upgrade: diffusion models are markedly more computationally expensive to train and to sample from, since generating a single synthetic sample requires running the full iterative denoising process rather than a single forward pass through a generator network — one direct architectural comparison found diffusion training took roughly ten times longer per iteration than GAN training in a controlled test. Diffusion models also exhibit what recent time-series-specific research describes as a smoothing bias — a tendency to over-regularize outputs and suppress some of the sharper, more volatile local variability that a real degradation signal might contain, particularly on short or noisy sequences, which is a genuine concern for a use case where the whole point is capturing the sharp, sudden character of catastrophic failure trajectories rather than smoothing them into something more generic-looking.
| Dimension | GANs | Diffusion Models |
|---|---|---|
| Core mechanism | Adversarial generator vs. discriminator competition | Iterative forward-noising / reverse-denoising process |
| Training stability | Prone to instability and mode collapse | Generally more stable, smoother convergence |
| Mode coverage (diversity) | Weaker — mode collapse risk directly undermines rare-case diversity | Stronger — better coverage of the true data distribution |
| Training/sampling cost | Faster per iteration, fewer resources | Substantially more compute-intensive (roughly an order of magnitude slower per iteration in controlled comparisons) |
| Known failure mode for this use case | Mode collapse — synthetic "diversity" that's actually near-duplication | Smoothing bias — may under-represent sharp, volatile failure signatures |
| Architecture maturity for time series | Well-established (TimeGAN and purpose-built variants like CR-GAN, CPI-GAN, WGAN-GP) | Newer but rapidly maturing (TransFusion and other transformer-diffusion hybrids extending usable sequence length) |
2.7 Closing the Loop: How You Actually Know the Synthetic Data Helped
Generating synthetic failure trajectories is only half the exercise — the methodologically rigorous second half, and the part that's easiest to skip in a rushed project, is proving the augmentation actually improved the downstream RUL model rather than just producing plausible-looking synthetic charts. The standard evaluation protocol, consistent with how this is framed across recent predictive-maintenance literature, is a controlled before/after comparison: train a baseline RUL model on the original, imbalanced dataset; separately train an otherwise-identical model on the original dataset augmented with generated synthetic severe-failure trajectories; and compare their performance specifically on a held-out set of real severe-failure cases — not on the synthetic data itself, which would be circular, and not only on aggregate metrics across the whole test set, which can mask exactly the rare-case improvement (or lack of it) that the entire exercise is meant to produce.
This is precisely why a rigorous project design (and the "before/after" framing of this series' own FailureGen project) treats the comparison as the actual deliverable, not the generative model itself. A generative model that produces visually convincing synthetic degradation curves but doesn't measurably improve RMSE, and especially doesn't measurably improve the PHM08 asymmetric score (see our RUL 101 primer) specifically on the rare severe-trajectory subset of the test data, hasn't actually solved the problem this article opened with — it's produced an aesthetically satisfying but operationally unproven artifact. The single most important discipline in this entire workflow is resisting the temptation to declare success based on how realistic the synthetic data looks, and insisting instead on whether it measurably changes what the downstream model gets right.
2.8 Measuring Imbalance Correctly: Why Aggregate Regression Metrics Hide the Problem
Section 2.7 mentioned evaluating the rare-case subset separately, but it's worth explaining precisely why aggregate metrics are so good at hiding this problem, because the mechanism is a simple arithmetic fact that's easy to lose sight of in practice. If severe-failure trajectories make up, say, three percent of a test set, then a model can be dramatically wrong on every single one of those cases and still see its overall RMSE barely move — the other ninety-seven percent of well-predicted, gradual-wear cases mathematically dominate the average. This is the exact same arithmetic that makes accuracy a famously misleading metric in imbalanced classification (a model that always predicts "no fraud" can still be 99.9% accurate on a fraud dataset), just expressed in regression terms instead of classification terms.
The practical fix mirrors the classification world's well-established response to this problem: report metrics stratified by trajectory type, not just in aggregate. A rigorous evaluation reports RMSE and PHM08 score separately for gradual-wear trajectories and severe/rapid trajectories, rather than a single blended number, precisely so that an improvement — or a regression — in the rare-case subset can't hide inside a large, unaffected majority-case average. Some published approaches go further and report a precision/recall-style framing even for what's nominally a regression problem, by defining a "safety-critical miss" as any case where the predicted RUL exceeds the true RUL by more than some operationally meaningful threshold, then tracking how often that specific, high-consequence error type occurs on the rare-trajectory subset before and after augmentation — a framing that maps much more directly onto real maintenance-scheduling risk than RMSE alone ever could.
2.9 This Problem Isn't Unique to Jet Engines — And That's Useful
It's worth briefly zooming out, because the rare-failure-mode problem described throughout this piece isn't a jet-engine-specific quirk — it shows up in essentially identical form anywhere physical systems are engineered for reliability, and the cross-domain research is directly useful to borrow from. Railway track defect diagnosis faces the same structural problem for the same underlying reason: vehicle-based inertial monitoring systems generate enormous volumes of "normal track" data and comparatively few examples of genuine defects, precisely because well-maintained rail infrastructure is designed to rarely develop serious defects, and researchers in that domain have converged on GAN-based time-series augmentation as a direct response, for essentially the same reasons discussed in Section 2.5. A recent systematic review covering eighty-six peer-reviewed studies on synthetic data in industrial predictive maintenance since 2020 found that balancing datasets through augmentation and oversampling has proven broadly effective specifically for increasing representation of the minority failure classes across a wide range of heavy-machinery and industrial-process applications — not just aerospace.
The practical value of this cross-domain pattern is that techniques maturing faster in one industrial domain — a physics-informed constraint architecture proven out in hydrogen combustion engine testing, for instance, or a multi-generator failure-type-aware architecture validated on general industrial equipment data — are frequently transferable to jet engine RUL work with comparatively modest adaptation, because the underlying statistical structure of the problem (abundant normal-operation data, structurally rare and shape-diverse failure data) is the same regardless of which physical system is generating the sensor readings. A team working specifically on aerospace predictive maintenance doesn't need to solve this problem from scratch — it's one of the more actively cross-pollinated subfields in applied industrial machine learning right now.
3. Worked Example / Analogy
Think of this the way a flight-simulator training program treats rare emergencies. A pilot in training will fly thousands of routine, unremarkable simulated flights — normal takeoffs, normal cruise, normal landings — because that's what real flying overwhelmingly consists of, and the simulator has abundant data on what "normal" looks like. But a training program that only ever exposed pilots to routine flights would leave them dangerously unprepared for the rare engine-out scenario, the rare severe-weather diversion, the rare instrument failure — precisely the events that matter most for safety and that real flight logs, by design, contain almost none of, because pilots and aircraft are trained and engineered specifically to avoid them.
The simulator's answer isn't to wait around hoping enough real engine-outs eventually accumulate in the training data — it's to deliberately construct realistic emergency scenarios: not random noise bolted onto a normal flight, but physically coherent, expert-informed reconstructions of what an engine-out actually looks like moment to moment, built from aerodynamic and mechanical first principles even though very few real recorded instances exist to copy directly. Generative synthetic data for rare failure modes is doing exactly this for a maintenance model: constructing physically plausible examples of the trajectory shape it's never had enough real exposure to, specifically so the model doesn't have to learn what a catastrophic failure looks like for the first time when a real one is actually unfolding.
4. Application to Defense & Aerospace
For a Defense & Aerospace AI Center of Excellence, this problem is not an academic curiosity — it sits at the center of why predictive maintenance programs succeed or fail in exactly the use cases they're built for. A fleet-sustainment RUL model that performs excellently on aggregate benchmark metrics but has never genuinely learned the shape of a rapid-onset, catastrophic degradation trajectory is a model that looks production-ready right up until the specific moment it matters most, which is precisely the "confidently wrong" failure pattern described in Section 2.3. Military platforms compound this risk further: mission profiles are often more varied and more operationally stressful than commercial aviation's comparatively narrow, well-characterized flight envelopes, meaning the population of genuinely rare, severe-degradation events a defense fleet might encounter is both harder to characterize from historical data and more consequential to miss.
The practical implication for anyone building or procuring a predictive-maintenance capability in this space is that the toolkit comparison in Section 2.4 should shape acquisition and validation requirements directly: a vendor or internal team claiming a "predictive maintenance AI" capability should be able to show, specifically, how rare-failure-mode representation was addressed — whether through cost-sensitive learning, SMOTE-style interpolation, or genuine generative augmentation — and should be required to demonstrate the before/after evaluation discipline from Section 2.7 on held-out rare cases specifically, not just aggregate accuracy across a benchmark dominated by routine wear patterns. A model's performance on the easy, abundant majority of the data reveals almost nothing about whether it will behave safely on the rare case a maintenance program actually exists to catch.
5. Common Pitfalls in Synthetic Failure-Mode Augmentation
Building on the toolkit comparison above, a few specific mistakes recur often enough in published and applied work on this exact problem to warrant calling out directly:
| Pitfall | Why It Happens | Consequence |
|---|---|---|
| Evaluating synthetic data realism visually instead of via downstream task performance | Generated trajectories that "look right" on a plotted chart feel like sufficient validation | May mask mode collapse or physically implausible artifacts that don't show up in a casual visual check |
| Training the generative model and the RUL model on overlapping data splits | Convenient to reuse the same train/test split across both stages | Leaks test-set information through the generative model, producing an overoptimistic before/after comparison |
| Treating all "severe" trajectories as one homogeneous minority class | Simpler to implement a single generator for "the rare class" | Different failure mechanisms (bearing seizure vs. blade liberation vs. rapid seal failure) have genuinely different trajectory shapes; a single generator can average across them into something that resembles none of them precisely — the motivation behind failure-type-aware, multi-generator architectures |
| Ignoring physical plausibility constraints | Pure statistical pattern-matching is simpler to implement than physics-informed constraints | Risk of generating trajectories that are statistically smooth but violate known engine physics, as physics-informed approaches like CPI-GAN are specifically designed to prevent |
| Reporting only aggregate test-set metrics after augmentation | Aggregate RMSE is the most familiar, easiest number to report | Aggregate improvement can mask a lack of improvement — or even degradation — specifically on the rare cases the augmentation was meant to help with |
6. Quick-Reference Glossary
| Term | Meaning |
|---|---|
| Class imbalance | A dataset condition where one outcome (here, severe/rare failure trajectories) is dramatically underrepresented relative to another (routine wear) |
| Trajectory shape imbalance | The specific, sequence-level version of class imbalance where rare failure modes differ not just in count but in the pattern of degradation over time |
| Mode collapse | A GAN failure mode where the generator produces a narrow, repetitive subset of outputs rather than the full diversity of the real data distribution |
| SMOTE | Synthetic Minority Oversampling Technique — generates new minority-class points via interpolation between existing examples |
| GAN | Generative Adversarial Network — a generator and discriminator trained in competition to produce realistic synthetic data |
| Diffusion model | A generative model trained to reverse a gradual noise-corruption process, producing new samples via iterative denoising |
| CR-GAN / CPI-GAN / WGAN-GP | Purpose-built GAN variants for time-series/degradation-trajectory generation, incorporating recurrent structure, physics-informed constraints, or improved training stability respectively |
| Cost-sensitive learning | Modifying a model's loss function to penalize errors on rare/high-consequence cases more heavily than common ones |
| Stratified evaluation | Reporting model performance separately for different data subgroups (e.g., rare vs. common trajectory types) rather than only in aggregate |
7. Further Reading
This piece builds directly on the extrapolation and data-scarcity challenges raised in Section 2.7 of our RUL 101 primer, and sets up the practical build covered in our FailureGen project blog, which walks through implementing exactly this before/after generative-augmentation methodology on the C-MAPSS dataset. For the architectural detail this piece only summarized, see our companion deep dive, "GANs vs. Diffusion Models for Time-Series Data Augmentation: A Practical Comparison."