What the Trigger Doesn't Capture: Selection Bias and the Distorted Catalog of Rare Faults
Every triggered data acquisition system embodies a quiet assumption: that the events worth capturing are the events that exceed the threshold. It is a reasonable assumption in many contexts. It is a dangerous one in condition monitoring, fault detection, and any application where the population of rare events — not just the most energetic examples — determines the accuracy of a diagnostic or predictive model.
The statistical problem at the heart of event-triggered capture has a name in the broader scientific literature: selection bias. In time-domain signal acquisition, it manifests as a systematic distortion of the fault record that engineers use to characterize system behavior, calibrate detection algorithms, and build the empirical foundation for failure prediction. Understanding its mechanics is a prerequisite for building monitoring systems that deliver accurate insight rather than a curated illusion of system health.
The Threshold as a Filter
A trigger threshold is, by definition, a boundary. Events whose signal amplitude, rate of change, or spectral energy exceed the threshold enter the captured record. Events that fall below it do not. This is the intended behavior — the entire purpose of triggered acquisition is to focus storage and processing resources on signal activity deemed significant.
The problem arises when the threshold is not a neutral boundary between signal and noise, but an active shaper of the event population that engineers subsequently analyze. In mechanical systems, early-stage faults frequently manifest as low-amplitude, high-frequency perturbations — bearing defect frequencies, gear mesh anomalies, and early-stage fatigue cracking all produce signatures that grow in amplitude as damage progresses. A trigger threshold calibrated to avoid false alarms from background vibration will systematically exclude the earliest, most diagnostically valuable instances of a developing fault.
What remains in the captured record is a collection of mature fault signatures — events that were already energetic enough to clear the threshold. The engineer examining this record sees a population of faults that appear to emerge suddenly, without precursor activity. The precursors were there. The trigger filtered them out.
How Threshold Artifacts Enter the Analysis
The selection bias introduced by triggered capture does not merely reduce the number of captured events. It actively distorts the morphology of the event population in ways that can mislead quantitative analysis.
Consider a simple threshold trigger on signal amplitude. Near the threshold boundary, the probability of capture is not a step function — it is a gradient. A transient whose peak amplitude is slightly above the threshold will be captured on some occurrences and missed on others, depending on the precise timing of the threshold crossing relative to the acquisition window, noise superimposed on the signal, and the latency of the trigger logic itself. The result is a captured population that is systematically biased toward events with peak amplitudes well above the threshold, with near-threshold events underrepresented in proportion to their actual frequency of occurrence.
This effect — sometimes called trigger bias or threshold bias in the statistical literature — means that the amplitude distribution of captured events is not an accurate representation of the true amplitude distribution of the underlying physical phenomenon. Statistical models built on this biased sample will overestimate the typical amplitude of fault events, underestimate their frequency at low amplitudes, and produce detection thresholds that are systematically too high for early fault identification.
The Rearm Interval Problem
A related but distinct source of bias arises from the rearm interval — the dead time following a triggered capture during which the acquisition system is resetting and is unable to respond to a new trigger. In systems where faults occur in bursts — multiple mechanical impacts in rapid succession, for example, or a sequence of voltage transients following a switching event — the rearm interval will suppress all but the first event in each cluster.
The captured record will then reflect only the initiating event of each burst, systematically excluding the subsequent events that may carry the most diagnostic information about the fault's character. An engineer analyzing this record might conclude that the fault produces isolated, discrete events when the physical reality is a clustered, structured sequence. Maintenance decisions based on this conclusion — interval-based replacement, for instance — will be calibrated to a fault signature that does not accurately represent the underlying failure mode.
Reducing the rearm interval addresses part of the problem but introduces competing concerns around storage bandwidth, processing overhead, and the risk of filling acquisition memory with redundant near-threshold noise events. The engineering tradeoff is real and deserves explicit acknowledgment rather than resolution by default.
Implications for Machine Learning-Based Fault Detection
The selection bias problem takes on additional significance in the context of data-driven fault detection. Machine learning models trained on triggered capture data inherit the biases of the trigger configuration. A neural network or gradient-boosted classifier trained on a dataset where low-amplitude precursor events are systematically absent will not learn to recognize those precursors. It will learn to recognize the mature, high-amplitude fault signatures that dominate the training set.
This has a specific and consequential implication for deployment: such a model will not provide early warning of developing faults. It will provide confirmation of faults that are already well-developed — a capability that is useful for classification but provides little lead time for intervention. Organizations that deploy these systems expecting early fault detection are likely to be disappointed when the first alarm arrives shortly before the failure event rather than days or weeks in advance.
The problem is compounded by the fact that the training data looks comprehensive. The event catalog may contain thousands of labeled fault instances spanning multiple fault types and severity levels. The apparent richness of the dataset obscures the systematic absence of the early-stage events that would make the model genuinely predictive.
Complementary Capture Strategies
Addressing trigger selection bias requires supplementing event-triggered capture with acquisition strategies that are not conditioned on the signal exceeding a threshold.
Continuous background recording, where the acquisition system maintains a rolling buffer of pre-trigger data and retains segments based on post-hoc analysis rather than real-time threshold crossing, provides access to the sub-threshold signal environment surrounding each captured event. Examining the pre-trigger record often reveals low-amplitude precursor activity that threshold-based capture would have excluded entirely.
Periodic unconditional capture — acquiring fixed-duration records at regular intervals regardless of signal amplitude — provides an unbiased sample of the signal environment that can be used to characterize the true amplitude distribution of transient activity and calibrate the relationship between threshold-captured events and the broader population from which they are drawn.
Statistical debiasing techniques, borrowed from survey methodology and observational epidemiology, offer a post-processing path to correcting for known threshold effects in existing datasets. These approaches require explicit modeling of the capture probability as a function of event amplitude, but they can substantially improve the accuracy of amplitude distribution estimates and the reliability of models trained on biased samples.
Designing With Bias in Mind
The trigger threshold will always introduce some degree of selection. The goal is not to eliminate triggered capture — it remains an indispensable tool for managing the data volumes generated by high-speed acquisition systems. The goal is to design monitoring architectures with explicit awareness of what the trigger excludes, and to supplement threshold-based capture with strategies that illuminate the sub-threshold population.
Engineers who treat the triggered event catalog as a complete and unbiased record of system behavior are working with a fundamentally incomplete picture. The events that never cleared the threshold are not absent from the system's history — they are absent only from the record. That distinction matters enormously when the catalog becomes the empirical foundation for fault models, maintenance schedules, and safety assessments.
