Inspiration
When an outage is reported, a first crew is dispatched before anyone has seen the damage. In the hackathon data, 13% of outages with a crew on site needed a second trip by a different crew. That means an extra truck roll, and customers wait a median 2.2 more hours for the second crew. We wanted to warn dispatchers at the one moment they can still act: first dispatch.
What it does
FirstTrip scores every outage at first dispatch. It estimates the chance that an outage will need a second trip by a different crew, with calibrated probabilities so that a 30% risk means approximately 30 out of 100 similar outages will need one. It also predicts which crew type that second trip would most likely require. A cost-based rule converts the risk into three action bands: High means sending the suggested crew along, Medium means putting that crew on standby, and Low means sending the usual first crew. CenterPoint can adjust the cost ratio, and at a 3:1 ratio, the High threshold is 25%. Each score also includes the top four factors behind the prediction. The dispatcher interface replays real days from 2033, showing outages as they arrive in a queue with their risk scores, explanations, and suggested crews. Dispatchers can then reveal what actually happened.
How we built it
The dataset does not contain a direct second-trip label, so we constructed one from historical crew trip records. An outage counts as requiring a second trip when the first crew that actually worked it referred it, left it incomplete, requested another crew, or made it safe before a different crew later restored service. This definition identified second trips in 12.95% of 549,906 outages. We found that the existing follow_up_needed flag was not a reliable substitute, since only 1.9% of those flagged cases represented real second trips. During preprocessing, we removed 26,211 duplicate trips, standardized mixed UTC and local timestamps, consolidated inconsistent category spellings and zone names, filled 2,925 missing circuit IDs using device records, and marked 10,152 equipment installation years as unknown because later replacements had overwritten their original values.
Our model uses only information available at the time of dispatch, including storm activity within the zone, equipment involved, historical second-trip rates for circuits and devices based on settled outcomes, caller-reported symptoms, outage scope, circuit characteristics, time, and geographic zone. We excluded information recorded after dispatch, the dispatcher's own crew selection, and same-day weather observations. Automated tests enforce these restrictions to prevent data leakage. We built a two-stage gradient boosting system using scikit-learn with isotonic calibration. The first stage predicts the probability of a second trip, while the second predicts the likely crew type given that a second trip occurs. Training used January 2031 through June 2032, model selection and calibration used July through December 2032, and final evaluation was performed once on 179,634 outages from 2033. The application combines a Python machine learning model, a FastAPI backend, and a React and TypeScript dispatcher interface.
Results
On the held-out 2033 test set, the riskiest 10% of outages required a second trip 29.4% of the time, approximately 2.5 times the overall rate of 11.6%. In comparison, only 3.6% of outages in the safest 10% required another trip. The model achieved an ROC-AUC of 0.687 and a PR-AUC of 0.237, compared with a random baseline of 0.116. The High risk band covered 9.9% of outages while identifying 25% of all second trips. We also demonstrated the importance of preventing data leakage: adding information recorded after dispatch increased the same model's AUC to 0.957, but this improvement was misleading because that information would not be available during real dispatch decisions. At the 25% threshold, our estimated additional crew cost was approximately $6.60 per customer-hour of outage avoided, assuming $175 for a troubleshooter roll and $450 for a specialist. CenterPoint can replace these assumptions with its actual operational costs.
Challenges we ran into
One of our biggest challenges was defining what qualifies as a second trip. We had to distinguish actual follow-up work from assists, crews that never arrived, scheduled follow-ups, and cases where the same crew returned. Another challenge was identifying hidden data leakage. For example, the device dataset represents an end-of-2033 snapshot, meaning equipment replaced during the observation period could display its newer installation year even for earlier outages. Using that value without correction would reveal future information to the model. We also had to accept the limitations of predicting an outcome that often depends on physical conditions discovered only after a crew arrives. Despite testing larger models and additional features, performance remained around 0.69 AUC.
Accomplishments that we're proud of
We developed a second-trip label that two independently implemented pipelines reproduced exactly across all 549,906 outages. We also maintained a strict chronological evaluation process, scoring the 2033 test year only once after all modeling decisions were finalized. Finally, we built a working dispatcher interface that provides actionable risk estimates, explains the factors behind each prediction, and keeps the final operational decision in the dispatcher's hands.
What we learned
We learned that a trustworthy prediction is more valuable than an artificially high performance score. Preventing data leakage is essential when building models intended for real operational decisions. We also learned that probability calibration can matter more than ranking performance when predictions directly influence cost-based dispatch rules. Most importantly, we found that the crew type ultimately needed for an outage is often determined by conditions discovered on site, which places a natural limit on what can be predicted at first dispatch.
What's next
Our next steps include giving more weight to recent historical data because the second-trip rate declined from 14.8% to 11.6% over three years, contributing to slight overestimation by the current model. We also plan to add interactive comparisons that allow dispatchers to explore how different initial crew assignments might affect outcomes. Before real-world deployment, we would work with CenterPoint to confirm which data fields are available at dispatch, determine whether weather forecasts can be incorporated, and replace our estimated crew costs with actual operational figures. Ultimately, we would like to evaluate FirstTrip through a shadow-mode pilot over one storm season, allowing the system to generate recommendations alongside real dispatch operations without affecting live decisions.
Slide deck: https://docs.google.com/presentation/d/1Y6Q-elHEJH422QD_uPqJADh9pdkKWD9b8oVC6XEah5w/edit?usp=sharing
Code: https://github.com/janny801/cnp-hackathon-2026 (private; access on request)
Additional file: https://drive.google.com/file/d/1tS2ysTwWGtnCZLMnK9CKi0hPVmxQ8zKM/view
Built With
- duckdb
- fastapi
- pandas
- python
- react
- scikit-learn
- typescript
