SIMULATED DATA · RESEARCH / EVALUATION PROTOTYPE

SIMULATION-FIRST TEST & EVALUATION

A safer way to test, measure, and trust constellation autonomy.

SpaceOps Twin grades AI-assisted satellite operations against hidden ground truth — detection, diagnosis, recovery, and safety — in reproducible, benchmarked simulation campaigns. Before autonomy touches a mission, it should have a score.

Request a Private EvaluationWatch the Demo

011,000-scenario campaigns

0250-satellite flagship

03Deterministic replay

04114/114 automated tests

EVALUATION BASELINE

THE PLATFORM

A flight simulator, a testing lab, and a mission assistant — in one instrumented environment.

SpaceOps Twin simulates an entire satellite constellation, quietly injects faults, and challenges an AI-assisted operations stack to find them, explain them, and recover from them — safely, under human approval, with every step scored and recorded.

The Simulator

Up to 100 spacecraft with operational-style telemetry effects. The environment models operational effects such as sensor noise, quantization, dropped packets, and ground-pass delays.

The Referee

Because the platform holds the ground truth it injected, every claim gets graded: what was detected, how fast, how accurately, at what false-alarm cost, and whether recovery actually worked.

The Assistant

Anomaly detection, ranked candidate causes with evidence, digital-twin tested recovery options — always constrained by deterministic safety rules, always subject to human approval.

THE PROBLEM

Constellations are scaling faster than operations teams.

Every year, fewer operators watch more spacecraft. Anomalies arrive subtly — a wheel current drifting milliamps at a time, an eclipse discharge running slightly steep — and the cost of catching them late is measured in lost capability and lost assets.

Autonomy is the obvious answer, and the hardest one to adopt. An operations team cannot delegate to a system it cannot measure, and it cannot certify a system that might act outside flight rules. Most AI tooling asks for trust. Aerospace requires evidence.

SpaceOps Twin was built in the opposite order: the proof machinery first, the assistant second.

THE WORKFLOW

From hidden fault to verified recovery — every step observable, every step scored.

01
Simulate
A seeded constellation runs with realistic, degraded telemetry.
02
Inject
A fault enters the hidden truth state. The analytics are never told.
03
Observe
The analytics stack sees only observation-plane telemetry available within the simulated environment.
04
Detect
Limit checks, physics residuals, and drift envelopes flag the anomaly.
05
Rank
Candidate causes are ranked with evidence — never a declared “root cause.”
06
Plan
Recovery strategies are generated, alongside a mandatory do-nothing baseline.
07
Constrain
SAFETY GATE
Every plan passes deterministic safety checks. Out-of-policy plans are rejected and the rejection is recorded.
08
Twin-test
Valid strategies run in a forked digital twin; predictions are labeled as simulation.
09
Recommend
The lowest-risk valid option is proposed.
10
Approve
A human decision gates execution. Approval of a non-compliant plan is refused.
11
Verify & record
Recovery is verified, fleet health updates, and the full sequence lands in a tamper-evident audit chain.

Deterministic by construction: the same scenario and seed reproduce the same run, byte for byte.

TWO DEPTHS, ONE SYSTEM

One system, explained at your depth.

How would you know an AI operator actually works?

You’d test it the way pilots are tested: in a simulator, against failures it doesn’t see coming, with an instructor holding the answer key. That’s SpaceOps Twin. It creates a fleet of simulated satellites, breaks them in realistic ways, and watches whether the operations software notices, explains the problem correctly, and proposes a fix that’s actually safe. Because the platform knows what it broke, it can grade every answer.

And how would you know it’s safe?

The software can only recommend actions from a fixed, pre-approved list — it cannot invent commands. Every recommendation is checked against hard safety rules before a human ever sees it, and a person approves every action. When we deliberately fed the system dangerous plans during testing, the safety layer rejected them and logged the refusal.

THE FLAGSHIP SCENARIO

Fifty satellites. One developing anomaly. Fourteen verified steps.

