SpaceX runs a conjunction screening service that is free to satellite operators and

returns a result in under a minute. The file format it falls back to by default is

specified in two paragraphs and a screenshot, on page 20 of a handbook published by a US

Space Force squadron.

That is not a complaint about SpaceX. It is the shape of the orbital data layer as it

actually stands, and anybody planning to consume ephemeris at scale should know which

of these documents is a standard and which is a description of a script.

The immediate occasion is a push for reciprocity. The Register reported on 7 October 2026

that Starlink encountered conjunctions with about 650 unique manoeuvring third-party

satellites during 2026 and that only about half of those shared ephemeris, and that over

six months it observed roughly 164,000 conjunctions where closest approach fell within

four hours of an unannounced manoeuvre. Those figures are attributed to Starlink's own

space safety update. That page is client-rendered and did not return readable content to

this run, so the two numbers above are second-hand and BeamDesk has not verified them

against the primary. Everything that follows was read first-party on 18 October 2026.

What is actually on offer

The platform documentation at docs.space-safety.starlink.com describes, in its own

words, low-latency conjunction screening against both user-submitted data and

observations made by the Stargaze space situational awareness system, with results

typically available less than a minute from trajectory submission. The overview page

states that the platform is "always free of charge to participating spacecraft

operators", and immediately afterwards that "Currently, use of the API is limited to

satellite operators." Onboarding is a human process: the documentation gives an email

address at SpaceX and nothing self-service.

Separately, and with no key at all, Starlink publishes its own fleet's ephemerides. The

README at starlink.com/public-files/ephemerides/ gives the terms: Modified ITC format,

carrying position and velocity covariance, 72 hours of prediction, refreshed every eight

hours, with a MANIFEST.txt acting as the directory listing. For the file naming

convention and the format itself, the README points at the Spaceflight Safety Handbook

for Operators, version 1.7, on space-track.org.

The platform's own collision avoidance article is worth reading for scale. It documents

over a thousand avoidance manoeuvres a day, planned and executed without humans in the

loop, with probability-of-collision criteria of 3e-7 for healthy satellites and 1e-6 for

satellites in orbit transfer, and a miss distance box of 100 m radial by 1500 m

along-track and cross-track in the RTN frame. All of these are documented figures from

the operator, not measurements by anyone else.

The format under it is a squadron handbook page

The trajectory upload accepts several formats and identifies them by sniffing the file

header. A file beginning CCSDS_OEM_VERS is read as an Orbit Ephemeris Message. One

beginning CCSDS_OCM_VERS is read as an Orbit Comprehensive Message. Both of those are

defined in CCSDS 502.0-B-3, Orbit Data Messages, Blue Book, April 2023, whose cover was

read first-party today. A file containing the string JSpOC Format Ephemeris Report gets

one parser, a file with time, pos.x and vel.x headers gets another, and a file whose

epochs start in the squadron day-of-year style gets a third. Anything that matches none of

these is treated as Modified ITC. The standard format is the special case. The

unstandardised one is the default.

So it matters what Modified ITC is. The Spaceflight Safety Handbook for Satellite

Operators, version 1.7, April 2023, published by the 18th and 19th Space Defense

Squadrons at Vandenberg Space Force Base, defines it on page 20. The definition is one

paragraph of prose, one figure, and one paragraph describing a program. The prose says

the format is "the only format that is required to contain both positional and velocity

covariance data in addition to ephemeris data", that it carries four descriptive and

header lines of which the fourth gives the orbital reference frame of the covariance,

and that each point is one state vector line followed by three lines holding the

twenty-one values of the 6x6 lower triangular covariance matrix.

The figure is a screenshot of the file open in an emacs window. The remaining normative

content is a description of what the tooling does with the bytes: the handbook says the

preprocessing script "reads the data lines in groups of four and separates the entries on

each data line wherever one or more space" characters are found. That is a specification

in the sense that you could implement against it. It is not a grammar, it has no field

widths, it states no units, and it is silent on the thing that bites first.

The thing it is silent on is the frame of the state vector. Page 20 names a reference

frame only for the covariance. It never says which frame the position and velocity are

in. Starlink's API reference closes that hole by convention rather than by citation: an

OEM upload may carry position and velocity in ITRF or EME2000, while a Modified ITC

upload must be EME2000, with covariance in UVW, RTN, RSW, EME2000 or J2000. Note that

