How the record is made.

Each source contributes the things it does best. We never invent missing values: where a field has a supporting claim, the record exposes it; otherwise provenance is shown as unknown.

• CelesTrak, periodically refreshed orbital elements (the numbers that describe where an object is and how it moves), plus NORAD catalog numbers and object names. This is our backbone for the tracked catalog.
• GCAT (Jonathan McDowell), a detailed public launch catalog: launch and decay dates, object classification (payload, rocket body, debris), operator, country, and orbital regime.
• Wikidata, community-maintained facts the orbital and launch catalogs don’t carry: operator details, country of operator, launch mass, and mission purpose.
• SatNOGS DB, a community-maintained transmitter catalog: downlink and uplink frequencies, bands, modes, and reported transmitter status for the objects amateur operators listen to. Published under CC BY-SA 4.0, so anything you build on this part of the data has to carry the same licence.

OrbitalWiki does not query Space-Track directly. It retrieves published GP data from CelesTrak, whose documentation says it receives and ingests GP data through 18 SDS/Space-Track. See Sources for every source, its license, and its attribution requirements.

Data is refreshed automatically on fixed schedules, not by hand:

• CelesTrak, fetched every 6 hours by an open-source GitHub Actions workflow. Orbital data changes constantly, so it gets the most frequent refresh.
• GCAT, downloaded daily at 07:30 UTC. The launch catalog changes slowly.
• Wikidata, queried via SPARQL weekly, on Sundays, since the fields we pull (operator, mass, purpose) rarely change once set.

The ingestion scripts and the workflow definition are public, so anyone can audit exactly what we fetch and when.

The hard part of a project like this is deciding when two records from two different sources describe the same physical object. We do it in three steps.

Every stored value (we call them “claims”) carries one of five confidence levels, CONFIRMED, HIGH, MEDIUM, LOW, CONFLICTING reflecting how much we trust its source for that kind of field. It is a label, not a numeric score:

Which level a claim gets is decided by its source, not per value: CelesTrak elements are CONFIRMED, CelesTrak SATCAT and GCAT are HIGH, Wikidata is MEDIUM, and entity resolution re-marks a claim CONFLICTING when a second source contradicts it.

Displaying the level lets you decide for yourself how much weight to give any single value rather than trusting a black box.

We would rather state our weak spots plainly than have you discover them:

• ·Uneven Wikidata coverage. Large constellations are sparsely documented, many individual Starlink satellites have no Wikidata entry, so operator/mass/purpose may be missing for them.
• ·Under-documented status. Operational status is only set when a source states it: CelesTrak SATCAT publishes an explicit status code per object, and GCAT's status column records whether an object is still in orbit, not whether it works. Where no source states a status we show “unknown” rather than assuming the spacecraft is alive. That is currently 531 of 16,564 objects (3.2%).
• ·Archive depth. Historical orbital completeness depends on CelesTrak’s archive. Some objects out of CelesTrak’s active set (for example, very high orbits like JWST at L2, or long-decayed objects like Vanguard 1) may have limited or no current orbital data.
• ·Orbital data is approximate. Our elements are suitable for browsing and research, not for operational tracking, collision avoidance, or maneuver planning.
• ·Object-type coverage is payload-only. Our satellite records come from CelesTrak's active feed, which is almost entirely payloads. GCAT and Wikidata enrich those existing rows but never create new ones, so rocket bodies, debris, and long-decayed objects are barely represented: 6 of 16,564 records, despite GCAT's full catalog covering tens of thousands of them.

Publishing an honest error rate matters more to us than claiming perfection. We measure accuracy two complementary ways, and we publish updated results periodically.

The spot-check is regenerated by a committed, read-only script (scripts/spot-check.ts). The script is committed in the public repository, selected reports are archived, and issues found are investigated and corrected after discovery. We periodically re-run validation and update these figures here.

Found something wrong? We want to know. Every record is open to correction, and reports are reviewed privately by our team, we read every one.

Use the “Report a correction” control on any satellite detail page, or the form below. Please include the NORAD catalog number, the field in question, and a primary source for the correct value where possible, that lets us verify and fix it quickly.