SPACEOPS TWIN
SIMULATED DATA · RESEARCH / EVALUATION PROTOTYPE

TECHNOLOGY DEEP-DIVE

Architecture built to be graded.

The design decisions behind SpaceOps Twin exist to make one thing possible: honest, reproducible measurement of AI-assisted operations — with deterministic safety constraints between every recommendation and every action. All performance references on this page derive from controlled simulation.

SECTION INDEXT1T2T3T4T5T6T7T8T9

TWO-PLANE ARCHITECTURE

Analytics that can be wrong can be measured.

TRUTH PLANEhidden ground truth · fault injection · dynamicsSpacecraft stateFault injectorConstellation simulatorOBSERVATION → ANALYTICSnoise · quantization · loss · pass latencyTelemetry frames onlyDetection · diagnosis · twinSafety gates · human approvalENFORCED BOUNDARY — IMPORT AUDITS + RUNTIME LEAK TESTStelemetry
01

The foundation is a hard separation between what is true and what is observed. The truth plane holds ground-truth spacecraft state, injected faults, and constellation dynamics. The observation plane is all the analytics ever see: telemetry frames governed by a dictionary of per-point sample cadence, sensor noise, quantization, yellow/red limits with persistence, and communication-pass latency including store-and-forward delay.

02

The boundary is enforced, not promised. Static import audits scan every analytics, safety, and fleet-management module for any path to truth-plane code — including dynamic imports — and runtime tests walk the live pipeline’s object graph after full scenarios to confirm no truth object is reachable. Any leak fails the build.

03

The consequence is the platform’s defining property: the analytics stack can miss faults. In our limits-only ablation baseline it misses more than half of them. That fallibility is what makes every score meaningful.

DETECTION STACK

Three deterministic channels, tuned against false alarms.

01

Limit engine. Classic mission-operations yellow/red limit checking with persistence counters and state-dependent limit sets (eclipse, sunlit, safe mode).

02

Physics residuals. Observed telemetry against nominal-parameter model predictions with CUSUM accumulation and winsorized innovations — including an eclipse discharge-slope channel that compares the observed battery discharge rate against a nominal-capacity prediction derived from observed bus load, detecting capacity fade and cell failure without direct capacity measurement.

03

Drift envelopes. Learned per-point nominal envelopes that tolerate orbit-periodic behavior, with recalibration on commanded configuration changes so expected operating-point shifts don’t raise alarms.

04

Across 142 nominal simulation runs in the current benchmark campaign, the stack produced zero false-positive cases. False-alarm cost is reported per satellite-day in every campaign, because a detection rate without its false-positive rate is marketing, not measurement.

DIAGNOSIS

The system says “candidate,” because that is what the evidence supports.

Detections group into cases via deduplication and causal grouping. Diagnosis scores each case against a versioned catalog of fault signatures spanning power, attitude-control, communications, and sensor fault classes. Output is a ranked list of candidate causes, each with its signature-match score and its evidence — the specific detections and model-parameter estimates that support it. Positive-evidence gating ensures no candidate ranks on absence of evidence alone. Operator-facing language never asserts a confirmed root cause.

DIGITAL TWIN

Estimated from telemetry. Forked for every what-if.

The twin maintains per-spacecraft parameter estimates derived purely from observation-plane data — effective wheel friction, battery capacity fraction and capacity-step indicators, healthy solar-string count, and desaturation timing inferred from observed momentum drops. What-if simulations run on forked copies: pure, deterministic, side-effect-free, with every output labeled as simulation. Twin fidelity is itself scored, and twin defects are discoverable by the T&E process — as our own benchmark triage demonstrated.

SAFETY LAYER

Deterministic constraints, applied without exception, within the evaluated environment.

01Recommendation02Closed Vocabulary03Constraints04Digital Twin05Human Approval06Audit

Every candidate plan — including injected adversarial plans — traverses the identical gate sequence.

