DEV Community: Harihar Nautiyal

Astrophage: Building a Two-Stage Random Forest Exoplanet Classifier in Rust

Harihar Nautiyal — Mon, 29 Jun 2026 11:33:27 +0000

A weeks ago my teammate and I decided to enter the AI for Astronomy Hackathon 2026. The task was to classify thousands of Kepler Objects of Interest as confirmed exoplanets, candidates or false positives.

Most teams would use Python and scikit-learn. We did something. We built Astrophage, a custom Two-Stage Random Forest classifier written entirely in Rust. It uses Polars for data handling and a from-scratch machine learning implementation. Astrophage achieves 94.81% accuracy making it the accurate tabular-data model in the competition.

Here is how we did it why two-stage classification works and what we learned about building machine learning systems in Rust.

The Problem: Not Every Signal Is a Planet

The Kepler space telescope found thousands of exoplanet candidates.. Most of them are not planets at all. They are binary star systems, instrumental noise or stellar variability. Every false wastes precious telescope time. Every missed candidate is a habitable world we never study. The classification problem is real. It is hard.

The dataset gives you tabular features like periods, transit depths, signal-to-noise ratios, stellar temperatures and false positive flags. No images, no curves as pixels. Structured numbers that encode astrophysical reality.. That is where most machine learning approaches go wrong.

The Insight: Astronomers Do Not Think in Three Classes

We noticed that NASA astronomers do not look at a Kepler Object of Interest and ask "is this confirmed, candidate or false positive?" all once. They think in stages. They ask "is this definitely a planet?" If the answer is yes it is confirmed. If not they ask "is it worth telescope time?" If the answer is yes it is a candidate. If not it is a positive.

This is not a machine learning trick. It is literally how the science works. So we asked: what if our model did the thing?

The Architecture: Two-Stage Random Forest

Instead of a single 3-class classifier Astrophage uses two binary Random Forests in sequence. The first stage separates confirmed planets from not confirmed planets. The second stage separates candidates from positives.

The improvement is 3-4% accuracy gain over a single-stage approach. That may not sound like much. In exoplanet discovery every percentage point represents hundreds of potential worlds.

Why Rust?

We wrote a Random Forest from scratch in Rust. Why did we do that when Python and scikit-learn exist? It started as a challenge. It ended as a solution.

Metric	Astrophage (Rust)	sklearn (Python)
Inference	~1ms/sample	~10ms/sample
Training	~30 seconds	~2 minutes
Binary size	~2 MB	~500 MB+ (with env)
Runtime crashes	Zero	Occasionally
Memory safety	Compile-time guarantees	Manual management

The speed is not just nice to have. If you are classifying millions of Kepler Objects of Interest. Running real-time pipeline analysis, 10x faster inference matters.. The binary size? You could ship Astrophage on a Raspberry Pi if you wanted.

Feature Engineering: Where Astrophysics Meets Code

We did not throw 28 raw features at a model. We spent time understanding what each number actually means physically then engineered 8 derived features that encode astrophysical intuition.

The Star Feature: `fpflag_sum`

NASA already flags signals with four binary indicators. We simply added them up. Fpflag_sum has an importance score of 0.29. It alone explains a third of the models decision-making. When this value is non-zero the signal is certainly not a planet.

Other Derived Features

snr_x_prad. Signal-to-noise ratio × radius. Real planets have SNR to their size.
depth_duration_ratio. Transit depth ÷ duration. Planets make Ushaped transits; binary stars make V-shaped eclipses.
impact_penalty. If impact parameter > 1.0 the "planet" would miss the star entirely. Physically impossible.
log_period. Orbital periods follow log- distributions, not normal ones. Taking the log makes the feature model-friendly.
koi_prad_squared. Objects > 15 Earth radii are companions, not planets. Squaring creates a threshold.

Every derived feature has a story. That is not accidental. It is the reason the model generalizes well.

The Numbers

Metric	Score
Accuracy	94.81%
Macro F1	92.64%
Weighted F1	94.51%

Per-class breakdown:

Class	Precision	Recall	F1-Score
FALSE POSITIVE	99.69%	98.35%	99.01%
CONFIRMED	89.95%	94.54%	92.18%
CANDIDATE	88.42%	85.06%	86.71%

The false positive precision is nearly perfect because false positives often have flags. The candidate class is hardest. But that is by design. Candidates are supposed to be ambiguous.

What We Learned

1. Two-stage decomposition just works

Breaking a 3-class problem into two easier binary ones sounds obvious in retrospect but most machine learning pipelines do not do it. The accuracy gain is real. The architecture mirrors actual scientific workflow.

2. Domain knowledge beats compute

36 well-designed features outperform 100 generic ones. Understanding why orbital periods are log-normal why impact parameters matter geometrically and why NASA flags exist was worth more than any hyperparameter tuning.

3. Rust is viable for machine learning

Polars and NDArray can absolutely compete with Pythons ecosystem. The borrow checker is annoying for the week. Then you stop having memory bugs

4. Stratified sampling saves you from yourself

Without it our model would have learned "say false positive every time". Called it a day. The class distribution is that imbalanced.

5. Sometimes the best feature is already in the data

We thought we would discover some interaction no one had found. Nope. NASAs pre-vetting flags aggregated simply were our move. The experts already knew what to look for.

What's Next

