Ask CelesTrak for the last thirty days of newly catalogued objects in TLE format and

you get HTTP 404. Ask for the same thirty days as JSON and you get 402 records. Every

one of them is numbered above 100000, and that is now the normal case.

Both of those are measured. I ran the two queries on 11 October 2026, three months

after the catalogue crossed the line, and the query strings are in the sources at the

foot of this piece so anyone can repeat them in a browser in under a minute. The

single-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

request 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

catalogue number and not the endpoint.

The format ran out of field, not of room

CelesTrak's front page, read on 11 October 2026, carries the notice as its lead item.

It puts the official USSF catalogue at 100982 and states that "All newly cataloged

objects have 6-digit catalog numbers of 100000+ and GP data will not be available for

them using the TLE format."

The cause is a column count. The TLE is a fixed-width text record from the punched-card

era, and columns 3 to 7 of each line hold the satellite catalogue number. Five

characters, maximum 99999. Dr T.S. Kelso's CelesTrak page on GP data formats, first

published 27 May 2020 and updated 23 June 2026, states the consequence without

decoration: "Of course, TLE formats will not support objects with catalog numbers above

99999."

So the interesting number is not 100982. It is 982, the count of catalogue numbers

assigned since 11 July 2026, every one of which is unrepresentable in the format most

tooling still assumes. Across those 92 days that is an estimated average of about

eleven a day, derived from two documented counter readings and nothing else. It is an

average, not a forecast, and the population behind it is lumpy: a single breakup event

can add hundreds in a week.

What matters more than the rate is which objects they are. They are the new ones.

Anything catalogued from 11 July onward, which includes every payload from every launch

since, sits above the line. A pipeline built on TLE text does not degrade gracefully as

this proceeds. It simply never sees the spacecraft that launched this quarter.

Two publishers, two answers, for the same object

The United States Space Force produced a bridge. Space-Track's own documentation, which

is readable without a login and was read on 11 October 2026, describes Alpha-5 as "a

stopgap object numbering schema

from the United States Space Force that increases the satellite catalog's capacity to

display up to 339,999 objects". It replaces the leading digit with a letter, A for 10

through 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,

pointing users to XML, KVN, JSON and CSV, which carry the full nine-digit range.

CelesTrak declined the bridge. Kelso's page explains why in one line that is worth more

than the rest of the argument combined: "18 SPCS is already assigning catalog numbers in

their new analyst sat range of 7995xxxxx (or over 799,500,000)." Even letting all five

characters run from 0 to Z, a base-36 field reaches 60,466,176 identifiers, which is

more than 339,999 and still an order of magnitude short of the numbers the catalogue

authority has already issued internally. A bridge that does not reach the far bank is a

pier. CelesTrak's recommendation is the XML serialisation of the CCSDS Orbit

Mean-Elements Message, from CCSDS 502.0-B-3, Blue Book, April 2023.

That leaves two authoritative sources publishing different things about the same

object, 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

compatibility.

Downstream, that choice propagates. The AWS Ground Station user guide, whose document

history dates the section to 28 May 2026, says Alpha-5 encoded satellite numbers in

uploaded TLEs are parsed and resolved to integers, and that the service's own API field

stays numeric: "Alpha-5 is purely a display encoding for the TLE text format. The

underlying numeric satellite catalog number does not change." N2YO's API page carries a

notice dated 20 July 2026 telling callers to "always use the object's assigned NORAD

Catalog ID rather than the Alpha-5 identifier found in the TLE file", because its own

TLE files show one form and its API expects the other.

Three providers, three internally consistent conventions, one object. The identifier you

hold depends on which door you came in through.

The failure that costs money is the one that does not throw

On 6 October 2026 somebody opened an issue against an open-source orbital tool titled,

verbatim, `TLE with an Alpha-5 catalogue number (e.g. "A0001" = 100001) throws

FormatException instead of parsing`. The parser called integer-parse on a field

containing a letter. It has since been closed by a pull request. That is the good

outcome. An exception is a bug report.

The expensive version is quieter. satellite.js, which is the SGP4 implementation most

JavaScript ground software depends on, takes the catalogue number as

longstr1.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

NORAD_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

value silently returns nothing. A contact list that comes back empty reads exactly like

a spacecraft with no passes, and the difference between those two is invisible until

somebody walks out to the pad.

This is why the half of the field that has already moved to OMM has not noticed the

change at all. BeamDesk's console reads the JSON serialisation of the OMM and never

parses TLE text. That was not foresight. It was a decision taken for a duller reason,

that the providers publish OMM and the parser we would otherwise maintain is a parser

somebody else already maintains better.

What this changes for anyone counting beam-hours

Every access number this site publishes is computed by propagating an element set. Beam

hours, worst gap in a day, contact minutes at a particular site: all of them start with

an identifier and a set of mean elements, and the identifier is the part that just

changed.

The cost of adopting OMM is small and it is also not zero. The record carries the same

mean elements, so the propagator is untouched. What changes is ingestion, the type of

the catalogue number in your database, every fixed-width assumption in your test

fixtures, and any code path that compares an identifier from one provider against an

identifier from another. A day of work for a team that has one ingestion point. Longer

for a team that has seven, which is the usual number once somebody counts.

The deadline is not in anyone's roadmap, which is the awkward part. Nothing breaks on a

published date. The catalogue simply stops describing the newest spacecraft in the

format you are reading, and the newest spacecraft are the ones a new market is built

around. For a venue operator booking ground time against a demonstrator that launched

this autumn, the first symptom is a spacecraft that cannot be looked up, and the second

is an availability figure that is quietly computed over the wrong fleet.

What would change my mind

If CelesTrak began emitting Alpha-5 from its GP endpoint, the central claim here dies

and this becomes an encoding footnote rather than a split between publishers. The test

is 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

problem rather than overstating it. Alpha-5 would stop being a bridge for anybody,

Space-Track included, and the migration everyone is deferring would become compulsory in

the same quarter.

The argument that would genuinely soften this one is a breakdown of the 402 objects I

counted. If they are overwhelmingly debris and rocket bodies rather than payloads anyone

schedules a contact against, this is a data-hygiene problem with a long fuse rather than

an operational one. The list I read contained both, and I have not done that split. I

would want it before writing this with any more urgency than it already carries, and I

would publish it either way.

Sources