Platform

Focused components around one core: the Axiom rule engine.

Everything below runs today; items marked Pilot support are delivered with a pilot. The desktop app and the server deployment share the same service layer, so a project started on a laptop behaves identically on the ops network.

System shape

How the pieces fit

architecture
Steriod UI (browser)          Steriod App (desktop)
      │ REST                       │ native bindings
      ▼                            ▼
  Service Manager — projects · suites · runs · pipelines
      │ gRPC                       │
      ▼                            ▼
  Axiom engine (compiler + runtime)   Trend store (TimescaleDB)

  telemetry in:
  spacecraft / simulator → CCSDS/UDP → YAMCS → MQTT → pipelines
The core

Axiom — the rule language and its runtimes

A domain-specific language for temporal, behavioural rules over data streams. Human-readable enough for an auditor, formal enough for a compiler.

Compiler + reference runtime

The Axiom compiler and reference runtime are written in Go and exposed as a gRPC service, a CLI, and a WebAssembly build — the same engine you try in the Playground.

Embedded C runtime

libaxiom: strict C99, zero malloc, no recursion, bounded loops, no syscalls. A differential test proves its events identical to the Go and Rust runtimes. See the Embedded Rule Runtime.

Editor tooling

A language server (LSP) and a VS Code extension: syntax highlighting, diagnostics, and completion for .axiom files.

Flight recorder & trend store

The engine records evaluations and signal data as it runs — into files or TimescaleDB — so every verdict is reconstructible after the fact.

Pipelines, learning and workflows

Deterministic where it decides, AI where it reads.

PIPELINES

A processing chain with scheduled learning jobs.

Source, transformer, rule evaluator, notifier and statistical analysis, plus jobs that mine envelopes, drift, joint models and command-to-response maps on the mission clock. Every mined result is staged for human review before it can alarm.

Pipeline page: processing chain, learning jobs with schedules and run counts, and an activity log
WORKFLOWS

Versioned workflows with engine, agent and human steps.

Document import, rule drafting, root-cause analysis and signal analysis are declared workflows. Each step says whether a model runs in it; engine steps never call one. Every run is fully audited and can be pinned to a different model to cross-test.

Document Import workflow v7: plan, extract, inventory, describe, relate, reduce and verify steps, each marked engine or map, with inputs and outputs
SIGNALS

Your mission database is the vocabulary.

Signals, types and enumerations imported from XTCE, so every rule is type-checked against the catalogue before it runs.

Signal registry: XTCE import, signal names, types and enum values
The platform

One service layer, two front doors

All business logic lives in the service backend. The desktop app and the browser UI are two faces of the same system — no feature exists in one that can't be reached from the other.

Service Manager

The backend: projects, test suites, requirements, runs, dashboards, pipelines, settings — with pluggable storage and a REST API. This is where the approval gate lives.

Steriod App

A cross-platform desktop app embedding the same engine and an MQTT broker — a self-contained V&V workstation for a single engineer or a test bench.

Steriod UI

The web frontend: coverage and approvals, rule editing, the live rule board and episodes, dashboards, trend charts, the system map and the Vi assistant.

Data & integration

Built for the ground segment you already run

ComponentWhat it does
YAMCS integration A YAMCS plugin re-exports telemetry to MQTT, feeding Steriod pipelines from the mission-control system many smallsat teams already use.
Trend store TimescaleDB-backed storage for recorded runs and live telemetry — the substrate for trend analysis, multi-run comparison, and RCA timelines.
Signal metadata XTCE and ARXML readers give rules and analyses real signal names, units, and calibrations instead of raw packet offsets.
SCOS-2000 MIB importPilot support The mission information base of SCOS-2000, CCS5 and EGS-CC centres imported as the signal vocabulary.
Recorded runs from filesPilot support CSV and TDMS post-test files and CCS5 retrieval exports replayed through the same pipelines as the live feed.
Satellite simulator A CCSDS packet simulator with scriptable anomaly injection — rehearse fault scenarios and produce labelled test data end to end.
Transports MQTT and Kafka-compatible streaming (Redpanda) in the stack today, plus JSONL telemetry archives; the pipeline layer is transport-pluggable.
Deployment The full platform ships as a Docker Compose stack (UI, backend, engine, trend store, brokers, optional YAMCS) on a single on-prem node, with an offline bundle for air-gapped sites.
Open tooling

Scriptable and agent-ready by design

The same tool layer is exposed four ways, so both your engineers and your AI tools work against identical capabilities.

MCP server

Connect Claude or any MCP-capable agent to your Steriod instance: browse projects, query signals, validate rules, run analyses. Deliberately, there is no approve tool — sign-off stays human.

CLI & HTTP faces

The identical tool set as a command-line client for scripting and CI, and as an HTTP service — including document conversion (PDF, XTCE, office formats → structured markdown).

Curious how the AI layer uses this? See the agents page →

Get in touch

Want a walkthrough of the stack on your own data?

We can stand up the full platform against a recorded telemetry set in a single session.

ping@steriod.ai