The method that didn't run

I pointed Aurora at a climate buoy dataset and it returned 20 findings, each one carrying the name of the method that produced it. Then I scrolled to the bottom of the narrative and found the part I actually care about: a Gaussian process regression that hit its time budget, stopped, and said so in plain English. That disclosure is worth more than any of the findings above it, and almost no analytics tool will give it to you.

What I ran

The dataset ships with Aurora as climate_buoy_demo.csv, so anyone reading this can reproduce the run exactly. It is multivariate time series data with the shape environmental sensor feeds usually have: a timestamp column, a precipitation column, temperature, and several correlated channels that drift together.

Aurora's pipeline does not ask you to choose methods. It profiles the data, runs the methods that are valid for that shape, and skips the ones that are not, which means the interesting output is not just the findings list but the record of what the engine decided to attempt. Here is what came back.

Two things about that table matter more than the numbers in it. First, the anomaly detection is a consensus result: isolation forest and robust z-score both had to agree, which is why the finding carries two method names instead of one. Second, every row of it is clickable in the app down to the evidence, and the whole run exports as a signed bundle with a SHA-256 content hash. If I paste a number from this run into a report, you can verify I did not retype it wrong.

The equation nobody assumed

The result I found genuinely interesting was the sparse identification pass. Aurora ran SINDy against a candidate library of nonlinear terms and recovered a governing set of differential equations directly from the data: 49 active terms at sparsity 0.183, reconstruction RMSE 0.0424.

Why that framing matters to anyone who has fit a model in anger: the equation form was discovered rather than assumed. When you fit a parametric model, every residual is ambiguous. You cannot tell whether the world surprised you or whether you simply chose the wrong functional form. When the form is recovered from the data, departures from it are evidence of something real. The engine says this out loud in its own narrative, which is the kind of epistemics I want printed next to a number rather than buried in a methods appendix nobody reads.

And then the part I came for

At the bottom of the narrative, under pipeline notes, Aurora reported this:

Gaussian process analysis exceeded the 90-second per-method time budget on this dataset and was deferred. Reducing column count or using a higher tier will allow it to complete. verbatim from the run narrative

Sit with what the alternatives would have been. A dashboard product would have shown you the other results and quietly omitted this one, leaving you to conclude the analysis was complete. A language model asked the same question would have produced a confident paragraph about Gaussian process behavior on this data, invented from priors, indistinguishable in tone from the parts that were computed. Both failure modes are silent. Both are the industry default.

Aurora's third option is to tell you the budget it enforced, which method hit it, and the two concrete things you can change to get the result. That turns a limitation into an actionable instruction. It also tells you something about the shape of your own data, because a Gaussian process blowing a 90 second budget is a statement about dimensionality and sample count, not a mystery.

This is the whole argument for glass-box tooling, compressed into one sentence of output. The trustworthy tool is not the one that always has an answer. It is the one whose silence you can distinguish from its confidence.

Why I built the budget in the first place

A per-method time budget sounds like a performance feature. It is really an honesty feature. Without it, one expensive method on a wide dataset hangs the entire run, and the user is left staring at a spinner with no way to know whether to wait or restart. With it, the run always terminates, always returns everything that finished, and always names what did not. The cost is that some runs are incomplete. The benefit is that no run is secretly incomplete.

If you work with data professionally, you already know which of those two failure modes has cost you more. It is never the one you were told about.

# desktop app (Windows, macOS, Linux)
github.com/FantasyLab-ai/aurora/releases/latest

# or drive the same engine from an agent or notebook
uvx aurora-mcp --list-tools
pip install aurora-mcp