The flagship demonstration runs the complete operational story end to end — deterministically. Same seed, same outcome, every run.

PLAYBACK DECK

Request a Private Evaluation

MISSION LOG

01
T+0
50 spacecraft nominal. Fleet availability 100%.
02
T+6000 S
A wheel-bearing degradation begins on SAT-17 — in hidden truth only.
03
+145 S
Detection. A physics residual flags wheel current against the model prediction.
04
PRIORITIZATION
SAT-17 tops the fleet queue. The other 49 remain nominal.
05
EVIDENCE
Candidate causes ranked with signature-match scores. Top candidate: wheel friction degradation.
06
PLANNING
Three recovery strategies, plus the do-nothing baseline — which the twin predicts will violate the momentum envelope. Rejected.
07
ADVERSARIAL BEAT
A deliberately unsafe plan (wheel overspeed) is injected. The constraint layer rejects it.
08
THE REFUSAL
An approval attempt on the unsafe plan is refused by the system and written to the audit chain.
09
APPROVAL
The recommended plan is approved by the human role and executes at ground contact.
10
RECOVERY
Verified. SAT-17 returns to nominal. Availability 100%.
11
THE RECORD
Hash-chained audit verifies end to end; the T&E engine grades the run against hidden truth: detected, top-1 correct, recovered, zero out-of-policy executions.

MEASURED, NOT CLAIMED

Benchmarked across 1,000 controlled simulation scenarios.

CONTROLLED SIMULATION RESULTS — NOT FLIGHT VALIDATION

All figures below are simulation benchmark results from seeded, controlled campaigns on synthetic spacecraft data — not flight validation, and not performance on real telemetry.

CAMPAIGN

1,000-scenario campaign — 858 fault scenarios across six fault classes, 142 nominal.

CAMPAIGN RESULTS

98.4%

Anomaly detection rate

97.3%

Correct top-1 candidate cause

False positives across 142 nominal simulations

Out-of-policy plans executed

1,000 / 1,000

Audit chains verified

Satellite flagship scenario, ~2,800× real time

VERIFICATION114/114 automated tests passingByte-identical campaign reproductionFull provenance embedded in every report

MATCHED COMPARISON

What the analytics stack adds

On 100 identically seeded scenarios, we ran the same environment twice: once with classic limits-only monitoring, once with the full SpaceOps Twin analytics stack.

METRIC (100 MATCHED SIMULATED SCENARIOS)	LIMITS-ONLY BASELINE	FULL STACK
Detection rate	45.4%	98.8%
Correct top-1 candidate cause	45.4%	98.8%
Median time-to-detection	2,035 s	1,235 s

BENCHMARK TRIAGE FINDING

The referee caught our own defect

During benchmark triage, the T&E engine surfaced a defect in our own digital twin: forked plan simulations mis-predicted momentum behavior, causing valid recovery plans to be wrongly rejected. Correcting it raised the campaign mitigation rate from roughly 43% to 99%. This is the point of evaluation-first engineering — the grading machinery finds what demonstrations hide, including in our own code.

REPRODUCIBILITY

Every campaign re-runs from a single command and reproduces deterministically. Evaluators run the benchmarks themselves.

SAFETY BY CONSTRUCTION

Deterministic constraints between every recommendation and every action.

SpaceOps Twin uses deterministic safety constraints to prevent out-of-policy actions within the evaluated environment. The safety layer is ordinary, inspectable logic — not a model, not a prompt — and it sits between all recommendation components and execution.

CONSTRAINT CHAIN

AI Recommendation

Recovery strategies proposed by the analytics stack — the input, never the authority.

Closed Action Vocabulary

Ten versioned recovery actions with typed parameter ranges, mode preconditions, and exclusions. AI-generated recommendations are restricted to this predefined vocabulary and cannot bypass the constraint checks.

Deterministic Constraints

Static rule checks: vocabulary membership, parameter ranges, preconditions, mutual exclusions, redundancy availability.

