When ML Meets Fatigue Data: Useful, But Only With Guardrails

Last quarter we tried ML to flag outliers in shaker and flight strain data before fatigue analysis. Unsupervised models spotted "interesting" runs, but most were just sensor drift, bad zeroing, or fixture chatter. Helpful to catch housekeeping issues, but it didn’t replace time in the plots.

Where it did help: automated rainflow and PSD feature extraction tied to test logs, and a simple classifier to detect grip slip and thermal drift. Where it struggled: extrapolating to new configs or temp ranges, and giving any uncertainty I’d trust near margins. A hybrid approach worked better: physics for the main load-to-damage path, ML on the residuals and metadata.

My takeaway: if the model can’t explain itself in terms of modes, cycles, or crack growth, it’s a dashboard light, not a gauge. I’m curious how others are handling dataset shift between ground and flight, and how you validate ML outputs against allowables and scatter factors. What guardrails are you using before letting ML influence a fatigue decision?