They did just make a GitHub repo public which has some of the data, some of which seems newly public:
https://github.com/dca-doherty/VASCO-ML
MIT License, so I've attached a .zip here:
Thanks Mick. Worth adding what is and isn't in that release, because it changes what anyone can do with it.
The 107,875-row file is the VASCO 2025 sample. The detection output behind Solano et al. (2022). It carries RA, Dec and observation date plus some catalogue-level columns. What it
doesn't carry is the per-candidate ML scores behind the paper's figures: the ml_probability column takes 287 distinct values across 107,875 rows, and 99.7% of rows share one identical value, while the committed decile tables span a continuous range in ten equal bins. The scored catalogue, the 250 training labels and the image-derived features aren't in the repo either.
I tried the documented reproduction in their own pinned environment. reproduce.py --verify-only passes 22/22, but it only compares committed outputs against committed expectations - nothing is recomputed. The full run stops in half a second at stage one of four. Working around each obstacle in turn: the config points at data/raw/ while the file ships at data/; requirements.txt omits seaborn, which the training stage imports; feature extraction then reports OK in under a second while producing a cache containing none of the 16 image-derived features (the config points at a D: path); and training stops on "No label files loaded", which can't be worked around.
To be clear about what that does and doesn't mean:
the published results can't currently be regenerated from the published artifacts. It is not evidence they're wrong. Any one of the labels, the feature matrix or the scored catalogue would change the situation.
Two other things in the write-up: 1) the catalogue can't be derived from the method the 2022 paper describes, 2) and why my catalogue isn't the same list (stated by stage, because raw-detection agreement and candidate-level agreement are very different numbers and mine has been misquoted before):
https://github.com/jannefi/poss1-plate-slice/blob/main/docs/REFERENCE_CATALOGUE_REPRODUCIBILITY.md
External Quote:
MNRAS 515(1):1380 describes tessellating the sky in circular regions of 30 arcmin radius, fed by an image cutout service. No tessellation of that kind can produce this catalogue, and the reason is measurable without any access to it.
External Quote:
...The ceiling above implies a negative that is worth stating precisely: the catalogue was not produced by a position-blind tessellation of the sky, grid or circular, because no such tessellation reaches it.
...
What the released file cannot settle at all. It carries ra, dec and obs_date and no plate identifier or exposure time. A single observing date commonly covers several plates, so for most rows the exposure a row came from is not determined by the released columns. Any account of the construction that depends on knowing the plate per row is therefore not checkable against the public file, and we make none here.
POSS-II red plates
Separately, and I think more interesting: a control I've wanted for a long time. Run the identical pipeline on POSS-II red plates covering
the same sky as POSS-I plates I've already processed. If the candidate rate were a property of my filters rather than of POSS-I, it should reproduce. It doesn't:
0.1243 ± 0.0152 over 30 plate pairs, about an eighth, and no stratum departs from it when split by declination, galactic latitude or plate grade.
The caveat matters as much as the number: POSS-II red is a different emulsion at a different depth and epoch, sampled 1.68× finer, so "fewer candidates on a cleaner, deeper plate" is an ordinary explanation this test can't exclude. It's same-sky, not same-instrument. Busko (2026, arXiv:2603.20407) is the comparison that does control for era and instrument class.
https://github.com/jannefi/poss1-plate-slice/blob/main/docs/POSS2_RED_CONTROL.md
External Quote:
What this does and does not mean. It means the published results cannot be regenerated from the published artifacts, contrary to what the README states, and that a reader who runs the documented command will get a pass that verifies nothing. It is not evidence that the results are wrong. They may be entirely correct; the point is that no third party can currently check, which is a property of the release rather than of the analysis.
Additional notes
Four notes on choices I made and used on my github repo:
I used "the VASCO 2025 sample", not the letter. I know the letter notation is Watters' and has been used in that thread before, including me. But it's now a locked convention in the repo and gate-enforced, so using it in a post while the repo bans it would be inconsistent the first time someone checks.
I put the "not evidence they're wrong" line in the body, not a footnote. In a thread started by the site's most prominent VASCO critic, that sentence is what keeps the post a reproducibility report rather than a pile-on, and it's the thing that preserves your ability to talk to the VASCO team afterwards.
I built the POSS-II caveat into the same breath as the number. A skeptic-leaning forum will read "an eighth" as "POSS-I candidates are mostly artifacts", which is exactly what it does not show.
On the zip: I'd avoid referencing or re-hosting it. The data in that repo isn't MIT. The licence covers the code, and the README grants the datasets only "for reproducibility of the associated publication".
