How Star Vetter decides.
Star Vetter runs unattended, end to end, from sampling a fresh batch of TESS targets through to a written dossier for every surviving candidate. No step is manually curated: every number on this page and in every candidate's dossier comes directly from the pipeline's own output, and every stage transition is logged with the reasoning behind it. Unfamiliar term? Everything technical here is also in the glossary. How well does it work? See how it was tested against known binaries.
What this is
A piece of software that looks through public space-telescope data on its own, star by star, checking each one for two stars orbiting so closely that each dims the other's light on a repeating schedule.
How it works
Seven stages, sample to dossier - sampling, fetching, statistical vetting, catalog cross-matching, a contamination check, a pixel-level confirmation, then a written dossier. Laid out in full below.
Why it exists
TESS has observed hundreds of millions of stars and only a fraction have ever been checked by a person. This covers more of that ground automatically, as an unattended, fully logged agentic workflow - not a script a person babysits.
Where targets go
Seven stages
- 1
Sample
Draw a fresh batch of TESS Input Catalog targets that haven't been looked at in any earlier run, so every batch expands genuinely unexplored territory rather than re-checking old ground.
- 2
Fetch
Pull each target's light curve from MAST. Not every TIC has usable data - many were never observed at the right cadence, or the FITS file is unusable - so this stage is a real filter, not a formality.
- 3
Statistical vetting
Run every light curve through the physical vetting gates below: eclipse count, odd/even depth consistency, robust detection significance, secondary-eclipse search, and BLS signal-to-noise. Most light curves are noise, instrumental artifacts, or non-eclipsing variability, and are rejected here.
- 4
Catalog cross-match
Every statistically-passing candidate is checked against 6 variable-star and eclipsing-binary catalogs. A match means the star is already known and vetting stops there; only unmatched candidates are carried forward as novel.
- 5
Contamination check
Before spending a pixel-level check on a candidate, its TESS aperture is checked for bright catalog neighbours close enough to plausibly be the true source of the dimming.
- 6
Pixel-level confirmation
The only stage that looks at pixels rather than the summed light curve: difference imaging between in- and out-of-eclipse cadences, checked against the 6 pixel-level gates below, to confirm the dimming comes from the target and not a blended neighbour.
- 7
Dossier
Every surviving candidate gets a full written dossier - ephemeris, every gate value, the catalog cross-match table, and the pixel-check imagery - generated automatically, with no manual write-up step.
The gates
Statistical vetting
- Eclipse count
- At least the minimum number of eclipses required to trust a period, so a single noisy dip can never pass on its own.
- Odd/even depth consistency
- Alternating eclipses must be statistically consistent in depth. A significant odd/even split is often the signature of an undetected period alias rather than two different eclipse depths.
- Robust detection significance
- The in-eclipse dip must clear a signal-to-noise threshold computed with an outlier-robust noise estimate, not a plain standard deviation that outliers could inflate.
- Secondary eclipse search
- The phase-folded curve is searched for a secondary eclipse independent of the primary detection, informing the tier and caveats even when none is required to pass.
- BLS signal-to-noise
- The Box Least Squares periodogram signal-to-noise ratio must clear a minimum threshold for the detected period to be trusted.
Pixel level
- In-eclipse light curve dip
- The dip must independently reappear at the same phase in this sector's own light curve, at significance.
- Difference-image peak SNR
- The out-of-eclipse minus in-eclipse pixel difference image must show a significant, spatially compact source, not scattered noise.
- Epoch-shift consistency
- The eclipse timing recovered independently at the pixel level must line up with the light-curve ephemeris, ruling out an unrelated nearby variable aligning by chance.
- Source compactness
- The difference-image source must be consistent with a single point spread function, not a diffuse or multi-peaked pattern that would suggest blended light.
- Centroid offset
- The photometric centroid shift between in- and out-of-eclipse images must stay within the target's own pixel, or the signal is charged to a neighbour instead.
- Nearest-neighbour contamination
- Catalog neighbours within the aperture are checked by brightness and distance, so a bright nearby star cannot masquerade as the target dimming.
Catalogs cross-matched
- VSX
- ASAS-SN
- Gaia eclipsing-binary table
- Gaia variable classification
- TESS EB catalog (Prsa+2022)
- ExoFOP TOI list
The learning layer
A model trained on this pipeline's own labeled history to predict the pixel-check outcome before it runs. It does not currently skip any pixel check - every novel candidate still gets the full check - this only measures whether the model could, safely, do that one day. Chosen model: hist_gradient_boosting, cross-validated on 2,465 labeled candidates (239 confirmed on-target, 2226 not).
send every candidate to the pixel check
ROC AUC 0.824
ROC AUC meaningfully above 0.5 (a coin flip)
Screening value
How much of the pixel-check download could be skipped, at a given minimum recall, if the model were used to screen candidates - a cross-validated, out-of-fold estimate, never measured on the model's own training data.
| Target recall | Threshold | Achieved recall | Downloads skipped |
|---|---|---|---|
| 0.95 | 0.01 | 0.983 | 23.3% |
| 0.90 | 0.03 | 0.916 | 47.3% |
| 0.80 | 0.07 | 0.812 | 66.2% |
Top features
- Tmag0.1008
- bls_duration0.0531
- robust_sigma0.0504
- depth_ratio0.0307
- n_points0.0201
- bls_period0.0144
In plain English
Star Vetter automatically identifies eclipsing binary stars in data from NASA's TESS satellite. An eclipsing binary is a pair of stars orbiting each other in a plane that crosses our line of sight, so they periodically block each other's light. TESS collects brightness measurements of hundreds of thousands of stars; Star Vetter searches those light curves for the telltale dips that signal an eclipse, then tests whether each candidate is real or a false alarm caused by instrument noise or other stars in the field. Every candidate passes statistical vetting, a cross-check against six known variable-star catalogs, and an automated pixel-level check to rule out contamination from nearby stars. We list the 239 candidates that passed all these gates. You can examine each one's light curve, vetting details, and open caveats on its individual page. Because many candidates remain unconfirmed eclipsing binaries, visitors are encouraged to inspect the data themselves.
- What is an eclipsing binary?
- An eclipsing binary is a pair of stars that orbit each other. Their orbital plane is tilted so that from Earth, each star periodically passes in front of the other, blocking some of its light. This creates a distinctive dip in the brightness pattern we observe. Eclipsing binaries are valuable laboratories for measuring stellar properties and understanding stellar evolution.
- What do you mean by 'candidate' versus 'confirmed'?
- A 'candidate' is a star system whose light curve shows eclipse-like features but has not yet been checked for false alarms. A 'confirmed' candidate is one that passed Star Vetter's automated pixel-level check, which verifies that the eclipse signature comes from the target star itself and not from a nearby star whose light accidentally blended into the measurement. Confirmation means the automated check passed - it does not mean the star has been scientifically verified by other means.
- What is the machine learning score shown on candidate pages?
- Star Vetter uses a machine learning model (gradient boosting, trained on 2465 labeled examples) as a second opinion on whether a candidate is likely to be a real eclipsing binary. It scores each candidate but does not decide which ones get checked - every candidate that passes statistical vetting and the catalog cross-match undergoes the pixel-level check regardless of the ML score. The ML score is for reference only and is not used to gate or prioritize future work.
- How does Star Vetter check whether a candidate is real?
- Every candidate undergoes an automated pixel-level check. This test examines the spatial distribution of the eclipse signal within the TESS pixel data to confirm the eclipse comes from the target star and not from a fainter nearby star whose light contaminated the measurement. The pixel-level check is fully automated and runs on every candidate that passes the earlier statistical and catalog checks.
- What if the eclipse period looks like it might be aliased?
- TESS observes stars at a regular cadence, which can create ambiguity: the true eclipse period might be different from what the light curve appears to show. Star Vetter tests for this using an odd/even eclipse-depth test, which compares the brightness dip of odd-numbered eclipses against even-numbered ones. If they differ significantly, the period may be aliased. This caveat, if present, is listed on the candidate's individual page.
- Can I verify a candidate myself by looking at the data?
- Yes. Every confirmed candidate on this site has a detailed page with its light curve, vetting statistics, and pixel-level check results. You can download the TESS light curve data and inspect it yourself. Because many of these candidates are still unconfirmed eclipsing binaries in the broader astronomical sense, independent examination and follow-up are encouraged.