Rare Event Monitor¶
Software or tool — instantiates Intermittent Failure Capture
Watches for low-frequency events and preserves evidence when they occur rather than relying on continuous human attention.
A Rare Event Monitor is a tool that stands ready indefinitely, watching a signal for one specific low-frequency event, and — the instant it detects the event's signature — latches and preserves the surrounding evidence. Its defining move is to solve the attention problem: unbroken vigilance for something that almost never happens is exactly what humans are worst at and automation is best at, so the monitor becomes the tireless watcher. It is defined by detection of a rare occurrence plus preserve-on-fire — the engineering challenge is discriminating the event from ordinary variation at a very low base rate. It is not an escalation of logging verbosity, nor a rolling buffer that keeps everything.
Example¶
A power utility gets sporadic customer reports of momentary flickers on a rural distribution feeder — a fault that clears itself in a fraction of a second, perhaps twice a month, and never while a crew is on site. They install a rare event monitor on the feeder: a device that continuously watches the voltage and current waveforms for the signature of a transient fault — a sub-cycle sag beyond a threshold. It ignores normal load variation, but the instant that signature appears, it latches the high-resolution waveform for the surrounding window into non-volatile memory and flags it. Two months later, several latched captures show the transient always coincides with a particular sag shape consistent with a tree branch intermittently contacting the line in wind — caught without anyone watching the feeder around the clock.
How it works¶
- The tool continuously and cheaply watches a signal for a defined rare signature — a detector, not a general logger.
- Its discrimination is tuned to fire on the genuine event while rejecting normal variation, which at a low base rate is the hard part.
- On detection, it immediately latches and persists the surrounding evidence window to durable storage, so a once-a-month event is not lost to routine overwrite.
- It flags or notifies for follow-up, then returns to watching indefinitely.
Tuning parameters¶
- Detection sensitivity vs. specificity — more sensitive catches faint or variant events but fires on noise; at a low base rate, even a specific detector's fires are dominated by false positives.
- Signature definition — what counts as "the event." Narrow misses variant forms; broad drowns the real event in look-alikes.
- Preserved-window size — how much evidence around the detection to latch.
- Storage and retention — how long latched captures are kept before the tool reclaims space.
When it helps, and when it misleads¶
Its strength is that it removes the human-vigilance bottleneck for genuinely rare events and preserves the moment automatically, so nothing depends on someone happening to watch at the right second. Its named hazard is the base rate fallacy[n1] — when the event is rare, even a highly specific trigger yields a haul dominated by false positives, so any single detection is a lead, not a diagnosis. Its central failure mode is chasing sensitivity until the latched captures are mostly noise that buries the real event — or a signature so narrow it misses variant forms of the phenomenon. The classic misuse is trusting one latched capture as proof of the cause. The guarding discipline is to set specificity against the true base rate, treat any single detection as a lead to be confirmed rather than a diagnosis, and check that the signature actually brackets the phenomenon it claims to catch.
How it implements the components¶
Rare Event Monitor realizes the detection-and-latch side of the archetype — recognizing the rare occurrence and persisting its moment, not interpreting it afterward:
trigger_condition— the detection signature or threshold that recognizes the rare event amid normal variation; the tool's hard core.capture_window— the span of evidence latched around each detection.evidence_preservation_rule— on fire, it commits the latched window to durable storage so a low-frequency episode is not lost to routine overwrite. (This is a save-on-detection latch, distinct from a black box's hardening of a record against a destroying event.)
It does not compare the latched captures to find the common cause (recurrence_analysis) — that is post_episode_evidence_review's; and it does not route each capture into corrective action (follow_up_diagnostic_path) — that hand-off is automatic_diagnostic_capture's.
Related¶
- Instantiates: Intermittent Failure Capture — provides the always-ready watcher and preserved evidence for genuinely rare episodes.
- Sibling mechanisms: Flight Recorder · Trigger-Based Debug Trace · Incident Snapshot · Symptom Diary · Automatic Diagnostic Capture · Post-Episode Evidence Review · Black Box Log
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Rare Event Monitor operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it watches for low-frequency events and preserves evidence when they occur rather than relying on continuous human attention.
Independent corroboration: The frozen evidence defines Rare Event Monitor as 'Watches for low-frequency events and preserves evidence when they occur rather than relying on continuous human attention', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Event-triggered capture of infrequent failures is rooted in reliability engineering and condition monitoring.
Related originating lineages:
- Computer Science & Software Engineering — Event logging and observability supplied continuous software implementation.
- Statistics & Experimental Design — Rare-event detection supplied threshold and false-alarm analysis.
Review resolution: Both blind reviewers agree on engineering_design as the primary origin. Explicit reconciliation resolves reported_ambiguity, origin_mode_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=universal records later applicability separately from origin breadth.
Attribution caveat: The generic monitor spans industrial, software, and scientific instrumentation.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] The base rate fallacy is the error of judging the probability of an event from a test's accuracy while ignoring how rare the event is. For a genuinely low-frequency episode, even a highly specific trigger produces captures dominated by false positives — which is why a single detection is a lead, not a diagnosis. ↩