Team Name: BTT_Heatwave
\nTeam Members: Rishik Yesgari and Ayooluwa Wojuade
\nPrivate Leaderboard Score: 0.97250
\nPrivate Leaderboard Place: 3rd Place
This competition focused on predicting when a wildfire may threaten an evacuation zone. For each fire, we estimated the probability of a threat within 12, 24, 48, and 72 hours using only the first five hours of fire perimeter information.
\nThis was a right-censored survival prediction problem. Some fires reached an evacuation zone, while others did not during the observation window. For censored fires, we only know that a hit was not observed during the available time. Because of this, the model had to handle event timing and censoring while still producing calibrated probabilities for fixed horizons.
\nOur approach was to build a horizon-specific ensemble. We engineered features for distance, movement, fire growth, alignment, and estimated time to reach an evacuation zone. Then we trained multiple model families, combined their outputs, and applied post-processing so the final probabilities stayed valid and followed the required cumulative order over time.
\nThe main idea was to avoid treating the task as one single classification problem. Since the competition required probabilities at four horizons, we built the solution around those horizons directly. A fire that may threaten an evacuation zone within 12 hours can behave differently from one that becomes risky closer to 48 or 72 hours.
\nWe also handled censoring carefully. For each horizon, fires censored before that horizon were not treated as clear negatives because their true outcome was unknown. We built horizon-specific labels only from examples where the outcome was known and used censor-aware weighting to reduce bias.
\nThe final solution combined two views of the problem. Horizon-specific models helped produce calibrated probabilities for fixed time windows, while survival-risk models helped capture the overall urgency ranking of fires. This matched the competition metric, which rewarded both ranking and probability calibration.
\nFeature engineering was important because the original columns did not fully capture the relationship between the fire, its movement, and the nearest evacuation zone. We created features that described closeness, movement, growth, direction, and estimated arrival time.
\nThe engineered features included distance transformations such as distance in kilometers, log distance, square-root distance, inverse distance, and distance-zone indicators. We also added distance trend features such as normalized distance change, normalized distance slope, normalized distance variation, distance acceleration, and a distance-trend reliability flag.
\nWe created movement and ETA-based features using closing speed, radial growth rate, effective closing speed, and along-track speed. From these, we estimated time-to-arrival values and horizon-specific ETA indicators for 12, 24, 48, and 72 hours. We also added fire size and growth features such as estimated fire radius, radius-to-distance ratio, area-to-distance ratio, growth-to-distance ratio, and radial-growth-to-distance ratio.
\nFinally, we added directional and temporal features, including alignment with the evacuation zone, alignment and closing-speed interactions, threat pressure, cross-track movement, bearing strength, movement flags, perimeter density, short-window indicators, low temporal resolution indicators, and cyclical encodings for hour, day of week, and month.
\nOur final approach was a seed-bagged, horizon-specific ensemble with survival-risk blending and monotonic post-processing. Since the required outputs were cumulative probabilities at 12, 24, 48, and 72 hours, we trained the model around those time horizons instead of using one general prediction.
\nWe used LightGBM, XGBoost, and CatBoost as horizon-specific tree-based models. For 12 and 24 hours, these models predicted whether a fire would threaten an evacuation zone by that time. For 48 hours, we used a tail-modeling approach to estimate the additional probability of a threat between 24 and 48 hours. The 72-hour probability was extended from the 48-hour probability using the late-event rate from the training data.
\nBecause the dataset included censored examples, we used censor-aware training and inverse probability of censoring weighting. This helped avoid treating unknown outcomes as negatives and made the usable examples better represent the full training distribution.
\nWe also trained XGBoost Cox and XGBoost AFT models to capture the time-to-event structure. Their outputs were converted into horizon probabilities using isotonic calibration and combined into one survival-risk component. The final prediction blended four components: LightGBM, XGBoost, CatBoost, and the Cox/AFT survival-risk component. Multiple random seeds were averaged for the tree-based models to improve stability.
\nAfter blending, we applied post-processing. The 12-hour probability received an extra calibration adjustment because the earliest horizon was the most sensitive. We then applied a final consistency check so the cumulative probabilities followed the expected time ordering across the four horizons.
\nWe used a local version of the competition metric to compare modeling ideas. The metric combined C-index and weighted Brier score. C-index measured how well the model ranked fires by urgency, while the weighted Brier score measured probability accuracy at the 24-hour, 48-hour, and 72-hour horizons.
\nFor the Brier score, censoring was handled by horizon. Fires that hit before the horizon were labeled as 1, fires still observed past the horizon without hitting were labeled as 0, and fires censored before the horizon were excluded because their true outcome was unknown.
\nSince the final score placed more weight on probability calibration than ranking, we focused on stable and well-calibrated probabilities. This is why horizon-specific models, censor-aware labels, calibration, and post-processing were important.
\nThe final submission can be reproduced using the terminal-executable script src/Submission/submit.py. This script loads the data, applies the same feature engineering used in the final solution, trains the model components, loads the saved blending settings from src/models/stack_bundle.joblib, blends the model outputs, and creates the final submission file.
The generated submission is saved to:
\nsrc/Submission/submission.csv
The original notebook workflow is also included as src/Submission/submit.ipynb for review. The notebook shows the same final modeling workflow in notebook form, while the Python script provides a cleaner command-line version for reproducibility.
To verify reproducibility, we included check_reproducibility.py in the src/ReproducibilityCheck folder. This script regenerates the submission and saves it as:
src/ReproducibilityCheck/generated_submission.csv
It then compares the regenerated file with the Kaggle-downloaded submission file:
\nsrc/ReproducibilityCheck/kaggle_submission.csv
The reproducibility check verifies that the event IDs match and that the prediction values match within a small floating-point tolerance. The check saves and reloads the generated predictions before comparison to avoid confusion from tiny in-memory floating-point formatting differences.
\nThe full final pipeline took 99.40 seconds, or about 1 minute and 39 seconds, in our tested environment.
\nThe code for our final solution is available here: GitHub Repository.
\nThe repository includes the terminal-executable final submission script, the original final submission notebook, the reproducibility check script, the reproducibility check notebook, and the saved blending settings needed to reproduce the submitted file.
\nThe main files are:
\nsrc/Submission/submit.py: terminal-executable script that reproduces the final submission.src/Submission/submit.ipynb: original notebook version of the final workflow.src/ReproducibilityCheck/check_reproducibility.py: script that regenerates the submission and compares it with the Kaggle-downloaded submission.src/ReproducibilityCheck/reproducibilityCheck.ipynb: notebook version of the reproducibility check.src/models/stack_bundle.joblib: saved blending and post-processing settings used by the final workflow.The final solution can be run from the project root using:
\npython -m src.Submission.submit
or, using uv:
\nuv run python -m src.Submission.submit
The reproducibility check can be run using:
\npython -m src.ReproducibilityCheck.check_reproducibility
or, using uv:
\nuv run python -m src.ReproducibilityCheck.check_reproducibility
The most important part of our solution was building around the four prediction horizons instead of using one general risk prediction. This made the model outputs more directly connected to the required submission probabilities.
\nFeature engineering also made a big difference. Distance, movement, fire growth, alignment, and estimated time-to-arrival features gave the models clearer signals about whether a fire was likely to threaten an evacuation zone soon.
\nThe ensemble approach helped make predictions more stable. Averaging multiple seeds reduced variance, and combining tree-based models with Cox and AFT survival-risk models helped balance probability calibration with urgency ranking.
\nBTT_Heatwave consisted of Rishik Yesgari and Ayooluwa Wojuade. We met through the Break Through Tech AI program.
\nThe final solution used the competition-provided data and the following software libraries and documentation:
\nTeam Name: BTT_Heatwave
\nTeam Members: Rishik Yesgari and Ayooluwa Wojuade
\nPrivate Leaderboard Score: 0.97250
\nPrivate Leaderboard Place: 3rd Place
This competition focused on predicting when a wildfire may threaten an evacuation zone. For each fire, we estimated the probability of a threat within 12, 24, 48, and 72 hours using only the first five hours of fire perimeter information.
\nThis was a right-censored survival prediction problem. Some fires reached an evacuation zone, while others did not during the observation window. For censored fires, we only know that a hit was not observed during the available time. Because of this, the model had to handle event timing and censoring while still producing calibrated probabilities for fixed horizons.
\nOur approach was to build a horizon-specific ensemble. We engineered features for distance, movement, fire growth, alignment, and estimated time to reach an evacuation zone. Then we trained multiple model families, combined their outputs, and applied post-processing so the final probabilities stayed valid and followed the required cumulative order over time.
\nThe main idea was to avoid treating the task as one single classification problem. Since the competition required probabilities at four horizons, we built the solution around those horizons directly. A fire that may threaten an evacuation zone within 12 hours can behave differently from one that becomes risky closer to 48 or 72 hours.
\nWe also handled censoring carefully. For each horizon, fires censored before that horizon were not treated as clear negatives because their true outcome was unknown. We built horizon-specific labels only from examples where the outcome was known and used censor-aware weighting to reduce bias.
\nThe final solution combined two views of the problem. Horizon-specific models helped produce calibrated probabilities for fixed time windows, while survival-risk models helped capture the overall urgency ranking of fires. This matched the competition metric, which rewarded both ranking and probability calibration.
\nFeature engineering was important because the original columns did not fully capture the relationship between the fire, its movement, and the nearest evacuation zone. We created features that described closeness, movement, growth, direction, and estimated arrival time.
\nThe engineered features included distance transformations such as distance in kilometers, log distance, square-root distance, inverse distance, and distance-zone indicators. We also added distance trend features such as normalized distance change, normalized distance slope, normalized distance variation, distance acceleration, and a distance-trend reliability flag.
\nWe created movement and ETA-based features using closing speed, radial growth rate, effective closing speed, and along-track speed. From these, we estimated time-to-arrival values and horizon-specific ETA indicators for 12, 24, 48, and 72 hours. We also added fire size and growth features such as estimated fire radius, radius-to-distance ratio, area-to-distance ratio, growth-to-distance ratio, and radial-growth-to-distance ratio.
\nFinally, we added directional and temporal features, including alignment with the evacuation zone, alignment and closing-speed interactions, threat pressure, cross-track movement, bearing strength, movement flags, perimeter density, short-window indicators, low temporal resolution indicators, and cyclical encodings for hour, day of week, and month.
\nOur final approach was a seed-bagged, horizon-specific ensemble with survival-risk blending and monotonic post-processing. Since the required outputs were cumulative probabilities at 12, 24, 48, and 72 hours, we trained the model around those time horizons instead of using one general prediction.
\nWe used LightGBM, XGBoost, and CatBoost as horizon-specific tree-based models. For 12 and 24 hours, these models predicted whether a fire would threaten an evacuation zone by that time. For 48 hours, we used a tail-modeling approach to estimate the additional probability of a threat between 24 and 48 hours. The 72-hour probability was extended from the 48-hour probability using the late-event rate from the training data.
\nBecause the dataset included censored examples, we used censor-aware training and inverse probability of censoring weighting. This helped avoid treating unknown outcomes as negatives and made the usable examples better represent the full training distribution.
\nWe also trained XGBoost Cox and XGBoost AFT models to capture the time-to-event structure. Their outputs were converted into horizon probabilities using isotonic calibration and combined into one survival-risk component. The final prediction blended four components: LightGBM, XGBoost, CatBoost, and the Cox/AFT survival-risk component. Multiple random seeds were averaged for the tree-based models to improve stability.
\nAfter blending, we applied post-processing. The 12-hour probability received an extra calibration adjustment because the earliest horizon was the most sensitive. We then applied a final consistency check so the cumulative probabilities followed the expected time ordering across the four horizons.
\nWe used a local version of the competition metric to compare modeling ideas. The metric combined C-index and weighted Brier score. C-index measured how well the model ranked fires by urgency, while the weighted Brier score measured probability accuracy at the 24-hour, 48-hour, and 72-hour horizons.
\nFor the Brier score, censoring was handled by horizon. Fires that hit before the horizon were labeled as 1, fires still observed past the horizon without hitting were labeled as 0, and fires censored before the horizon were excluded because their true outcome was unknown.
\nSince the final score placed more weight on probability calibration than ranking, we focused on stable and well-calibrated probabilities. This is why horizon-specific models, censor-aware labels, calibration, and post-processing were important.
\nThe final submission can be reproduced using the terminal-executable script src/Submission/submit.py. This script loads the data, applies the same feature engineering used in the final solution, trains the model components, loads the saved blending settings from src/models/stack_bundle.joblib, blends the model outputs, and creates the final submission file.
The generated submission is saved to:
\nsrc/Submission/submission.csv
The original notebook workflow is also included as src/Submission/submit.ipynb for review. The notebook shows the same final modeling workflow in notebook form, while the Python script provides a cleaner command-line version for reproducibility.
To verify reproducibility, we included check_reproducibility.py in the src/ReproducibilityCheck folder. This script regenerates the submission and saves it as:
src/ReproducibilityCheck/generated_submission.csv
It then compares the regenerated file with the Kaggle-downloaded submission file:
\nsrc/ReproducibilityCheck/kaggle_submission.csv
The reproducibility check verifies that the event IDs match and that the prediction values match within a small floating-point tolerance. The check saves and reloads the generated predictions before comparison to avoid confusion from tiny in-memory floating-point formatting differences.
\nThe full final pipeline took 99.40 seconds, or about 1 minute and 39 seconds, in our tested environment.
\nThe code for our final solution is available here: GitHub Repository.
\nThe repository includes the terminal-executable final submission script, the original final submission notebook, the reproducibility check script, the reproducibility check notebook, and the saved blending settings needed to reproduce the submitted file.
\nThe main files are:
\nsrc/Submission/submit.py: terminal-executable script that reproduces the final submission.src/Submission/submit.ipynb: original notebook version of the final workflow.src/ReproducibilityCheck/check_reproducibility.py: script that regenerates the submission and compares it with the Kaggle-downloaded submission.src/ReproducibilityCheck/reproducibilityCheck.ipynb: notebook version of the reproducibility check.src/models/stack_bundle.joblib: saved blending and post-processing settings used by the final workflow.The final solution can be run from the project root using:
\npython -m src.Submission.submit
or, using uv:
\nuv run python -m src.Submission.submit
The reproducibility check can be run using:
\npython -m src.ReproducibilityCheck.check_reproducibility
or, using uv:
\nuv run python -m src.ReproducibilityCheck.check_reproducibility
The most important part of our solution was building around the four prediction horizons instead of using one general risk prediction. This made the model outputs more directly connected to the required submission probabilities.
\nFeature engineering also made a big difference. Distance, movement, fire growth, alignment, and estimated time-to-arrival features gave the models clearer signals about whether a fire was likely to threaten an evacuation zone soon.
\nThe ensemble approach helped make predictions more stable. Averaging multiple seeds reduced variance, and combining tree-based models with Cox and AFT survival-risk models helped balance probability calibration with urgency ranking.
\nBTT_Heatwave consisted of Rishik Yesgari and Ayooluwa Wojuade. We met through the Break Through Tech AI program.
\nThe final solution used the competition-provided data and the following software libraries and documentation:
\n