TransitScope

Inspiration

Earlier in October, reports showed that AI-assisted analysis had helped an amateur astronomer surface a possible hidden exoplanet. Those stories made the idea feel both exciting and approachable: astronomy discoveries can begin with careful questions asked of public data.

The reporting that inspired TransitScope includes Scientific American's coverage and Gizmodo's coverage.

I wanted to build something that showed the investigation process instead of simply announcing that an AI had “found a planet.”

What it does

TransitScope is a live and replayable observatory for assessing potential exoplanet signals.

It samples public TESS observations, looks for periodic brightness dips that could be caused by orbiting objects, and ranks candidates according to the strength and consistency of their evidence.

Candidates move through three stages:

1. Stage 1 screens light curves for periodic, transit-like patterns.
2. Stage 2 checks whether those patterns repeat across longer historical observations.
3. Stage 3 tests whether a model trained on earlier observations can predict later observations.

The dashboard shows rankings, candidate statuses, activity, light curves, metrics, pipeline history, and replayable ranking changes. It is intentionally framed as an assessment of potential planets—not scientific confirmation.

How we built it

TransitScope uses official MAST/TESS observations and the NASA Exoplanet Archive for known-object cross-reference.

A Dockerized worker handles ingestion and model execution. It writes normalized observations, candidate assessments, ranking snapshots, and pipeline events to DuckDB. A read-only FastAPI layer publishes consistent state to a Next.js and TypeScript dashboard.

Stage 1 uses an explainable Box Least Squares search and combines period, depth, signal strength, event count, consistency, coverage, and data quality into an evidence score.

Stage 2 checks whether detected signals remain repeatable over longer chronological windows.

Stage 3 uses a CPU-capable scikit-learn logistic model over transit-phase features. Its results are compared with a transparent phase-window baseline and evaluated against a later chronological holdout.

TransitScope also saves ranking snapshots and pipeline events. Replay reads those saved states rather than rerunning the models, allowing users to watch candidates enter, move through, or leave the pipeline.

I used Codex and the Devpost Learn Skill Pack to interview and narrow the original idea, create the scope, product requirements, and technical specification before coding, and work through a verification-based implementation checklist.

Challenges we ran into

The first challenge was scope. Searching 126,000 targets sounds simple until data availability, archive latency, historical coverage, CPU limits, and staged computation are considered. We had to distinguish a realistic public-data workflow from an unrealistic promise of instant discovery.

Another challenge was designing the pipeline as an investigation rather than a one-time leaderboard. A high Stage 1 score is only a reason to investigate. Candidates need repeatability, chronological holdout testing, and sufficient coverage before their status can change.

Missing data also required careful treatment. A candidate with insufficient observations should remain “Needs More Data,” rather than being incorrectly treated as a negative result.

A third challenge was making live behavior understandable. Worker publication, queue transitions, ranking changes, and replay all need durable state. During development, archive schema differences and DuckDB read/write timing exposed how easily a dashboard can display stale or partial information.

The final challenge was communicating uncertainty without making the experience feel empty. TransitScope shows the evidence, the next test, the candidate history, and changes in rank instead of overstating a provisional signal as a confirmed planet.

Accomplishments that we're proud of

• We turned a broad space-anomaly idea into a focused end-to-end exoplanet assessment observatory.
• The project uses real MAST/TESS-derived observations and scientific data provenance.
• The three-stage investigation process is visible instead of hidden behind one unexplained score.
• Replay is deterministic and read-only, so it does not rerun expensive models.
• Candidate details combine a light curve, interpretable metrics, current activity, next evidence, and pipeline history.
• The project includes Docker services, tests, model-processing code, ranking APIs, and a working dashboard.
• The repository contains the required scope.md, prd.md, and spec.md planning documents.
• The product remains useful even when no new planet is found because the changing quality of evidence is the experience.

What we learned

We learned that AI-assisted development becomes much more effective when the agent has a durable plan, explicit constraints, and verification checkpoints.

The most important improvements came from clarifying what a candidate represents, what each stage is allowed to conclude, and which state must be saved for replay.

We also learned that an evidence score is not the same thing as the probability that a planet exists. It is a prioritization signal whose meaning depends on coverage, repeatability, model evaluation, and comparison with other candidates.

Archive data is also not the same thing as a live stream. A live product must explain when data was retrieved, when processing occurred, and when a new published state is available.

Finally, observability is part of the model. Queue health, data sufficiency, model metrics, and publication state are necessary to understand whether the pipeline is actually making progress.

What's next for TransitScope

The next step is to make the production pipeline more scalable and scientifically useful. This includes improving throughput across the target universe, moving durable state to managed storage and queues, expanding known-object cross-reference coverage, and calibrating model metrics against labeled transit and false-positive examples.

I also want to deepen the educational layer with clearer comparisons between genuine transit signals, instrumental artifacts, and known objects.

The long-term goal is a public observatory where visitors can follow a candidate from its first suspicious brightness dip to a well-supported research lead—or watch the evidence responsibly rule it out.

Built With

• python