list. UVW and RTN are the same frame under two names, and the handbook says so itself on

the facing page. EME2000 and J2000 are, for this purpose, two more. A parser has to know

that before it can be correct, and no document in this chain says it in a normative

sentence.

The contrast on the next page is the sharpest part. For the CCSDS format, the same

handbook does not attempt a definition at all. It tells the reader to "refer to please

visit the Consultative Committee for Space Data Systems (CCSDS) website and reference the

'Orbit Data Messages' Blue Book". That is exactly right, and it is what a standard is

for. The handbook defines the format that has no owner and delegates the one that does.

The case against making anything of this is real and should be stated. A format defined

by an example is adequate when there is one producer, one consumer and a shared parser,

and that was the situation when the handbook was written. The output that matters is the

screening result, not the file. CCSDS conformance buys interoperability, and

interoperability is only worth paying for when more than two parties need it. The reason

to care now is that the number of parties went up. The publisher of the largest

constellation in orbit is asking every other operator to feed the same pipe, which turns

a bilateral convention into something closer to infrastructure.

Three places the documentation disagrees with itself

Anyone implementing against this will hit all three. The tutorial page gives two upload

types, definitive and hypothetical. The endpoint reference for POST /v1/trajectory gives

three, adding candidate, and does not explain it. On covariance, the tutorial says

covariance is recommended but not required, and that omitting it yields null collision

probability values in the resulting conjunction data messages. The endpoint reference

says the upload requires a minimum of six data points with accompanying covariance and

that all position covariance must be non-zero. Those cannot both be true. On frames, the

tutorial lists ITRF as preferred with EME2000 and ITRF2000 also accepted, while the

endpoint reference splits the permitted frames by file format as described above.

The rest of the envelope is consistent and worth writing down: at least six state vectors

in the future, a span between 42 seconds and 21 days, velocity below 70 km/s, positions

above the surface, UTC only with GPS time explicitly unsupported, and a file body under

31,458,780 characters.

What it costs to adopt

Nothing in money, and that is the headline. The cost is in three other currencies.

The first is eligibility. The documented gate is being a satellite operator, decided by a

person at an email address. An operations or market layer that is not itself flying

hardware has no documented route to a key. The public ephemeris mirror has no gate at

all, so for the narrow job of knowing where those satellites are, the integration is one

parser and a manifest.

The second is disclosure. The platform documents that a definitive trajectory is inserted

into the catalogue and visible to all users, where a hypothetical one is screened once

and visible only to the submitter. That is a sensible design and it is the point of a

sharing platform. It is also a decision: your planned trajectory becomes readable by

every other participant, including the party operating the platform. The same

documentation argues the case for that openly, telling operators that ephemeris "should

not be treated as proprietary information, it is critical for safe flight."

The third is the parser. Modified ITC is not hard. It is ten lines of code and a

reference frame you have to know by folklore. The question is whether you want that in

your dependency graph with no issuing body to point at when it changes.

For what it is worth on this side: BeamDesk's standards register pins CCSDS 502.0-B-3 for

orbit data messages and CCSDS 508.0-B-1 for conjunction data messages, whose Blue Book

cover reads June 2013 with updates through Technical Corrigendum 2 of October 2021, read

first-party today. The console consumes orbit mean-elements messages in the JSON

serialisation that CelesTrak and Space-Track publish, emits OEM, and in live mode reads

public conjunction data messages from Space-Track. BeamDesk has no account on the

platform described here, no relationship with SpaceX of any kind, and nothing in this

article should be read as implying one. Every statement above about that platform comes

from its own public pages, linked below.

What would change my mind

If SpaceX publishes a grammar for Modified ITC, with field widths, units and a normative

statement of the state vector frame, the central complaint here evaporates and the format

becomes as implementable as OEM. The same goes for a newer edition of the Spaceflight

Safety Handbook that does the job; version 1.7 of April 2023 is the newest this run

found, and a reader who can show a later one with a real specification should.

If the platform's eligibility statement changes, or if the first-party Starlink pages that

did not render to this fetch say something different from the documentation site, then the

claim that the API is closed to non-operators is wrong and I will retract it rather than

soften it. That claim rests on one sentence on one page.

And if CCSDS, or any other body with a publication process, opens work to adopt or replace

Modified ITC, that would settle the argument in the direction this article is pointing,

and it would be the single most useful thing anyone reading this could tell me about.

Sources