Ask CelesTrak for the last thirty days of newly catalogued objects in TLE format and
\nyou get HTTP 404. Ask for the same thirty days as JSON and you get 402 records. Every
\none of them is numbered above 100000, and that is now the normal case.
\nBoth of those are measured. I ran the two queries on 11 October 2026, three months
\nafter the catalogue crossed the line, and the query strings are in the sources at the
\nfoot of this piece so anyone can repeat them in a browser in under a minute. The
\nsingle-object version is cleaner still. gp.php?CATNR=100000&FORMAT=json serves
SARAMAGO, international designator 2026-067CY, epoch 2026-10-10T03:17:45. The identical
\nrequest with FORMAT=tle returns 404. A control run against object 25544 in TLE format
on the same day served the International Space Station normally, so this is the
\ncatalogue number and not the endpoint.
\nCelesTrak's front page, read on 11 October 2026, carries the notice as its lead item.
\nIt puts the official USSF catalogue at 100982 and states that "All newly cataloged
\nobjects have 6-digit catalog numbers of 100000+ and GP data will not be available for
\nthem using the TLE format."
\nThe cause is a column count. The TLE is a fixed-width text record from the punched-card
\nera, and columns 3 to 7 of each line hold the satellite catalogue number. Five
\ncharacters, maximum 99999. Dr T.S. Kelso's CelesTrak page on GP data formats, first
\npublished 27 May 2020 and updated 23 June 2026, states the consequence without
\ndecoration: "Of course, TLE formats will not support objects with catalog numbers above
\n99999."
\nSo the interesting number is not 100982. It is 982, the count of catalogue numbers
\nassigned since 11 July 2026, every one of which is unrepresentable in the format most
\ntooling still assumes. Across those 92 days that is an estimated average of about
\neleven a day, derived from two documented counter readings and nothing else. It is an
\naverage, not a forecast, and the population behind it is lumpy: a single breakup event
\ncan add hundreds in a week.
\nWhat matters more than the rate is which objects they are. They are the new ones.
\nAnything catalogued from 11 July onward, which includes every payload from every launch
\nsince, sits above the line. A pipeline built on TLE text does not degrade gracefully as
\nthis proceeds. It simply never sees the spacecraft that launched this quarter.
\nThe United States Space Force produced a bridge. Space-Track's own documentation, which
\nis readable without a login and was read on 11 October 2026, describes Alpha-5 as "a
\nstopgap object numbering schema
\nfrom the United States Space Force that increases the satellite catalog's capacity to
\ndisplay up to 339,999 objects". It replaces the leading digit with a letter, A for 10
\nthrough Z for 33, skipping I and O. Object 100000 prints as A0000.
Space-Track serves Alpha-5 in its TLE and 3LE outputs and recommends moving off them,
\npointing users to XML, KVN, JSON and CSV, which carry the full nine-digit range.
\nCelesTrak declined the bridge. Kelso's page explains why in one line that is worth more
\nthan the rest of the argument combined: "18 SPCS is already assigning catalog numbers in
\ntheir new analyst sat range of 7995xxxxx (or over 799,500,000)." Even letting all five
\ncharacters run from 0 to Z, a base-36 field reaches 60,466,176 identifiers, which is
\nmore than 339,999 and still an order of magnitude short of the numbers the catalogue
\nauthority has already issued internally. A bridge that does not reach the far bank is a
\npier. CelesTrak's recommendation is the XML serialisation of the CCSDS Orbit
\nMean-Elements Message, from CCSDS 502.0-B-3, Blue Book, April 2023.
\nThat leaves two authoritative sources publishing different things about the same
\nobject, both defensibly. Space-Track gives you A0000 in a TLE. CelesTrak gives you
100000 in an OMM and gives you nothing at all in a TLE. Neither is wrong. They have
made opposite bets about whether the installed base is worth two more years of
\ncompatibility.
\nDownstream, that choice propagates. The AWS Ground Station user guide, whose document
\nhistory dates the section to 28 May 2026, says Alpha-5 encoded satellite numbers in
\nuploaded TLEs are parsed and resolved to integers, and that the service's own API field
\nstays numeric: "Alpha-5 is purely a display encoding for the TLE text format. The
\nunderlying numeric satellite catalog number does not change." N2YO's API page carries a
\nnotice dated 20 July 2026 telling callers to "always use the object's assigned NORAD
\nCatalog ID rather than the Alpha-5 identifier found in the TLE file", because its own
\nTLE files show one form and its API expects the other.
\nThree providers, three internally consistent conventions, one object. The identifier you
\nhold depends on which door you came in through.
\nOn 6 October 2026 somebody opened an issue against an open-source orbital tool titled,
\nverbatim, `TLE with an Alpha-5 catalogue number (e.g. "A0001" = 100001) throws
\nFormatException instead of parsing`. The parser called integer-parse on a field
\ncontaining a letter. It has since been closed by a pull request. That is the good
\noutcome. An exception is a bug report.
\nThe expensive version is quieter. satellite.js, which is the SGP4 implementation most
\nJavaScript ground software depends on, takes the catalogue number as
\nlongstr1.substring(2, 7) in src/io.ts on master, read 11 October 2026, and keeps it
as a five-character string with no Alpha-5 decoding, while its OMM path takes
\nNORAD_CAT_ID and stringifies it. Nothing throws.
You get "A0001" from one source and "100001" from the other, for the same
spacecraft, and both look like perfectly good identifiers. Every join keyed on that
\nvalue silently returns nothing. A contact list that comes back empty reads exactly like
\na spacecraft with no passes, and the difference between those two is invisible until
\nsomebody walks out to the pad.
\nThis is why the half of the field that has already moved to OMM has not noticed the
\nchange at all. BeamDesk's console reads the JSON serialisation of the OMM and never
\nparses TLE text. That was not foresight. It was a decision taken for a duller reason,
\nthat the providers publish OMM and the parser we would otherwise maintain is a parser
\nsomebody else already maintains better.
\nEvery access number this site publishes is computed by propagating an element set. Beam
\nhours, worst gap in a day, contact minutes at a particular site: all of them start with
\nan identifier and a set of mean elements, and the identifier is the part that just
\nchanged.
\nThe cost of adopting OMM is small and it is also not zero. The record carries the same
\nmean elements, so the propagator is untouched. What changes is ingestion, the type of
\nthe catalogue number in your database, every fixed-width assumption in your test
\nfixtures, and any code path that compares an identifier from one provider against an
\nidentifier from another. A day of work for a team that has one ingestion point. Longer
\nfor a team that has seven, which is the usual number once somebody counts.
\nThe deadline is not in anyone's roadmap, which is the awkward part. Nothing breaks on a
\npublished date. The catalogue simply stops describing the newest spacecraft in the
\nformat you are reading, and the newest spacecraft are the ones a new market is built
\naround. For a venue operator booking ground time against a demonstrator that launched
\nthis autumn, the first symptom is a spacecraft that cannot be looked up, and the second
\nis an availability figure that is quietly computed over the wrong fleet.
\nIf CelesTrak began emitting Alpha-5 from its GP endpoint, the central claim here dies
\nand this becomes an encoding footnote rather than a split between publishers. The test
\nis one request: gp.php?CATNR=100000&FORMAT=tle returning two lines instead of 404.
If 18 SPCS released its nine-digit analyst numbers externally, the piece understates the
\nproblem rather than overstating it. Alpha-5 would stop being a bridge for anybody,
\nSpace-Track included, and the migration everyone is deferring would become compulsory in
\nthe same quarter.
\nThe argument that would genuinely soften this one is a breakdown of the 402 objects I
\ncounted. If they are overwhelmingly debris and rocket bodies rather than payloads anyone
\nschedules a contact against, this is a data-hygiene problem with a long fuse rather than
\nan operational one. The list I read contained both, and I have not done that split. I
\nwould want it before writing this with any more urgency than it already carries, and I
\nwould publish it either way.
\n