Platform

Focused components around one core: the Axiom rule engine.

Everything below exists and runs today. 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, an embedded C runtime for constrained targets — the path to running signed rule sets on flight-adjacent and onboard hardware.

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.

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 React web frontend: rule editing with Monaco, run timelines, dashboards, trend charts, a Cesium 3D mission view, and the Vi assistant.

Data & integration

Built for the ground segment you already run

Component	What 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.
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; the pipeline layer is transport-pluggable.
Deployment	The full platform ships as a Docker Compose stack — UI, backend, engine, trend store, brokers, optional YAMCS — for on-prem or cloud.

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