Inspiration

I have been learning the Python programming language, and I wanted to find a real-world application for it to actually use what I have been learning. I have always wanted to participate in a hackathon, and when I heard this challenge would use actual NASA data instead of a fake data set for participants to use, it sounded perfect for me. I am also very interested in space and planetary science, so contributing to a project related to exoplanets and not just theoretical ones was appealing to me.

What it does

Transit Triage uses data from the NASA Kepler Space Telescope, namely information about dips in the light of observed stars and the characteristics of these dips, to classify each one into CONFIRMED (real planets), CANDIDATE (not yet classified as real or not), and FALSE POSITIVE (not planets). It then prioritizes the CANDIDATEs according to their likelihood of being real planets, offering something more than a simple classification — a decision-support tool astronomers could actually use.

How I built it

I started by analyzing the raw data of 9,564 signals with 140 columns to determine class distribution, missing values, and class separability before building any models. I removed columns that could allow the model to cheat by using NASA's pre-calculated answers, like koi_pdisposition, and trained three classification models of increasing complexity (Decision Tree, Random Forest, XGBoost) to evaluate the impact of each step. All analysis was performed in Python using pandas, scikit-learn, and XGBoost in a Google Colab notebook.

In addition to the basic model, I performed a hyperparameter tuning procedure to find the best-performing settings, prepared a metrics table and ROC curves for comparison, included eight automated sanity checks to catch simple errors, and implemented an interactive testing section that lets users try the model on real signals or enter custom data for predictions.

Challenges I ran into

  1. Realizing a column (koi_pdisposition) was silently letting the model cheat by giving away NASA's precomputed answer, and having to hunt it down and remove it along with a couple other columns
  2. Discovering that XGBoost doesn't have an equivalent to the class_weight parameter that the other two models do, and having to implement it manually
  3. Being misled by an early version of the interactive predictor due to an issue with how missing values were being imputed, and having to dig into it to find the root cause
  4. And finally, balancing wanting to deliver something genuinely strong against a real time crunch from schoolwork

Accomplishments that I'm proud of

  1. Reaching roughly 94% accuracy on real-world, messy NASA data with three properly-evaluated models, not just one
  2. Catching and fixing a data leakage issue before it could greatly inflate my results
  3. Building the candidate ranking so it's an actually useful feature, not just a novelty add-on
  4. Defending my results with automated testing rather than just trusting my instincts

What I learned

Before this project, I didn't know anything about how astronomers actually find exoplanets — I learned that they don't see the planet directly, they watch a star's brightness for a tiny, repeating dip, and that's the transit method. Working with real Kepler mission data also taught me that a lot of what looks like a planet signal turns out to be noise or a false alarm, which is why NASA has to sort thousands of signals like this in the first place.

On the modeling side, I learned that going from a Decision Tree to a Random Forest to XGBoost isn't just about picking "the best" model — each one taught me something different, like how a single tree can be easy to read but also easy to fool, while combining many trees or having them correct each other's mistakes actually improves results. I also learned that data cleaning matters more than I expected going in — I found a column that would have let my model "cheat" by seeing an answer it shouldn't have had access to, and I had to think carefully about missing values and class imbalance instead of just throwing everything into a model and hoping for the best.

What's next for Transit Triage: Kepler Exoplanet Classifier

Given more time, I would like to perform a broader hyperparameter search, compare my sample-weighting approach against SMOTE for handling the class imbalance, and analyze the raw Kepler light curves rather than the preprocessed features provided by NASA.

Built With

Share this project:

Updates

Submission history