Orion: MIT's Unsupervised Time Series Anomaly Detection Library

The problem Orion targets: anomaly detection without labels

Most anomaly detection tutorials assume you have labeled anomalies to train against. In practice you rarely do. The anomalies you care about are the ones that have not happened yet, and the historical record is mostly normal behavior with a handful of incidents that nobody tagged consistently. Orion is built for that situation. The README describes it as a machine learning library for unsupervised time series anomaly detection, and the workflow it supports is fit on one window of a signal, then detect on a later window. The quickstart does exactly this: it loads S-1-train, fits a pipeline, loads S-1-new, and calls detect. The intended user is an engineer or data scientist who has a single time series, wants rare patterns flagged for expert review rather than auto-remediated, and would rather start from a pipeline someone else assembled than from a paper. The README frames the output as a set of pipelines that identify rare patterns and flag them for expert review, which is an honest description of the scope. Orion is a triage tool, not an alerting system.

How an Orion pipeline is assembled and what fit and detect actually do

The unit of work in Orion is the pipeline, and the README is specific that these are verified ML pipelines. You select one by name. In the quickstart the name is 'aer', and the object you construct is orion.Orion(pipeline='aer', hyperparameters=...). Hyperparameters are not passed as a flat dictionary. They are keyed by a primitive path string, in the example 'orion.primitives.aer.AER#1', with a nested dictionary of settings such as epochs and verbose. That naming scheme tells you something about the architecture: a pipeline is a composition of primitives, each primitive is a class in the orion.primitives namespace, and the #1 suffix distinguishes multiple instances of the same primitive within one pipeline. So a pipeline is not a single model. It is a graph of primitives, and the hyperparameter dictionary addresses nodes in that graph. fit takes the training signal and detect takes the new signal, returning a pandas.DataFrame with start, end, and severity columns. The severity value in the README example is 0.122539, a continuous score rather than a boolean. That matters for how you consume the output: you get ranked intervals, and the thresholding decision is yours.

Installing Orion and running the aer pipeline end to end

Installation is one command: pip install orion-ml. Note the package name differs from the project name, which is a common source of confusion when searching PyPI. The README states this pulls the latest stable release. The README badge lists Python 3.8 through 3.11, so a 3.12 environment is outside what the project advertises. The quickstart sequence is short. Load data with from orion.data import load_signal, then train_data = load_signal('S-1-train'). The returned frame has timestamp and value columns, with timestamps as integers in the example rows. Build the detector with Orion(pipeline='aer', hyperparameters={'orion.primitives.aer.AER#1': {'epochs': 5, 'verbose': True}}), call orion.fit(train_data), then load_signal('S-1-new') and orion.detect(new_data). The README includes a warning that depending on your system and installed versions, warnings may be printed and can be safely ignored because they do not interfere with pipeline behavior. Treat that as a signal about the library's polish level rather than as reassurance. The demo signals such as S-1-train are bundled with the package, which is why the quickstart works without downloading anything.

The leaderboard is the most interesting part of the project

Orion ships a benchmark rather than just a model zoo. The README states that in every release the project runs the Orion benchmark and maintains a leaderboard scoring the verified pipelines. The benchmark covers 12 datasets with known ground truth, and the table reports how many of those 12 each pipeline beats the ARIMA baseline on. Read the column header carefully: it is Outperforms ARIMA, a win count, not an average score. AER posts 12, meaning it beats ARIMA on every dataset in the suite. LSTM Dynamic Thresholding posts 9. TadGAN, LSTM Autoencoder, Dense Autoencoder, LNN, and TimesFM each post 7. VAE and UniTS post 6. Matrix Profile and GANF post 5. AnomalyTransformer posts 2. Azure's anomaly detector posts 0. The README points to a details spreadsheet with per-signal scores. This is a more useful artifact than a typical README table because it tells you which pipeline to try first and gives you a reason to distrust the rest. It also implies a maintenance obligation: the leaderboard is regenerated per release, so a pipeline's standing can move between versions.

Where Orion is the wrong tool

The README's own badge marks Development Status 2, Pre-Alpha. That is the project's self-assessment, and it should shape how you deploy it. Pre-alpha generally means interfaces can change without a deprecation cycle, and the hyperparameter key format, which embeds a primitive class path and an instance index, is exactly the kind of string that breaks silently when a pipeline is refactored. The second limitation is dimensionality. Every signal in the README, S-1-train and S-1-new, is a single value column. There is no multivariate example, no discussion of how to combine channels, and no guidance on correlated series. If your data is a fleet of sensors that only makes sense jointly, Orion's documented path does not cover you. Third, the output is intervals with severity scores, so Orion does not decide what is anomalous. It ranks. If you need a binary alert with a defensible threshold, you are building that layer yourself. Fourth, the train and detect split means distribution shift between the two windows is your problem, not the library's. Finally, the README's note about ignorable warnings suggests the dependency surface is not tightly pinned, which makes reproducible environments harder than the pip install line implies.

How Orion differs from a general purpose anomaly detection toolkit

The obvious comparison is a general purpose library such as PyOD, which exposes a catalog of detectors you fit and score yourself, or a forecasting library such as statsmodels, where you model the series and treat residuals as anomalies. Orion's approach is different in a way that matters. It does not hand you an estimator. It hands you a named, pre-composed pipeline that the maintainers have already run through a 12 dataset benchmark, and it exposes the tuning surface as a hyperparameter dictionary keyed by primitive path. The practical consequence is that you trade flexibility for a starting point that someone has already validated. With PyOD you pick an algorithm and own the preprocessing, the windowing, and the evaluation. With Orion you pick a string like 'aer' and get a fit and detect pair with a documented output schema. The cost is that when a pipeline underperforms on your data, your debugging surface is a graph of primitives addressed by string keys rather than a single class you can read. The benefit is that the leaderboard gives you a ranked shortlist instead of a blank page.

Licence, releases, and what maintenance actually costs

Orion is published under the MIT License, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is permissive and imposes no copyleft obligation on your own code. It says nothing about the licences of the underlying deep learning dependencies that individual pipelines pull in, and those vary, so if you are shipping a product you should check the transitive dependency licences separately. This is not legal advice. On release cadence, the supplied history shows v0.7.1 in March 2025, v0.7.0 in December 2024, and v0.6.1 in October 2024, with the repository's last push recorded in August 2026. The gaps are months, not weeks, and a minor version bump in a pre-alpha project is not a compatibility promise. The upgrade cost is concentrated in two places: the hyperparameter key strings, which reference primitive class paths, and the pipeline names themselves, since the leaderboard is regenerated each release and a pipeline's relative standing can change. Pin the version in your requirements file and re-run your own signal through the new version before upgrading.

Editorial conclusion

Adopt Orion if you want a working baseline anomaly detector on a single univariate signal without building the model yourself, and you are comfortable with a library the README labels Pre-Alpha. Do not adopt it if you need a supported, versioned API for production alerting, or if your data is multivariate, since every example and every signal name in the README is univariate. Before committing, run the aer pipeline from the quickstart on your own signal, check the shape and columns of the DataFrame that orion.detect returns, and read the leaderboard's details spreadsheet to see whether the pipeline you picked actually wins on data that resembles yours.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sintel-dev/Orion on GitHub