A few months into the work, Caltech astronomer Steven Giacalone opened a review site we had built and started clicking through plots. We had already run hundreds of planet candidates through an exoplanet validation pipeline that Holaxis cofounder Mike Collier had spent months building.
Steven noticed something our tests had missed. Some of the transit signals looked smeared rather than sharp. The orbital periods being used to fold the light curves needed further refinement.
The pipeline had calculated precisely what it had been instructed to calculate. The problem was that some of the inputs needed another scientific check.
That distinction mattered. Our internal tests could tell us whether two implementations produced the same result from the same input. They could not tell us whether the input itself made scientific sense. That required an astronomer to look at the evidence. And once Steven had looked, the check he performed became something the pipeline did on every candidate that followed.
The team corrected the problem before completing the final analysis. That was not the end of the project. It was the middle of it.
The result
We shared the scientific findings of this project in our previous story. The study, accepted for publication in The Astronomical Journal, reports 80 statistically validated TESS planets, including 64 validated for the first time. Mike is the first and corresponding author. Holaxis cofounder Brian Derfer is a coauthor, and the 41-member research team includes Steven and contributors affiliated with NASA, MIT, Caltech and other institutions.
The paper also examines how much high-resolution imaging affects the statistical validation of planet candidates, particularly the smallest ones. That finding may help astronomers determine where scarce ground-telescope time is most likely to change an outcome.
Those are the scientific results. This story is about what it took to produce them.
Holaxis is not an astronomy company
Holaxis builds systems that turn what a team knows into infrastructure it can run on.
Mike and Brian brought backgrounds in applied AI, software, product development, real-world cognition and organizational systems to the project. Neither had traditional training in astronomy. They could not determine on their own what counted as a scientifically defensible result.
That expertise came from Steven and the broader research team.
Astronomy presented an unusually demanding test. The field had a difficult problem, public data, established scientific methods and a substantial backlog of planet candidates awaiting further study. The results needed to withstand expert scrutiny, and every important calculation needed to remain connected to the evidence supporting it.
Mike began the project unable to read a light curve. He used AI agents to help him navigate unfamiliar terminology, methods, software and source material. Over time he developed enough working knowledge to collaborate productively with Steven and the other researchers. Terms that initially meant little to him became specific enough to discuss, question and eventually translate into working software.
He never became an expert in light curve analysis, Bayesian inference or astronomy. The expertise ended up somewhere else, in the system he was building around himself. That system produced an automated pipeline that did in minutes what had taken hours, and it fixed and hardened software the astronomy community has relied on for nearly a decade.
Making separate systems behave like one
Statistical validation is commonly performed one candidate at a time. Each analysis draws on observations, catalogs, models and quality checks stored in different places and presented in different formats.
The pipeline brought information from multiple archives, catalogs, services and observing facilities into one coordinated workflow. Catalog entries and imaging products came through ExoFOP. Light curves came from the MAST archive. Stellar information and companion data came from additional catalogs and services. Imaging from multiple observatories had to be prepared in forms that TRICERATOPS could use.
TRICERATOPS is the statistical validation software at the center of the analysis. Steven is one of its developers. It was designed to evaluate individual targets, not to run hundreds of candidates through a coordinated production system.
Running it reliably at that scale required Holaxis to adapt the surrounding workflow. Data preparation had to be separated from computation. External-service failures needed clean recovery points. The information required to trace and reproduce each result had to be retained.
That work made the study possible at scale. It also introduced a risk. Reworking scientific software can make it faster while quietly changing what it calculates.
When two implementations disagree
To manage that risk, Holaxis built a numerical parity harness. It sent the same inputs through the original and revised implementations, compared the results function by function and flagged disagreements for investigation.
Some differences came from mistakes introduced during the new work. Others exposed problems in the original implementation. The comparison led to fixes that were contributed back to the TRICERATOPS project with regression tests.
One disagreement exposed an underflow condition affecting targets with especially dense light curves. Instead of producing a valid probability, the calculation could return a non-finite result without raising an obvious exception.
The failure appeared on precisely the targets with the most data, which might otherwise seem like the ones to trust most.
Comparing the implementations made the problem visible. The parity harness did what it was built to do.
But it could answer only one kind of question: Given the same inputs, would the two implementations produce the same calculation?
It could not determine whether the input itself was correct, or made scientific sense.
The correction our tests could not find
That brings us back to the smeared plots.
Steven could see that the transit signals did not look right. The software could not. Both implementations had received the same orbital periods, and both had faithfully calculated answers from them.
The correction became more than a one-time fix. It became a new requirement in the pipeline.
Before a candidate reaches TRICERATOPS, the pipeline now tests its orbital period and reference time against the light curve and refines them when the evidence supports doing so. Reviewing folded light curves also became a standing practice rather than a single check performed at the end.
The project produced this pattern repeatedly. An expert identified a problem or contributed an insight. People and agents investigated it, and the workspace turned it into something that could be tested. Once it held up, it became part of the pipeline rather than a lesson someone had to remember.
Each correction changed the starting point for the work that followed.
What made the pipeline possible
The pipeline is the part of this work that performs the calculations in the study. It gathers and prepares the data, tests important inputs and runs TRICERATOPS to calculate false-positive probabilities.
No scientific classification in the final catalog depends on an AI model's judgment. The paper's authors reviewed the calculations produced by the pipeline and remain responsible for the findings.
But the pipeline is only the settled part. It came out of a workspace that held far more than any pipeline could.
The project stretched across data sources, software, research papers, working documents, expert conversations and many AI-agent sessions. All of it accumulated in one place: expert feedback, rejected approaches, the evidence behind a correction, the reasoning behind a decision, the questions still open.
People and agents worked inside that cognitive ecosystem, and it shaped what they could see. An agent investigating a discrepancy could reach the earlier session where a related problem had been ruled out. An agent reading a working document could follow it to the expert conversation that produced it. A question Steven answered once did not have to be asked again.
The effect was a ratchet. Each turn built a floor of knowledge and capability that later work could start from. Work that was still unsettled stayed available without being committed to code. Work that held up was written into the pipeline, where it could be tested and versioned and improved a piece at a time.
Pipeline, workspace, platform
Holaxis
FPP Pipeline
Deterministically calculates the probability that a candidate was not a planet.
Workspace
Accumulating store of structured domain knowledge related to exoplanet validation.
Platform
Domain-agnostic infrastructure for building workspaces around domains.
But the pipeline was not the only thing accumulating. Corrections were saved along with the evidence that prompted them and the reasoning that resolved them, so a decision made in month two could still be traced and questioned in month six. Every addition also made the next one easier to file and easier to find. The workspace was getting better at holding knowledge at the same time it was getting more of it, and both of those gains held. Very little had to be re-derived by whoever hit the problem next.
The workspace was where knowledge and capability could ratchet. AI agents made the ratchet move with velocity and scale. Agents organized expert feedback, developed implementation plans, investigated software differences, wrote and checked code, monitored production runs and supported manuscript development. A small team worked through a volume of investigation and iteration that would otherwise have required a much larger one.
By the end of the project, the workspace knew a great deal about astronomy. The platform it was built in knows nothing about astronomy at all. Holaxis built that platform before this project began, on a bet that what a team learns can be held as knowledge infrastructure rather than left in people's heads. Astronomy tested the bet on a hard problem in a field none of us had trained in, and the test led to the evolution of the platform. What the team learned about validating planets stayed in the workspace. What Holaxis learned about building workspaces went back into the platform.
Learning to look at the evidence
Steven's correction began with something simple: He looked at the plots.
During the project, Mike realized that the agents could reason confidently about numerical light-curve data without doing the same. That was a problem because much of astronomical practice depends on recognizing what the evidence looks like, not simply reading its numerical representation.
Mike built a separate interface that allowed an agent to open and inspect a plot. The resulting analyses changed. An agent might form an interpretation from the numerical data, view the plot and then revise its conclusion.
The interface did not give the agent the judgment of an experienced astronomer. It gave the system another way to encounter the evidence and another opportunity for its reasoning to be questioned.
Why we think this generalizes
There are many attempts underway to build systems where "AI does science." This project suggests a more useful model.
The study depended on Steven and the broader scientific team. Agents and automated tests extended the team's reach, but expert scientific judgment caught what the system could not. That correction then became a permanent part of the pipeline, applied to every candidate that followed.
What's Next
We expect the paper to be published in The Astronomical Journal this month. The accepted manuscript is on arXiv now.
We learned a great deal during the TESS study about how agents find and process information, and how to support collaboration between people and agents. The technical landscape moved at the same time. Models got more capable, and several tools and standards emerged that pointed the same direction we were going.
We took all of that input and rebuilt our human-agent collaboration platform around it, and we plan to release it as open source in the next few weeks, so that other teams can start from a higher floor than we did.