SpaceX runs a conjunction screening service that is free to satellite operators and
\nreturns a result in under a minute. The file format it falls back to by default is
\nspecified in two paragraphs and a screenshot, on page 20 of a handbook published by a US
\nSpace Force squadron.
\nThat is not a complaint about SpaceX. It is the shape of the orbital data layer as it
\nactually stands, and anybody planning to consume ephemeris at scale should know which
\nof these documents is a standard and which is a description of a script.
\nThe immediate occasion is a push for reciprocity. The Register reported on 7 October 2026
\nthat Starlink encountered conjunctions with about 650 unique manoeuvring third-party
\nsatellites during 2026 and that only about half of those shared ephemeris, and that over
\nsix months it observed roughly 164,000 conjunctions where closest approach fell within
\nfour hours of an unannounced manoeuvre. Those figures are attributed to Starlink's own
\nspace safety update. That page is client-rendered and did not return readable content to
\nthis run, so the two numbers above are second-hand and BeamDesk has not verified them
\nagainst the primary. Everything that follows was read first-party on 18 October 2026.
\nThe platform documentation at docs.space-safety.starlink.com describes, in its own
words, low-latency conjunction screening against both user-submitted data and
\nobservations made by the Stargaze space situational awareness system, with results
\ntypically available less than a minute from trajectory submission. The overview page
\nstates that the platform is "always free of charge to participating spacecraft
\noperators", and immediately afterwards that "Currently, use of the API is limited to
\nsatellite operators." Onboarding is a human process: the documentation gives an email
\naddress at SpaceX and nothing self-service.
\nSeparately, and with no key at all, Starlink publishes its own fleet's ephemerides. The
\nREADME at starlink.com/public-files/ephemerides/ gives the terms: Modified ITC format,
carrying position and velocity covariance, 72 hours of prediction, refreshed every eight
\nhours, 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
\nfor Operators, version 1.7, on space-track.org.
\nThe platform's own collision avoidance article is worth reading for scale. It documents
\nover a thousand avoidance manoeuvres a day, planned and executed without humans in the
\nloop, with probability-of-collision criteria of 3e-7 for healthy satellites and 1e-6 for
\nsatellites in orbit transfer, and a miss distance box of 100 m radial by 1500 m
\nalong-track and cross-track in the RTN frame. All of these are documented figures from
\nthe operator, not measurements by anyone else.
\nThe trajectory upload accepts several formats and identifies them by sniffing the file
\nheader. 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
\nread 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
\nthese is treated as Modified ITC. The standard format is the special case. The
\nunstandardised one is the default.
\nSo it matters what Modified ITC is. The Spaceflight Safety Handbook for Satellite
\nOperators, version 1.7, April 2023, published by the 18th and 19th Space Defense
\nSquadrons at Vandenberg Space Force Base, defines it on page 20. The definition is one
\nparagraph of prose, one figure, and one paragraph describing a program. The prose says
\nthe format is "the only format that is required to contain both positional and velocity
\ncovariance data in addition to ephemeris data", that it carries four descriptive and
\nheader lines of which the fourth gives the orbital reference frame of the covariance,
\nand that each point is one state vector line followed by three lines holding the
\ntwenty-one values of the 6x6 lower triangular covariance matrix.
\nThe figure is a screenshot of the file open in an emacs window. The remaining normative
\ncontent is a description of what the tooling does with the bytes: the handbook says the
\npreprocessing script "reads the data lines in groups of four and separates the entries on
\neach data line wherever one or more space" characters are found. That is a specification
\nin the sense that you could implement against it. It is not a grammar, it has no field
\nwidths, it states no units, and it is silent on the thing that bites first.
\nThe thing it is silent on is the frame of the state vector. Page 20 names a reference
\nframe only for the covariance. It never says which frame the position and velocity are
\nin. Starlink's API reference closes that hole by convention rather than by citation: an
\nOEM upload may carry position and velocity in ITRF or EME2000, while a Modified ITC
\nupload must be EME2000, with covariance in UVW, RTN, RSW, EME2000 or J2000. Note that
\nlist. UVW and RTN are the same frame under two names, and the handbook says so itself on
\nthe facing page. EME2000 and J2000 are, for this purpose, two more. A parser has to know
\nthat before it can be correct, and no document in this chain says it in a normative
\nsentence.
\nThe contrast on the next page is the sharpest part. For the CCSDS format, the same
\nhandbook does not attempt a definition at all. It tells the reader to "refer to please
\nvisit the Consultative Committee for Space Data Systems (CCSDS) website and reference the
\n'Orbit Data Messages' Blue Book". That is exactly right, and it is what a standard is
\nfor. The handbook defines the format that has no owner and delegates the one that does.
\nThe case against making anything of this is real and should be stated. A format defined
\nby an example is adequate when there is one producer, one consumer and a shared parser,
\nand that was the situation when the handbook was written. The output that matters is the
\nscreening result, not the file. CCSDS conformance buys interoperability, and
\ninteroperability is only worth paying for when more than two parties need it. The reason
\nto care now is that the number of parties went up. The publisher of the largest
\nconstellation in orbit is asking every other operator to feed the same pipe, which turns
\na bilateral convention into something closer to infrastructure.
\nAnyone implementing against this will hit all three. The tutorial page gives two upload
\ntypes, 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
\nprobability values in the resulting conjunction data messages. The endpoint reference
\nsays the upload requires a minimum of six data points with accompanying covariance and
\nthat all position covariance must be non-zero. Those cannot both be true. On frames, the
\ntutorial lists ITRF as preferred with EME2000 and ITRF2000 also accepted, while the
\nendpoint reference splits the permitted frames by file format as described above.
\nThe rest of the envelope is consistent and worth writing down: at least six state vectors
\nin the future, a span between 42 seconds and 21 days, velocity below 70 km/s, positions
\nabove the surface, UTC only with GPS time explicitly unsupported, and a file body under
\n31,458,780 characters.
\nNothing in money, and that is the headline. The cost is in three other currencies.
\nThe first is eligibility. The documented gate is being a satellite operator, decided by a
\nperson at an email address. An operations or market layer that is not itself flying
\nhardware has no documented route to a key. The public ephemeris mirror has no gate at
\nall, so for the narrow job of knowing where those satellites are, the integration is one
\nparser and a manifest.
\nThe second is disclosure. The platform documents that a definitive trajectory is inserted
\ninto the catalogue and visible to all users, where a hypothetical one is screened once
\nand visible only to the submitter. That is a sensible design and it is the point of a
\nsharing platform. It is also a decision: your planned trajectory becomes readable by
\nevery other participant, including the party operating the platform. The same
\ndocumentation argues the case for that openly, telling operators that ephemeris "should
\nnot be treated as proprietary information, it is critical for safe flight."
\nThe third is the parser. Modified ITC is not hard. It is ten lines of code and a
\nreference frame you have to know by folklore. The question is whether you want that in
\nyour dependency graph with no issuing body to point at when it changes.
\nFor what it is worth on this side: BeamDesk's standards register pins CCSDS 502.0-B-3 for
\norbit data messages and CCSDS 508.0-B-1 for conjunction data messages, whose Blue Book
\ncover reads June 2013 with updates through Technical Corrigendum 2 of October 2021, read
\nfirst-party today. The console consumes orbit mean-elements messages in the JSON
\nserialisation that CelesTrak and Space-Track publish, emits OEM, and in live mode reads
\npublic conjunction data messages from Space-Track. BeamDesk has no account on the
\nplatform described here, no relationship with SpaceX of any kind, and nothing in this
\narticle should be read as implying one. Every statement above about that platform comes
\nfrom its own public pages, linked below.
\nIf SpaceX publishes a grammar for Modified ITC, with field widths, units and a normative
\nstatement of the state vector frame, the central complaint here evaporates and the format
\nbecomes as implementable as OEM. The same goes for a newer edition of the Spaceflight
\nSafety Handbook that does the job; version 1.7 of April 2023 is the newest this run
\nfound, and a reader who can show a later one with a real specification should.
\nIf the platform's eligibility statement changes, or if the first-party Starlink pages that
\ndid not render to this fetch say something different from the documentation site, then the
\nclaim that the API is closed to non-operators is wrong and I will retract it rather than
\nsoften it. That claim rests on one sentence on one page.
\nAnd if CCSDS, or any other body with a publication process, opens work to adopt or replace
\nModified ITC, that would settle the argument in the direction this article is pointing,
\nand it would be the single most useful thing anyone reading this could tell me about.
\n