Start with V&V. Every capability after that reuses the same rules, data, and engine.
Each use case below states honestly what it does and what stage it's at. Available runs in the platform today; In development is being built; Planned is on the roadmap.
Automated requirement V&V
The scenario: your battery subsystem has forty written requirements and a folder of test scripts nobody trusts. With Steriod, each requirement becomes an Axiom rule in a versioned test suite, verified continuously against every recorded run and live pass.
Four-state rule status
Every rule reports pass, fail, pending, or not-exercised — so a green board can't hide requirements your tests never actually triggered.
Runs as first-class evidence
Each execution is a recorded run: which rules ran, on which data, with what verdicts. Compare runs, re-verify after changes, cite results in reviews.
Temporal semantics built in
"Within 5 seconds of X, Y shall hold" is a one-line rule, not a windowing library. Axiom is designed for behaviour over time, not just thresholds.
Readable by non-programmers
A systems engineer or an external reviewer can read a rule without tooling — it's structured plain text, versioned like code.
-- REQ TTC-T-1: after a mode switch to SAFE, the transmitter
-- power shall drop below 2 W within 10 seconds.
rule $"safe mode caps tx power" is
when acs_mode = SAFE
then tx_power < 2.0 within 10 secondsLive anomaly detection
The same approved rules that verify requirements also watch live telemetry. When a rule fails on a stream, that's an anomaly — flagged in real time, with the exact rule, signal values, and time window attached.
Streams, not batches
Pipelines subscribe to MQTT topics fed by your ground segment (YAMCS out of the box) and evaluate rules as samples arrive.
One vetted rule set
Replaces scattered limit tables and per-console alarm configs with a single reviewed, versioned source of truth.
Recorded as it happens
Live data lands in the trend store while rules evaluate, so the moment something fires you already have the data to investigate it.
Root-cause analysis
The scenario: a battery fault fired during last night's pass. Instead of grepping logs, you open the run: an event timeline shows every rule transition and signal excursion in order, and the AI assistant explains the likely chain — citing your own specification documents, not folklore.
RCA timeline
Rule events and signal behaviour on one run-scoped timeline — see what tripped first and what cascaded.
Multi-run comparison
Put the anomalous run next to a nominal baseline and diff the behaviour instead of guessing from memory.
Grounded explanations
AI answers cite the imported spec — the root-cause guide for each requirement comes from your documents, retrieved at answer time.
Everything is auditable
The analysis, the data it used, and the resulting report are stored artefacts — an investigation you can hand to a review board.
Trend & data analysis
Ask "how did battery temperature behave across the last three runs?" in plain language. The planner builds a small, reviewable analysis plan in bounded, verified steps; execution is deterministic against the TimescaleDB trend store; the summary you get back is grounded in the computed results — not improvised.
Plan, then run
The AI proposes charts and statistics as a plan the backend verifies step by step — and the run itself involves no AI: execution is fully deterministic.
Statistics, not vibes
Descriptive stats, window comparisons, and trend tooling computed by the engine. The LLM narrates results; it never invents numbers.
Durable results
Every analysis produces a stored result artefact — reportable, comparable, and reusable as the starting point for the next question.
Document intelligence
Your specification PDF is the ground truth everything else hangs off. Steriod imports it into a knowledge base with one artefact per requirement, then puts it to work: coverage measurement, gap analysis, rule drafting, and grounded answers.
Import with provenance
PDF specs become structured, versioned knowledge artefacts — searchable by meaning, with provenance kept and imports resumable on large documents.
Coverage & gap analysis
See which spec requirements your test suites actually cover, which are gaps — and have the assistant draft candidate rules for the gaps.
Measured quality
Imports are scored, not assumed: a verification loop marks per-artefact extraction quality so you know how much to trust the knowledge base.
Feeds everything downstream
RCA citations, drafted thresholds, and coverage numbers all trace back to the imported documents — one source of truth, used everywhere.
Requirement reverse-engineering
For legacy systems whose real behaviour has drifted from — or was never in — the documentation: learn candidate rules from historical telemetry, review them like any other draft, and bring the system back under an explicit spec. The building blocks (trend store, rule drafting, human approval gate) are the same ones the available use cases already run on.
Onboard & embedded execution
Axiom already has an embedded C runtime alongside the Go reference runtime. The goal: the exact rule text an auditor signed on the ground also runs on constrained hardware — the same verification logic from the test bench to the spacecraft, without a rewrite in between.
Have a use case that isn't on this page?
Tell us about your mission and data — the rule layer is more general than this list.