Qualified Monitoring · for satellite operators and control centres

Fewer false alarms. One alarm per event. An explanation with every verdict.

Steriod adds a second, explainable opinion behind your mission-control system: rules your engineers approved, each citing the operating document it came from, plus a label-free anomaly detector benchmarked on ESA's own public dataset. Every alarm names the affected channels, fires once per event, and traces back to the number and the document behind it.

  • Reads your archive or a live tap; never commands, never replaces your alarm system
  • Learns operating envelopes from your own archive, with no labels and no training
  • Runs on one server inside your control-centre network
Episode detail: two mined telecommand sequences account for ten of ten spans; per-detector timeline; score peaking at 34.9 times its threshold; Start RCA and Acknowledge
When the alarm goes off, Steriod knows why: the detectors, the channels and the command sequences behind it.
The problem

Your fleet grows faster than your operations team.

"The most important aspect repeated unequivocally by all [spacecraft operations engineers] was the problem with too many false positives […] It decreases adoption and trust." ESA/ESOC paper on the ESA Anomaly Detection Benchmark, SpaceOps 2025

Static limits flood the shift

Every commanded manoeuvre, eclipse and mode change trips a threshold. Operators learn to ignore alarms.

Learned detectors cannot explain themselves

A score without a reason does not survive a review board, and it cannot be told apart from a commanded event.

One disturbance, fifty alarms

A single event fragments into dozens of alarms across channels. Someone has to stitch them together by hand.

Investigations take days

Root cause means custom queries over raw archives, timelines rebuilt by hand, and the one engineer who remembers the last time.

What you get

A monitoring layer you can defend in a review.

Items marked Pilot support are delivered with the pilot, configured for your mission by our team.

DeliverableWhat it is
Approved monitoring rulesReadable rules drafted from your operating documents, flight procedures, ICDs and mission database, approved one by one by your engineer. Each cites its source.
Label-free anomaly detectionOperating envelopes, seasonal baselines, slope and joint-behaviour models mined from your own archive, with no training labels. Each mined bound carries its derivation and sample count, and stays unarmed until a human approves it.
One alarm per event, with affected channelsRule failures fold into episodes on the mission-time axis. Each episode lists the channels involved and whether a telecommand preceded it.
Command context, never silent suppressionCommand-to-effect links are mined from your archive. A rare nominal event caused by a command is annotated with that command; it is suppressed only after a person accepts the link.
Root-cause investigationOn request, one correlated investigation across every failing rule: time windows, charts and statistics computed by the engine, a narrative written by an LLM bound to cite those numbers, confidence stated. "Undetermined" is an allowed verdict.
Panels inside your consoleThe rule board and episode panels embed in Yamcs, Grafana or your operations console as chrome-less pages.
Operational qualification sheetPilot supportHow the system meets the operator requirements published with the ESA benchmark (binary verdicts, affected channels, alarm once for rare nominal events, online streaming, single high-end PC), with per-rule alarm statistics, reproducible replays and an exportable audit trail.
Fleet viewPilot supportThe same rule set on every satellite of the same bus; the unit that deviates from its siblings is ranked first.
See it, on ESA's Mission 1 archive

From an archive to explained episodes.

Every screen below runs on ESA's public Anomaly Detection Benchmark data (ESA/ESOC, Airbus DS, KP Labs, CC-BY 4.0).

Events timeline over five months of mission time: envelope rules, statistical models and command-vector lanes per row; 869 spans grouped into 9 episodes
One alarm per event. 869 rule and model spans over five months of mission time fold into 9 episodes. Download the report, or export the verdicts for independent scoring.
EXPLAIN

Each episode says what fired, where, and what may explain it.

Envelope rules on three channels, a joint model across six, coupling and noise-band detectors, each with its peak against its threshold. Two mined telecommand sequences account for every span, so the episode is annotated, and nothing is suppressed until a person accepts the link.

Episode card: notable severity, five detectors, six channels, and a command-context table with mined but unreviewed links
LEARN

It learns your spacecraft from its own archive.

A learning window on the mission clock runs the miners: envelopes, joint models, coupling, noise bands and command-to-response maps. Every result is staged for review; a named person closes the learning phase.

Pipeline page: processing chain from source to rule evaluator and statistical analysis, scheduled learning jobs, and an activity log with staged results for review
CORRELATE

It shows what moves together, and what nobody documented.

For any signal: what moves before it, what follows it, and whether the documents predicted that relation. Couplings measured on recorded runs but "not predicted by the system graph" are findings worth a look.

Signal flow for bat_current: upstream and downstream signals with measured correlation, labelled confirmed, finding or hypothesis, and the rules that check it
INVESTIGATE

Root cause, grounded in your documents.

