Conjunction Screener
Conjunction screening checked against a government answer key
August 2026
I don't work in aerospace. That is the reason this project exists in the shape it does.
Most software written about space cannot be checked. It computes where satellites will be, which pairs will pass dangerously close — and produces numbers no outside reader can verify. You accept them because of who published them. From outside the field that is an uncomfortable thing to build into: I would have no way of knowing whether my own code was right, and neither would anyone reading it.
In March 2026 the US Office of Space Commerce published a verification dataset for conjunction assessment. One week of orbit data for 26,789 objects, and the correct list of the close approaches their validated tool found in it — 913,330 of them. Public domain. It exists so that anyone building this kind of software can find out whether theirs works.
Conjunction Screener reads the same data and produces its own list. This is what the scoring program prints when it compares the two, unedited:
answer key : 913,330 unique conjunctions (by pair, epoch, source files)
ours : 913,329 events
matched : 913,329 (99.9999% recall)
missed : 1
extra : 0 (found by us, absent from key)
bucket in key matched recall in tol tol p50 err p99 err max err
NLRV 910,766 910,766 100.000% 910,764 0.001 0.0003m 0.0028m 1.5520m
LRV 1,259 1,259 100.000% 1,225 0.010 0.0104m 127.2221m 168.7333m
VLRV 1,305 1,304 99.923% 1,304 10.000 4.8961m 457.5292m 8009.2918m
(err columns are TCA error in milliseconds)
miss distance error (m): p50 0.000067 p99 0.005090 max 1.223235
One conjunction missed, nothing invented. The three rows group encounters by how fast the two objects pass each other, because that governs how sharply the moment of closest approach is defined at all — when two objects drift past one another slowly, the distance between them barely changes for a long stretch and the closest instant is genuinely blurry. The tolerance column is the agreement the benchmark asks for in each group. Median timing error across all 913,329 matches is 293 nanoseconds.
How it avoids checking 359 million pairs
26,789 objects is 358,811,866 possible pairs, and when is a continuous question with no smallest unit. Checking all of it isn't slow, it's impossible.
So the screener samples time every two seconds — 302,401 steps across the week — and at each step drops every object into a grid of imaginary cubes, comparing only those in the same or touching cubes. Almost everything is discarded without ever being measured.
The obvious hole is that the closest approach almost never lands on a sample. It happens between two of them, and at both the objects look further apart than they truly got.
What closes the hole is a limit that can't be violated: two objects cannot close on each other faster than their combined speed. Two satellites at 7.6 km/s can eat at most 15.2 km of gap in the one second between a sample and the true closest moment. So a pair that came within 10 km in between was within 26.2 km at the nearest sample:
guard radius = 10 km + (speed_a + speed_b) × half a step + 1 km
= 10 km + 15.2 km + 1 km = 26.2 km
Flag everything inside that radius and a conjunction has nowhere to hide. It isn't a heuristic that usually works, it's a bound — and the speeds come from the catalogue rather than from an assumption. 359 million pairs collapse to 5,932,497 candidate intervals, and the exact arithmetic runs only on those. The full week takes six hours on a laptop with 8 GB of memory.
How the grading was attacked
A benchmark score is a claim you make about your own work, graded by your own program. So the grading was attacked before the result was written down.
Matching computed encounters to official ones needs a time window. Make it generous and unrelated events start pairing up, and the score measures the window instead of the work. Tightening it from ten seconds to one millisecond — ten thousand times stricter — costs 959 of the 913,329 matches. One tenth of one percent. The events genuinely coincide.
The stronger evidence is where the failures sit. Thirty-six encounters were found but timed outside tolerance. Thirty-four of them pass at between 10.4 and 11.5 m/s, inside a band running from 10 to 50 — all of them hard against its lower edge, where crossing one decimal place loosens the required precision by a factor of a thousand. The other two sit just above the next boundary up. None is in the screening geometry.
What it doesn't do
It misses one conjunction. This is the row the program wrote for it:
obj_a,obj_b,tca_s,min_range_km,vrel_ms,bucket,file1,file2
95146,95147,245339.019327,0.019545,0.018,VLRV,95146.ocm,95147.ocm
Two objects 19.5 metres apart, drifting past each other at 1.8 centimetres per second. The answer key records two closest approaches 76 seconds apart and the screener finds one. Position accuracy is about a metre here, which is five percent of the distance between them.
It doesn't compute collision probability. It doesn't ingest live tracking data. It has no interface. It runs on one week of one dataset, because one week is what the answer key covers, and it has never been pointed at operational data. The code is not public, so the result is reproducible in principle and not yet in practice.