REJECTED

Digital Twin

Every candidate plan — including the do-nothing baseline and any externally injected plan — must remain within hard envelopes for state of charge, thermal limits, and momentum.

Human Approval

The approval gate re-checks at decision time and refuses non-compliant plans. Refusals are recorded.

Audit

Every constraint decision, refusal, approval, and outcome enters a hash-chained ledger with verification tooling.

EVIDENCE

Across more than 1,100 scored simulation scenarios — including deliberately injected adversarial plans — zero out-of-policy plans have executed within the evaluated environment. That figure is asserted automatically in our test suite on every build.

SCOPE

These guarantees apply to the evaluated simulation environment. Extending them to operational systems is precisely the work of a structured evaluation and development program.

THE CORE PRODUCT

The heart of the platform is the referee, not the dashboard.

Because SpaceOps Twin injects faults and holds ground truth, every operational claim can be scored — automatically, repeatedly, and honestly. That turns “trust our AI” into “here is its measured performance on your scenarios.”

WHAT THE REFEREE SCORES

Detection rate

False positives per sat-day

Time-to-detection

Top-1 / Top-3 cause ranking

Mitigation vs strict recovery

Out-of-policy rejection integrity

Audit validity

Deterministic reproducibility

Campaigns scale from 10 scenarios to 1,000 in a single command, with an architecture demonstrated for far larger runs through deterministic chunking. Every report — Markdown, HTML, JSON — embeds its provenance: code version, configuration hashes, seeds, scenario content hashes, timestamps, and limitations. The same engine that graded our stack against a limits-only baseline is designed to grade it against your scenarios, and eventually your historical telemetry.

An evaluation platform that can fail its own product in public is one you can calibrate your trust against.

UNDER THE HOOD

Two sealed planes. One deterministic spine.

Instrumented throughout by the T&E Engine, with integration surfaces for OpenC3 COSMOS and a historical-telemetry replay interface.

Built to be inspected. The full architecture, verification posture, and limitations register are documented for technical review.

Read the Technology Deep-Dive →

WORKING WITH US

A structured path from first look to funded development — no connection to operational spacecraft required.

Every engagement stage is standalone-simulation or file-based replay on hardware you control. No connection to operational spacecraft is required during evaluation, and at no stage does SpaceOps Twin command or influence any operational spacecraft or ground system.

ENGAGEMENT STAGES

STAGE 01

Private demo

The flagship scenario, live — including the safety-refusal sequence. Thirty minutes.

STAGE 02

Technical review

Your engineers audit the methodology: separation tests, benchmark reproduction on your hardware, red-team of the safety gates, our limitations register on the table.

STAGE 03

Customer evaluation

Four to six weeks. Your team authors mission-relevant scenarios in our DSL and grades the stack blind; a defined path exists to replay your historical telemetry through the observation plane.

STAGE 04

Funded Development & Integration Program

A milestone-structured program to move the evaluated baseline toward customer-validated technology: replay of your fleet’s data, engineering validation of every modeled assumption, ground-segment integration, hardening, and a formal T&E campaign your team runs itself.

Request a Private Evaluation

DIRECT ANSWERS

Direct answers to the questions that matter.

QUESTION REGISTER

No. SpaceOps Twin ships with no uplink capability and no ground-station drivers. All results come from controlled simulation, and the evaluation model is standalone simulation plus file-based replay of historical data on hardware you control.

BEGIN

See it run. Then measure it yourself.

A private technical walkthrough takes approximately 15 minutes and ends with a refusal — the system declining an unsafe plan, on the record. If that’s the kind of autonomy evidence your program needs, the next step is a conversation.

DIRECT CONTACT

Request a Private EvaluationView Technology

This site has no contact form backend. The address below is a direct mailbox — mail reaches a person, not a queue.

CONTACT ROUTES

FOUNDERFaisal AhmedFounder, SpaceOps Twinfaisal@spaceopstwin.com