Real-data credibility
Implementation of the replay adapter and scorecards on your historical incidents — the first milestone, because it is the evidence that matters most.
SIMULATED DATA · RESEARCH / EVALUATION PROTOTYPE
EVALUATION & PARTNERSHIP
Measure it on your terms. No operational spacecraft connection required.
A structured path from first demonstration to a funded development and integration program — every stage on hardware you control, with no connection to any operational spacecraft or ground system required at any point.
SECTION INDEXE1E2E3E4E5
THE GROUND RULE
No connection to operational spacecraft is required during evaluation.
SpaceOps Twin’s evaluation model requires no live links of any kind. The platform ships with no uplink capability. Engagements run as standalone simulation on an isolated machine in your environment, and — when you choose — file-based replay of historical telemetry you export yourself. The evaluation is designed to run in an isolated customer-controlled environment.
THE ENGAGEMENT LADDER
Four steps, each valuable on its own.
01
Private demonstration
Thirty minutes.
The flagship scenario live: fifty spacecraft, one developing anomaly, ranked candidate causes, a deliberately injected unsafe plan rejected by the constraint layer, a refused approval on the record, verified recovery, verified audit chain. Deterministic — it runs the same way every time, which is rather the point.
02
Technical review
Half a day with your engineers.
Your team runs the machinery: the full test suite, the plane-separation leak tests, benchmark reproduction on your hardware with byte-level comparison, and a red-team hour against the safety gates via UI and API. Our limitations and validation registers are on the table from the start.
03
Structured customer evaluation
Four to six weeks, ~one part-time engineer on your side.
01
WEEK 0
Install from pinned dependencies on your isolated machine; everything green before we proceed.
02
WEEK 1 — REPRODUCIBILITY & METHODOLOGY
Re-run shipped 100- and 1,000-scenario campaigns and diff the results; audit metric definitions; red-team the approval gate and verify audited refusals.
03
WEEKS 2–3 — YOUR SCENARIOS, GRADED BLIND
Your operations engineers author mission-relevant fault scenarios in the scenario DSL — severities, onsets, and communications constraints you consider realistic. The stack is graded against hidden truth, and we review the results together, including the failures. Success thresholds are agreed before results are seen.
04
WEEKS 3–5 — HISTORICAL-TELEMETRY REPLAY
You export a small set of housekeeping points around one to three past anomalies, per the published replay specification. The stack processes them through the observation plane only, producing an honest scorecard: would it have flagged the anomaly, when, with what candidate ranking, at what false-alarm cost on your nominal data. Misses are reported as misses.
05
WEEKS 5–6 — GROUND-SEGMENT FIT & FINDINGS
Optional validation of the OpenC3 bridge against your COSMOS instance, telemetry direction first; then a joint findings review and a decision brief scoped from measured gaps.
04
Funded Development & Integration Program
Twelve to eighteen months, milestone-structured.
For organizations whose evaluation supports going further: a program to move the evaluated baseline toward customer-validated technology on your fleet’s data and ground segment.
THE PROGRAM
From evaluated prototype to customer-validated technology.
Aerospace validation
Your engineers validate or replace every modeled assumption — telemetry dictionary, safety envelopes, battery and wheel models, orbit and pass geometry — working from our published 12-item register, with sign-off per item.
Fault catalog & playbook expansion
Classes derived from your FMECA; recovery playbooks reviewed against your flight rules; compound-fault support.
Ground-segment integration
Live OpenC3 validation in your environment — telemetry direction live, command direction exercised exclusively against simulation.
Security & hardening
Access control, deployment packaging, independent penetration testing, and remediation — engineering toward accreditation-readiness without claiming accreditation.
Formal T&E exit
A benchmark campaign on your scenarios and replays, with thresholds registered in advance, executed by your team on your hardware, reported with full provenance — including any shortfalls, converted into documented gap plans rather than hidden.
Program scope, milestones, and commercial terms are provided in the private proposal materials following an initial evaluation conversation.
WHAT WE ASK OF YOU
A small, well-defined footprint.
One Linux machine you control (modest specification suffices). Roughly one engineer at quarter-to-half time during the evaluation, plus subject-matter sessions your team schedules. For the replay phase: exported telemetry for 10–20 housekeeping points around selected incidents, and your annotations of when the anomalies occurred. That’s the entire footprint.
OUR COMMITMENTS
The terms we hold ourselves to.
Every figure we show is scoped to its evidence: simulation results are labeled as simulation, always.
Success criteria are agreed before results exist, and results are reported against them — including misses.
We will tell you what the platform cannot do before you ask.
No claim of flight heritage, certification, government approval, or customer deployment will ever appear in our materials unless it is true.
If an evaluation shows the technology isn’t ready for your mission, you’ll have the measurements that prove it — and so will we. That is what evaluation-first means.
Start with a short walkthrough and a running system.
The demonstration is live, deterministic, and ends with the system refusing an unsafe command on the record. Bring your hardest questions — the honest answers are the product.