The engine seeds the investigation with the failing rule, the exact time windows and the requirement behind it. An agent selects the signals and charts within a fixed budget; deterministic steps execute; the summary may only cite what was computed. Without grounding, the run says so instead of guessing.

Root-cause analysis workflow: engine steps seed scope and references, a budgeted agent investigates, engine steps finalise and execute, a grounded summary closes
How it works

Archive first, live second, humans throughout.

1 · Connect

A read-only tap on your telemetry archive, or a subscription to the live parameter stream. Signal metadata from your mission database.

2 · Learn

A learning window on the archive, on the telemetry's own clock. Envelopes, seasonal bounds and command-to-effect relations are mined. Nothing leaves the node.

3 · Approve

Your engineer reviews mined bounds and drafted rules next to their derivation and source, and arms the ones that should alarm.

4 · Run

The deterministic engine evaluates every approved rule on the live feed. Episodes appear on a shared timeline and inside your console.

5 · Investigate

Press "Start investigation". The engine assembles the facts, the model proposes a cause within the evidence, your engineer accepts or rejects.

6 · Review

Monthly: alarm statistics per rule, drift re-fits proposed with their evidence, rules retired or tightened by your team.

Fits your landscape

Behind your mission control, not instead of it.

You runHow Steriod connectsStays untouched
SCOS-2000 / EGS-CCOn-premises node inside the control-centre network; archive replay first (read-only), live tap second; signal metadata from the MIB Pilot supportYour MCS, alarms, procedures and flight dynamics
YamcsXTCE mission database imported directly; parameters forwarded by Steriod's Yamcs-to-MQTT connector; Steriod panels in a Yamcs web tabYour Yamcs instance and its alarm definitions
Commercial or in-house mission controlYour stack publishes decoded parameters to Kafka or MQTT, or drops JSONL archivesYour software, your command path
Grafana or an operations consoleRule board and episode panels embed as chrome-less pagesYour dashboards
Analysis archives (Terma STAT, data lakes)Read from file exports Pilot support; the detector runs on the data you already keepYour archive
Your own agents or scriptsEverything reachable as REST, command-line and MCP tools; deliberately no "approve" toolYour automation

Deployment: one Ubuntu server or equivalent, Docker Compose, offline bundle, no cloud dependency. LLM steps (document import, rule drafting, investigation narrative) run on an open-source model on your hardware; detection, evaluation and recording need no LLM at all.

Proof and savings

Measured on ESA's data, modelled on your fleet.

0.788 vs 0.786
Event-wise F0.5, Mission 1 lightweight subset, vs best published
5.5×
The event-wise precision of the best published method, Mission 1 full set (0.275 vs 0.050)
0.973
Alarming precision on the full set: one alarm per event
65 ms
A 14-year trend query over 611 million samples, on one machine

Self-reported on ESA's public labels, scored with ESA's own code, walk-forward protocol. Full case study →

LeverTodayWith SteriodBasis
False-alarm triageAbout 15 false alarms per satellite per month at about 2 h each: 4,320 h a year for 12 satellitesTriage volume cut by about 90 % through command context and seasonal baselines: about 350 k USD a yearSteriod ROI model, illustrative (12 LEO smallsats, 90 USD/h)
Root-cause investigationAbout 80 engineering hours per major anomaly, 12 a yearAbout 4 h of human review over an evidence-bound verdict: about 82 k USD a yearSteriod ROI model, illustrative
Archive queries during investigationsCustom queries over raw logs, hoursTens of milliseconds over a 14-year spanMeasured
Pilot: six weeks, fixed scope

One mission or bus type, one year of archive, six weeks.

WeekWhat happens
1Node installed in your network; archive connected; signal catalogue imported and reconciled
2Learning window run on the archive; mined bounds reviewed; first approval session
3Blind replay over the archive; episodes compared with your known anomalies; alarm statistics
4Rules drafted from operating documents; coverage report; command context tuned
5Live tap or shadow mode; two investigations run on real episodes
6Qualification sheet, statistics and the approved rule set handed over; decision on operational use

What we need from you

  • A telemetry archive export for one mission or bus type covering at least one year, or a read-only live tap
  • The mission database and the operating documents you want rules from
  • Known past anomalies if you have them: used only to score us afterwards, never to train
  • One operations engineer for about half a day a week

What this is not

  • Not a mission-control system, a packet decoder or flight dynamics
  • Not onboard FDIR. Steriod never sends a command.

Priced as a fixed pilot fee, quoted on scope. The rules, bounds and evidence stay with you.

Start with your archive

Send us one year of telemetry. We will tell you what your alarms meant.

Blind replay first, scored against your own anomaly list afterwards. Or book a meeting with us at Space Tech Expo Europe in Bremen, 17–19 November 2026.

ping@steriod.ai