Test evidence for every unit you build, traced to the requirement.
Steriod reads the specifications, ICDs and mission database you already have, drafts one executable check per verifiable requirement, and your engineer approves each one. The approved checks run over the recordings your checkout system or bench already produces, for every unit and every campaign. At launch, the same checks move unchanged into operations monitoring.
- No change to your EGSE, DAQ or mission control: we read what they record
- Every check cites its clause; every approval is a person, on the record
- Requirements that cannot be checked from telemetry are reported, not invented
You are building more units with the same team, and every unit needs evidence.
Serial production, flat headcount
Series of tens to hundreds of satellites a year multiply test reports, not test engineers.
Checks live in scripts
Limit checks sit in sequencer scripts, Python suites and LabVIEW or MATLAB post-processing. The requirement owner never reviews them.
Evidence assembled by hand
A test report per unit takes days of engineer time, and the unit that deviates from its siblings is spotted late, if at all.
Errors found late cost 21 to 78 times more
A requirement error found in integration and test costs 21–78× what it costs at the requirements stage (NASA JSC, Stecklein et al. 2004).
Deliverables, not a dashboard.
Items marked Pilot support are delivered with the pilot, configured for your programme by our team.
| Deliverable | What it is |
|---|---|
| Executable requirement set | One readable rule per verifiable requirement, each citing the clause it came from. Drafted by an LLM from your documents, approved one by one by your engineer. Approval is human-only; no agent and no API can approve. |
| Coverage and gap report | Which requirements are covered by a check, which cannot be verified from telemetry and why, where two documents contradict each other, and which signals the documents mention that your database does not carry. |
| Evidence per run | For every recorded test run: pass, fail or not exercised per requirement, the exact time spans, the samples behind each verdict, and an audit trail of who approved what and when. |
| Verification Control Document and test reportPilot support | Generated from the evidence, structured along ECSS-E-ST-10-02C Annex B, with the clause cited per line. Files you attach to your review. |
| Cross-unit viewPilot support | The same rule set replayed over every serial unit, so the unit that deviates from its siblings is visible before shipment. |
| Investigation on failure | A failing check opens an investigation that shows which signals moved, which commands preceded it, and which requirement is affected. |
| Hand-over to operations | The approved rule set, unchanged, running on the live telemetry feed after launch. Bench evidence and in-orbit evidence come from the same checks. |
From a stack of documents to signed checks.
An AOCS and power demonstration mission, built from its requirements export, ICDs and XTCE database.
Your engineer reviews each rule next to its clause.
Keyboard-driven: approve, edit, or reject with a note. The note is required, and the next drafting run reads it.
The rule is the requirement, in a form a machine can run.
"If the standard deviation of pointing error over 30 s exceeds 0.050° outside slews, the degraded flag shall be set within 20 s." Readable by the requirement owner, compiled and type-checked against your signal catalogue.
What cannot be checked from telemetry is said out loud.
"Run-in duty cycle of each wheel before delivery" is a manufacturing record, not flight telemetry. Steriod classifies it as not verifiable instead of inventing a check.
Six steps, and the last one is launch.
1 · Import
Specifications, ICDs, the mission database and a few recorded test runs. Each requirement becomes an artifact with a quality score against its source document.
2 · Draft
The LLM proposes a rule per verifiable requirement and says which it cannot express. Every rule compiles and type-checks before anyone sees it.
3 · Approve
Your engineer approves, edits or rejects each rule next to its clause. Every change is audited.
4 · Execute
The deterministic engine runs the approved rules on the recorded runs. No AI in this step; the same verdict on a laptop, the server and the embedded C runtime.
5 · Report
Coverage matrix, per-run evidence and test reports. A failure opens an investigation with the signals, commands and requirement involved.
6 · Carry over
At launch the pipeline switches from recorded runs to the live feed. Nothing is rewritten.
We sit on top of your checkout system and read what it records.
| You run | How Steriod connects | Stays untouched |
|---|---|---|
| Terma CCS5 / TSC with a SCOS-2000 MIB | MIB imported as the signal vocabulary Pilot support; recordings read from CCS5 retrieval exports (tsv, csv, json) Pilot support | Your test sequences, procedures and archive |
| Celestia EGSE, CONNEKTICA, other sequencers | Recorded measurements through their file export, REST or Python API; or a live tap on the EDEN / C&C stream Pilot support | Your sequences, SCOEs and instrument drivers |
| In-house Python test suite | CSV / JSONL export, or your suite publishes to Kafka or MQTT. The embedded C runtime can also be called from inside your suite. | Your suite and your ground software |
| Benches with LabVIEW, Python or MATLAB post-processing | Post-test CSV and TDMS files read as recorded runs Pilot support; later the same rules run live on the bench controller through the embedded C runtime | Your DAQ, your rig controller |
| Yamcs | XTCE mission database imported directly; parameters forwarded by Steriod's Yamcs-to-MQTT connector; rule panels shown in a Yamcs web tab | Your Yamcs instance and its alarms |
| Documents in Word, PDF, DOORS or Polarion | PDF and Word imported as they are; DOORS and Polarion through ReqIF or CSV export Pilot support. No re-modelling of your system in our tool. | Your requirements management |
Deployment: a single on-premises node (Docker Compose on one Ubuntu server or a strong laptop), inside your network, no cloud dependency. The LLM steps run on an open-source model on your hardware or on a European cloud, your choice. The execution path has no AI in it.
Where the hours go back.
| Lever | Today | With Steriod | Basis |
|---|---|---|---|
| Verification scripting and maintenance | About 4 engineering hours per requirement over development and test | About 0.5 h per requirement for review and sign-off: 87.5 % less | Steriod ROI model, illustrative, assumptions stated |
| Evidence per serial unit | Hand-assembled report, days of engineer time | Replay of the approved rule set: minutes of machine time plus review | Measured: a 101-million-sample year scanned in 1.5 s |
| Late-found requirement errors | 21–78× more expensive in integration and test | Requirements execute against the first recording | NASA JSC, Stecklein et al. 2004 |
| Bench to operations | Monitoring limits re-implemented by the operations team | The same approved rules, no rewrite | Identical verdicts on the server and C runtimes, differential-tested |
In our own automotive work, a high-voltage-coordinator verification went from about two weeks of hand-coded automation to minutes of rule writing.
One programme, two units, six weeks.
| Week | What happens |
|---|---|
| 1 | Node installed on your premises; documents and mission database imported; signal catalogue reconciled with your recordings |
| 2 | Rules drafted; first approval session; coverage and gap report |
| 3–4 | Rules replayed over all provided runs; evidence reviewed; rules refined; cross-unit comparison |
| 5 | Test report generated for one campaign; investigation walk-through on one real failure from your archive |
| 6 | Hand-over: the approved rules, the evidence, the reports and the node are yours; decision on roll-out and operations carry-over |
What we need from you
- One specification or verification matrix (PDF or Word), and the ICD or mission database for one programme
- Recorded test runs for two or more units or campaigns, in whatever format your system exports
- One engineer for about half a day a week, to approve rules and read the evidence
What this is not
- Not a checkout system, an EGSE or a mission-control system
- Not a packet decoder: we consume decoded parameters
Priced as a fixed pilot fee, quoted on scope. The rule set and the evidence stay with you, whatever you decide afterwards.
Bring one specification and one recording.
We will show you the coverage, the conflicts and the first evidence on your own data. Or book a meeting with us at Space Tech Expo Europe in Bremen, 17–19 November 2026.