Reliability Event Detection Case Study

Back to all projects

Overview

This case study analyzes reliability across a distributed service network using operational attempt logs and equipment and location metadata. Because the data contains no labeled failures, the central problem is not conventional supervised classification: the analysis must infer when a unit behaves abnormally, determine whether several abnormalities share a plausible cause, and preserve the distinction between evidence and attribution.

Client identity, the application domain, raw data, proprietary identifiers, and business conclusions are intentionally omitted because the work is not authorized for public disclosure.

Analytical approach

I structured the notebook as a hierarchical detection system rather than a single global anomaly score.

Independent impairment detection

Each unit is first evaluated against two references:

• its own historical behavior on the same day of the week;
• other units at the same location on the same day, using leave-one-out peer statistics.

The detector evaluates operational stage errors and unusually low activity. Alerts require both statistical evidence and a minimum practical deterioration, reducing false positives caused by small denominators or large datasets where negligible changes can appear statistically significant.

Systemic-event detection

Independently impaired units are then tested for concentration around shared characteristics. The analysis forms separate hypotheses for equipment-reader patterns, firmware patterns, and location-wide outages. Attribution is ordered so that overlapping evidence is not repeatedly counted under several explanations, while unexplained unit-level impairment remains visible instead of being forced into a systemic category.

Reporting and diagnostics

The final orchestration function returns one row per day with impaired-unit counts, systemic-event status, affected-unit identifiers, candidate correlates, and aggregate reliability and demand measures. Event-level diagnostic records preserve the locations, units, operational impact, and metrics behind each daily summary.

The notebook also includes:

• raw and weekday-corrected activity heatmaps;
• diagnostic flag and factor-comparison views;
• an interactive geographic dashboard with date controls;
• event ranking by observed operational impact;
• location and unit-level drill-down;
• explicit threshold documentation and worked statistical examples.

Engineering considerations

The implementation emphasizes reproducibility and auditability. Detection stages use explicit naming conventions for independent and systemic signals, preserve intermediate metrics, document threshold behavior, and expose a compact public function rather than requiring reviewers to reconstruct the notebook's internal execution order.

The project also records the use of generative-AI development tools while retaining human responsibility for the analytical design, implementation direction, testing, interpretation, and disclosure boundaries.

Disclosure boundary

The linked repository is a temporary private reference and may not be accessible without authorization. This page describes the general analytical and engineering work only; it intentionally excludes the client, application domain, data files, proprietary results, and conclusions that could identify the engagement.

Resources

Private project repository