C shows a mission the way the ground sees it. X builds it the way the spacecraft sees it: goal-driven execution, its own recalculation of manoeuvres, an understanding of what is around it. Where autonomy, intelligence and negotiation are tested and validated.
OPERATING SYSTEM FOR COLLABORATIVE AUTONOMY
X
The spacecraft's own view of the mission
every cooperative manoeuvre clears an independent check before it executes
Spacecraft are starting to decide for themselves. There is a need to test whether those decisions are safe before flight.
Capabilities
- Mission & CONOPS Simulation
- Cross-Vendor Translation
- Independent Go/No-Go Checks
- Close-Proximity Operations Modelling
- Mission Dynamics
- Evidence & Review-Board Reporting
Web based. Nothing to install, shareable across your team, reachable from anywhere.
Who needs it
Each of these markets is moving decisions on board.
| Market | What has to be proven |
|---|---|
| In-orbit servicing, refuelling and debris removal | approach, capture and docking decided on board |
| Constellations and swarms | many craft coordinating with no ground in the loop |
| Space traffic and interoperability | craft from different operators agreeing on a manoeuvre |
| Defence and security | autonomous responses that have to be provably safe |
What X is
Built on infrastructure that allows several spacecraft at once, so you can build a swarm and watch it behave, or put one craft into an ecosystem of autonomous objects and see it cooperate and negotiate. The question X answers is how it reaches the goal, and whether it stays safe getting there.
BUILT AND PROVEN IN ONE ENVIRONMENT
Mission autonomy, the negotiations between spacecraft, the go/no-go logic and the close-proximity manoeuvres are developed where they are tested.
REAL PHYSICS, DELIBERATE FAILURE
Everything runs against real physics and engineered failure until behaviour becomes evidence.
PROVING GROUND BEFORE FLIGHT, INDEPENDENT CHECK IN FLIGHT
The same environment that proves the mission rehearses every decision once the spacecraft are flying.
VENDORS TRANSLATED
Because X translates between vendors, machines that were never designed together are tested and trusted as one mission.
THE PILOT
Autonomous mission pilot
| The pilot | We are looking for the first pilot users. Your mission, built in X, tested from the spacecraft's side, with your engineers in the loop. Seats are limited by how many missions we can build ourselves. |
|---|---|
| Price | on demand |
| First build | First build underway: RAVEN (PIAP Space), co-developed with Telespazio Germany. |
X runs on our own orbital dynamics engine, measured against real satellites to about 2.5%. How we checked
INSIDE X
Autonomous missions need testing Testing is X
Translation is how X lets different vendors' spacecraft understand each other. What it enables is the testing of autonomy, close-proximity operations, the risky cooperative missions where spacecraft must coordinate and negotiate.
Commands from Vendor A, Vendor B and Vendor N arrive in different dialects and pass through three stages inside X, where TRANSLATE turns them into one common protocol, NEGOTIATE lets the spacecraft agree an approach and VERDICT gives a go or no-go that is checked independently, after which EXECUTE runs only what passed and a NO-GO is stopped before it reaches the spacecraft.
X SOLVES
No shared coordination layer
multi-vendor spacecraft are unable to interoperate safely
Uncertainty of autonomy
black-box decisions introduce risky cooperation between spacecraft
THE PROGRAMME
Who fits
- Primes and defence teams building multi-vehicle operations
- In-orbit servicers whose CONOPS depend on autonomy
- Constellation operators with assets they wish they could upgrade
What a partner commits
- Mission requirements and reference data for one real vehicle or mission
- An engineering model or interface definitions, enough to build against
- Regular review time with our engineers
- An MoU, and an agreed funding route
What a partner gets
- A NextGen Twin built against your real mission, not a demo
- Direct influence on the fidelity roadmap
- Priority access at release, on founding commercial terms
- First option on the Hybrid Loop deployment demonstration
WHERE IT LEADS
The NextGen Twin
Software that keeps improving after launch
Next comes the NextGen Twin: the same work against your actual vehicle. It is in development and the pilot users shape it.
IN DEVELOPMENT · OPEN FOR EARLY ADOPTERS
NextGen Twin
A physics-native digital twin of your spacecraft with added autonomy and intelligence as required by autonomous cooperative and other complex missions. It is the bench where autonomy is trained and validated and allows you to become part of the ecosystem and be ready for the in-orbit services. It is built against your mass, your actuators and your constraints.
Two spacecraft glyphs side by side. On the left, drawn in solid lines, your spacecraft, labelled flying. On the right, drawn in dashed red lines, its twin, labelled physics-native and per-vehicle. An arrow runs left to right carrying telemetry and design, and a second arrow runs right to left carrying validated updates. Below, three steps: train, validate, deploy.
Hybrid Loop
Create, Analyze, Optimize, Deploy. The cycle in which flight data from the real spacecraft flows back into the twin. The loop is applied at the testbed or after launch. It turns a one-off validation into a service that keeps improving your spacecraft.
A ring of four steps running clockwise, Create then Analyze then Optimize then Deploy, with an arrowhead on each arc showing the direction of travel. At the centre, inside a dashed red circle, sits the flying asset the loop exists to keep improving.
Autonomy validation. Proving a plan holds across a designed failure campaign is in development, and we are looking for design partners whose real mission becomes the first case.
APPLY