In January 2026, two things happened that changed how satellite operators think about collision risk. The Office of Space Commerce published the TraCSS verification dataset: open test data, with an answer key, for anyone who wants to build software that predicts whether two satellites will collide. A few days later, SpaceX unveiled Stargaze, a free collision-screening service powered by 30,000 star trackers across the Starlink constellation. In Europe, EUSST already provides conjunction screening for over 600 satellites. All three signal the same shift: tracking what is in orbit is becoming shared infrastructure, not a proprietary advantage.
I wanted to see what it takes to build a conjunction assessment system from scratch. I wrote an orbit propagator, a screening pipeline, and a 3D globe to visualise the results. The screening algorithm matches the TraCSS answer key (spherical hard-body test cases), and the whole thing runs in the browser.
Cosmos 1408
On November 15, 2021, Russia destroyed the Cosmos 1408 satellite with a missile. The debris cloud (over 1,500 trackable fragments) passed through the ISS orbit repeatedly. The crew sheltered in their escape capsules.
ISS (blue) and Cosmos 1408 debris (red) on November 15, 2021. Orbital elements are approximate (for illustration, not operational use). The animation starts 30 minutes before closest approach and runs at 60x speed. Drag to rotate, scroll to zoom.
This is the kind of event conjunction assessment exists to predict. Two objects in low Earth orbit approach each other at 10-15 km/s. Ground stations track both, but no position estimate is exact. Each one comes with an uncertainty envelope: not "the satellite is here", but "the satellite is probably within this region". Collision prediction takes those two uncertain positions at the moment of closest approach and computes a probability: how likely is it that the objects actually overlap? If the probability exceeds a threshold (typically 1 in 10,000), the operator fires thrusters to move out of the way.
The maths for computing that probability are well understood (a 2D integral over projected uncertainties, first published by Foster and Estes in 1992). The hard part is not the algorithm. It is knowing whether your implementation is correct. Getting a number is easy. Trusting the number requires open specifications you can read, and test data you can run your code against. Until recently, neither was easy to get.
Five components, one pattern
A conjunction assessment system needs five things:
Orbit propagation. Given a satellite's orbital elements (published as Two-Line Element sets on Space-Track and other catalogues), predict where it will be at any future time. The standard algorithm is SGP4 (Spacetrack Report #3), designed by NORAD in the 1980s and still the baseline for all catalogued objects. Vallado's Revisiting Spacetrack Report #3 is the modern reference; the TraCSS verification dataset provides test vectors.
Coordinate transforms. The propagator outputs positions in one reference frame, the collision geometry needs another, and the visualisation needs a third. Each conversion involves Earth rotation models and is easy to get subtly wrong. The IAU SOFA library documents the standard algorithms; Vallado's Fundamentals of Astrodynamics and Applications covers the practical implementation.
Message parsing. Collision warnings arrive as Conjunction Data Messages (CDMs), defined in CCSDS 508.0-B-1. A CDM contains the predicted time of closest approach, the miss distance, the relative speed, the uncertainty envelopes for both objects, and metadata about the data source. The CDM format is another CCSDS standard, similar to the ones I described in the wire formats post. There are at least three serialisation variants in active use (CSV from TraCSS, JSON from Space-Track, and the CCSDS text standard).
Probability computation. Project the two 3D uncertainty envelopes onto the plane where collisions happen (perpendicular to the relative velocity), then integrate the overlapping region. The result is a single number: the probability of collision. Foster and Estes (1992) describes the 2D method; the TraCSS dataset includes spherical test cases with expected results for validation.
Visualisation. Render the orbital geometry so an operator can see what is happening. Two satellites converging at 14 km/s look identical in a spreadsheet; on a globe, the crossing geometry is obvious. For an operator deciding whether to manoeuvre in a window of minutes, visual context matters.
The five components are standalone: I can test each one against its own reference data before connecting them. Without Vallado's test vectors I would not know if my propagator is correct; without the TraCSS dataset I would not know if my probability code gives the right answer. We learnt this in the MirageOS community when we built an email parser and had to release a corpus of a million messages because nobody had public test data. Open standards need open test data.
ssa.space
The result is ssa.space, a conjunction assessment dashboard. It loads the TraCSS verification dataset, propagates every tracked object, computes the collision probability for each close approach, and renders the results on a 3D globe. Close approaches are colour-coded by risk: red for dangerous, orange for watch-list, green for low. Click one to zoom in and see the orbital geometry at the moment of closest approach.
This runs on test data today (the TraCSS dataset includes difficult cases but is not live operational data). The entire stack is pure OCaml with no system dependencies, so it runs in the browser (via js_of_ocaml), on a server, and could run as a MirageOS unikernel on a satellite (the same architecture I described in the ASPLOS post). That is the direction we are pursuing with SpaceOS.
Today, collision avoidance runs through ground stations. A conjunction warning arrives 24-72 hours before closest approach, but the ground loop (downlink, screening, decision, command uplink) can consume most of that window. If the satellite runs the same screening algorithm on board, it can flag close approaches and pre-compute candidate manoeuvres before the next ground contact. The ground still approves, but time to first assessment drops to seconds.
What comes next
The application is live at ssa.space. The underlying libraries (sgp4, coordinate, cdm, collision, globe, cam) are work in progress and will be properly open-sourced when a full review is completed (currently validating against GMAT, NASA's General Mission Analysis Tool). The immediate goal is live data from TraCSS, Stargaze, or EUSST. If you have ephemeris data or screening results, get in touch.
