ETHOS
An ML pipeline that classifies 9,500+ Kepler Space Telescope candidates as confirmed exoplanets or false positives, deployed live on AWS with full experiment tracking.

The Problem
The Kepler archive holds thousands of candidate signals, but a large share are sensor artifacts and eclipsing binaries masquerading as planets. Separating real exoplanets from noise by hand doesn't scale.
Research
Before touching a model, I audited the data physically. The NASA Exoplanet Archive flags candidates with diagnostic columns (transit depth, stellar radius, signal-to-noise), and a naive model happily learns from rows that are physically impossible.
That audit shaped everything: I removed candidates whose parameters implied sensor artifacts (transits deeper than the star itself, for example) before any training happened, so the models learned planet physics rather than instrument quirks.
The literature pointed to tree ensembles as the standard for tabular Kepler features, but I wanted evidence rather than convention, which is why the project is built as a controlled comparison instead of a single-model pipeline.
The Solution
The pipeline runs from raw archive rows through feature selection, an 80/20 stratified split, and GridSearchCV with 5-fold cross-validation over two model families: Random Forest and a multi-layer perceptron.
Every training run logs to MLflow, nine performance metrics per run, so any result in the final report traces back to exact hyperparameters and data version. Nothing in the project depends on memory or a lucky notebook state.
The champion model ships as a Flask API on AWS EC2 with a Streamlit frontend, where anyone can submit stellar parameters and get a real-time classification with confidence output.
- Physical audit removed sensor artifacts before training
- Random Forest vs. MLP, GridSearchCV, 5-fold cross-validation
- MLflow tracking: 9 metrics logged per run, every run reproducible
- Champion model live on AWS EC2 (Streamlit + Flask)
Technical Decisions
Head-to-head model comparison instead of a single model
Claiming 'Random Forest is best' without a controlled baseline is folklore. Running the MLP under identical splits and tuning made the 94.91% vs. 91.42% result an evidence-backed conclusion.
Trade-off: Twice the training and tuning time, worth it for a defensible result.
MLflow from day one
Experiment tracking added ten minutes of setup and saved hours of 'which run produced this number?' archaeology. Every metric in the final report is traceable to a logged run.
Domain-driven data auditing before model training
Cleaning by physics (impossible transit geometries, artifact flags) rather than generic outlier removal meant discarding rows for reasons I could defend to a domain expert.
Trade-off: It required actually learning the astrophysics of transit detection, slower than dropping outliers, but the accuracy gains were real.
AWS EC2 + Streamlit for deployment
A live demo that anyone can try beats a notebook screenshot. Streamlit kept the frontend cost near zero so effort stayed on the pipeline.
What Didn't Go As Planned
Early models scored suspiciously high, the archive's disposition columns were leaking the label into the features.
Traced the leak, removed every disposition-derived column, and rebuilt the feature set from physical measurements only. Accuracy dropped, then became real.
GridSearchCV over the MLP was slow enough to stall iteration.
Narrowed the search space using coarse-to-fine sweeps and parallelized folds, cutting tuning time enough to keep the comparison honest without weeks of compute.
Outcome
ETHOS is live at eth0s.online. Beyond the model scores, the pipeline itself is the result: auditable, reproducible, and deployed, the difference between a course project and an engineering artifact.
Reflection
The physical audit was the highest-leverage work in the project, and I did it second instead of first. Next time, domain understanding comes before any code. I'd also add a calibration analysis, classification confidence matters more than raw accuracy when a human astronomer acts on the output.