01

Every candidate plan — playbook-generated, the mandatory do-nothing baseline, or externally injected — traverses the same pipeline: a closed, versioned vocabulary of ten recovery actions with typed parameter ranges, mode preconditions, prohibited states, mutual exclusions, risk classes, and ground-contact requirements; static checks for membership, parameter ranges and declarations, preconditions, exclusions, and redundancy availability; predictive checks in which twin-simulated trajectories must remain within hard envelopes — state-of-charge floor, battery and wheel thermal ceilings, momentum limit; and a human approval gate that re-validates at decision time, refusing and auditing non-compliant approvals.

02

AI-generated recommendations are restricted to the predefined action vocabulary and cannot bypass these deterministic constraint checks. Our adversarial test suite injects hostile plans — unknown commands, out-of-range parameters, plans engineered to violate envelopes — on every build; the campaign metric “out-of-policy plans executed” is asserted to equal zero and has been zero across every scored campaign to date. These properties are demonstrated within the evaluated simulation environment; carrying them into an operational context is the explicit subject of the development program.

AUDIT & PROVENANCE

Tamper-evident, verified, and honest about what that means.

Every step — telemetry digests, detections, case events, diagnoses, generated plans with their constraint results, approvals and refusals, commands, outcomes — is recorded in a SHA-256 hash-chained ledger. Verification tooling detects modified, deleted, reordered, or appended-forged records, in memory and on disk, and is exercised by dedicated tamper tests. This is tamper-evidence for engineering integrity, not a certified records system, and we make no regulatory claim.

THE T&E ENGINE

Scoring that joins conclusions to hidden truth.

01

The scorer is the single sanctioned consumer of truth data outside the truth plane. Per scenario it grades: detection and time-to-detection against injected onset; false positives on unfaulted spacecraft and pre-fault windows, normalized per satellite-day; top-1/top-3 candidate ranking against the injected class; mitigation (an approved action executed) separately from strict recovery (case closed, health restored) — separated because some degradations are mitigable but not recoverable, and conflating them hides exactly the failures an evaluator needs to see. It also reports perceived versus truth-referenced availability, spacecraft left in envelope violation, safety-gate integrity, and audit validity.

02

Campaigns are seeded, content-hashed, and reproduce byte-identically; 1,000-scenario runs execute in minutes via deterministic chunking, with the architecture sized for far larger studies. Reports ship in Markdown, HTML, and JSON with embedded provenance and an explicit limitations section.

INTEGRATION SURFACES

Designed to meet your ground segment where it is.

01

OpenC3 COSMOS bridge. Telemetry and command definitions are generated directly from the observation dictionary and the closed action vocabulary — a single source of truth — alongside lossless packet translation and a transport contract validated against a mock server. Live validation against a customer COSMOS instance, telemetry direction first, is a planned evaluation activity; inbound commands parse through the same closed vocabulary and approval pipeline.

02

Historical-telemetry replay (specified). A published interface for customer telemetry exports and incident annotations: file-based, observation-plane only, no resampling or silent gap-filling, deterministic outputs with hashed input provenance, and scorecards that list misses explicitly. Implementation is a defined early milestone of a funded engagement.

VERIFICATION & LIMITATIONS

What we test, and what we don’t yet know.

01

The baseline carries 114 automated tests: plane-separation and leak tests, determinism fingerprints, adversarial safety, audit tamper detection, detection-quality gates per fault class, twin purity, benchmark reproducibility, a 14-step flagship acceptance test, and a preserved 38-test regression suite from the original prototype.

02

Equally documented is what remains unproven: reduced-order physics with generic platform parameters; a closed six-class fault world; no validation against real telemetry; mock-only ground-segment validation; prototype security posture. A 12-item register maps every aerospace assumption to the artifact a customer’s engineers would validate or replace. We consider that register part of the technology.

Bring your engineers. Bring your hardest questions.