** term:** Hyperparameter grid search, K-fold cross-validation recursive feature elimination to find the optimal subset.

** term:** Model serialization, a REST API for real-time classification, a web dashboard for interactive exploration.

** term:** Direct NASA Exoplanet Archive integration extending to TESS and JWST data explanations for every prediction.

The dream: Astrophage becomes a tool in the exoplanet discovery pipeline. Helping astronomers prioritize telescope time identify the most promising candidates and find more worlds, like our own.

Try It Yourself

GitHub: github.com/harihar-nautiyal/astrophage
Documentation: astrophage.hariharnautiyal.com
Google Colab: Run it without installing Rust. Notebook link

git clone https://github.com/harihar-nautiyal/astrophage.git
cd astrophage
cargo build --release
./target/release/astrophage

The first build takes a minutes but subsequent runs are instant.

"Somewhere something incredible is waiting to be known.". Carl Sagan

I am really interested in machine learning that uses tables. I also like learning about planets outside our solar system. If you like these things too or if you just want to know more about using the programming language Rust for science I would love to hear what you think. You can write a comment. Tell me about a problem, on GitHub.

This was made using Rust, Polars, NDArray, Tokio and a lot of coffee.

Stop Using Raw UUIDs: Type-Safe, Prefixed IDs in Rust (Stripe-style)

Harihar Nautiyal — Wed, 24 Dec 2025 05:46:37 +0000

We have all been there. You are staring at your server logs at 2 AM, trying to debug a request, and you see this:

Processing request for ID: 550e8400-e29b-41d4-a716-446655440000

Is that a User ID? An Order ID? An API Key? Who knows. It’s just a blob of hex characters.

Even worse, have you ever written a function like this?

fn process_payment(user_id: Uuid, order_id: Uuid) { ... }

If you accidentally call process_payment(order_id, user_id), the compiler won’t stop you. They are both just Uuid. You won't find out until your database throws a "Record not found" error—or worse, you corrupt data.

I’ve always admired how Stripe handles this. Their IDs look like cus_018... or ch_018.... They are self-describing and readable.

I wanted that same experience in Rust, but with the compiler enforcing safety. So, I built puuid.

What is puuid?

puuid (Prefixed UUID) is a lightweight Rust crate that wraps the standard uuid library. It gives you two main things:

Readability: IDs print as "user_018c..." instead of just numbers.
Type Safety: You cannot mix up a UserId with an OrderId.

How it works

It’s surprisingly simple to set up. You define your prefixes once (usually in your types.rs):

use puuid::{Puuid, prefix};

// 1. Define your prefixes
prefix!(User, "user");
prefix!(Order, "ord");

// 2. Create strong types
pub type UserId = Puuid<User>;
pub type OrderId = Puuid<Order>;

Now, look at what happens when we try to make that mistake from earlier:

fn delete_order(id: OrderId) {
    println!("Deleting order: {}", id);
}

fn main() {
    let user_id = UserId::new_v7();

    // ❌ COMPILE ERROR: expected OrderId, found UserId
    delete_order(user_id); 
}

The Rust compiler now protects you from your own typos.

"But does it kill performance?"

This was my main concern when building it. The answer is no.

Puuid<T> is a #[repr(transparent)] wrapper around the standard uuid::Uuid.

Memory: It takes up the exact same space as a standard UUID (16 bytes).
Database: You can insert it directly as a UUID type (via .into_inner()) or store it as text if you want to keep the prefix visible.
Methods: It implements Deref, so you can still call .as_bytes(), .get_version(), or any other method from the standard uuid crate.

A Note on UUID v7

By default, puuid encourages UUID v7.

If you haven't switched from v4 (random) to v7 yet, you should. v7 UUIDs are time-sortable. This means that when you store them in a database, they naturally index according to time creation. It prevents index fragmentation and makes INSERT performance much faster for large tables.

let id = UserId::new_v7();
// Output: user_018c6427-4f30-7f89-a1b2-c3d4e5f67890

Serde is Magic

If you are building a JSON API (with Axum, Actix, etc.), puuid handles the serialization for you.

#[derive(Serialize, Deserialize)]
struct Checkout {
    id: OrderId,
    customer: UserId,
}

If a client sends this JSON:

{
  "id": "ord_018...",
  "customer": "user_018..."
}

It works perfectly. But if they send a raw UUID or mix up the prefixes, the deserializer rejects it immediately with a validation error.

Try it out

I’d love to hear your thoughts on the API design. I’ve been using it in my own projects to clean up my logs and it has saved me from at least three "argument swap" bugs already.

Crates.io: crates.io/crates/puuid
Docs: h01.in/projects/puuid
GitHub: github.com/h01-team/puuid

Let me know what you think! 🦀

Why I chose Rust over Node.js for my Code Execution Backend

Harihar Nautiyal — Tue, 09 Dec 2025 14:53:23 +0000

I’m building a coding platform (Unifwe) where users run untrusted code.

The Problem: Running user code is dangerous. You need sandboxing. Node.js is great, but heavy for spinning up thousands of isolated instances.

Why Rust? :
Memory safety (critical for sandboxes).
Performance (cold start times were 40000 ms faster).
WebAssembly potential.

The Architecture: Briefly explain how your Next.js frontend sends code to the Rust API.

It was hard to build, but the speed is worth it.

if you want to test the speed of the engine, you can try the challenges here: Demo course