Process

How Get NEOCP orbits turns public observations into checked orbit tables and ephemerides. The main publication path runs from steps 1 to 6. Status reporting and observation archiving are separate paths, not evidence of a completed calculation.

Red boxes labelled Attention identify stages flagged by an operational review. They do not relax any acceptance check or declare the numerical results invalid. An unmarked box is not a live health certificate.

Attention assessment: 2026-11-10 06:44:09 UTC. This is the recorded review time, not continuous live monitoring.

For a readable small-screen view, follow the complete numbered stages below. The full-size diagram is also available through the export buttons.

1. MPC and public Internet sources

NEOCP/PCCP lists and complete 80-column observations arrive from the Minor Planet Center. Project Pluto supplies supplementary orbit and guide information.

Monitor → confirmed source change or scheduled refresh → preparation.

2. Auxiliary data and discovery evidence

Check cross-identifications, suspect identifications and observatory information. Resolve unknown discovery stations from original observation evidence.

Complete source selection → coherent inputs for the calculator.

3. Orbit and ephemeris calculation

The native Get-CP engine prepares the inputs and calls Find_Orb. Daily, hourly and minute grids describe the orbit and close-approach geometry.

Native engine → isolated Find_Orb jobs → complete output set.

4. Scientific and consistency gates

Check observation integrity, freshness, object coverage, required outputs, numerical comparisons and cross-file consistency. Alternative computations are accepted only by their existing per-object promotion gates.

Accepted result → rendering. Rejected or incomplete result → no false fresh publication.

5. Render and validate the website

Build Actual, Small and Downloads first, then the remaining pages and History. Check the browser layout, links, public scope and complete file hashes.

Checked pages → public staging → guarded upload.

6. Atomic SFTP publication

The central uploader obtains credentials from the Windows vault, verifies the pinned server identity and transfers only approved public files. Atomic replacement is used; global remote deletion is disabled.

SFTP → HTTPS verification with cache-busting and full SHA-256 comparison.

Separate paths

Monitor activity → status preparation → status upload

The status banner reports observed monitor activity. The monitor maintains status and activity history separately from the scientific tables. Preparation, checked staging and transfer retain the existing serialization and security checks. The MPC change-detection watcher keeps its configured cadence; it is not evidence of a completed primary calculation.

A new status timestamp does not mean that the ephemeris reference time changed. Read the source-retrieval and ephemeris timestamps on Actual and Small separately.

Observation sources → checked OBS80 daily archive

The archive retains complete observation lines, source provenance and day assignment. All participating archive writers use the same exclusive writer lock. Immutable exports, complete manifests and hashes are verified. This path is not a website upload and does not bypass the calculation gates.

Optional analyses use private snapshots. A private analysis result is not silently injected into the primary runtime, and its completion is not a prerequisite for publishing an already accepted primary result.

What is the “station index”?

Two different datasets must not be confused:

Observatory catalogue: ObsCodes.html: The MPC station-code catalogue contains observatory names and location parameters. It answers “What observatory does this code identify?”
Discovery-evidence index: crossids-discovery-stations.sqlite3: This derived index describes observation files, not one file per station. It records which object identifiers occur in each existing OBS80 source and which station codes have an explicit discovery asterisk. Many files can belong to the same station; a file can contain several object identifiers. Original observation files are not copied into the index.
Unique, missing, unmarked and ambiguous evidence: A discovery station is filled in only if the combined evidence identifies one station uniquely. Missing observations, absent discovery marks and conflicting station codes remain distinguishable. A convenient filename or the first available station is never used as a guess.

Programs and helpers

Get-CP monitor: get_cp_app.py daemon: The long-running coordinator detects confirmed changes, applies the configured debounce and load guard, starts ordinary calculation cycles and tracks publication. Process uptime is not calculation duration.
Auxiliary-data reader and CrossID catalogue: Choose usable complete source groups, normalize known presentation defects and combine discovery evidence without inventing identities or stations.
Native engine: get-cp-engine32.exe: Coordinates required public inputs and produces the legacy data fragments. Atomic download helpers preserve existing files when a request fails.
Find_Orb launcher and numerical core: get-cp-orbit64.exe isolates each object's working files and starts get-cp-orbit-core64.exe. Numerical models, observation selection and accuracy thresholds belong to the scientific gates; a startup or disk optimization does not authorize a mathematical shortcut.
Ephemeris shadow and production-pilot helpers: Compare alternative predictions with the trusted reference. Rejections, fallbacks and unavailable comparisons remain explicit. A historical cache or promotion count is not a fresh accuracy comparison.
Modern website builder and browser validator: Turn accepted data fragments into shared-layout pages and verify the exact public bytes before transfer. The early primary path does not wait for unrelated optional analysis pages.
Status-upload helpers and central SFTP uploader: Prepare status/history and serialize transfers using the existing shared locks. Per-operation vault, profile, scope, host-key and full-hash checks remain mandatory; no password or private configuration is published.
Daily archive helper: obs80_daily_archive.py: Checks and archives original OBS80 evidence separately from web publishing. A completed archive does not imply that a new public ephemeris exists.
Watchdog and safe-switch helper: The watchdog uses the established single-instance start route. A maintenance helper can wait for a natural safe boundary, revalidate a coherent source bundle and allow one ordinary successor start. It does not force a running calculation to stop or create a second monitor.

Timing, failure handling and freshness

Source acquisition, auxiliary preparation, orbit fitting, ephemeris grids, validation, rendering and transfer are separate measured phases. Their wall time can include network and disk waits. A process read counter is not a measurement of physical traffic on one particular drive.

A timeout, unavailable mandatory source or failed integrity gate must not be hidden by labelling old or partial data as new. The last accepted public result may remain visible, with its original scientific timestamps, until a complete new result passes the ordinary publication path. There is no fixed minute guarantee and no automatic weakening of checks under load.

Operational review is scheduled every six hours. Attention markers are annotations of that review, not continuous telemetry or a new scientific acceptance rule. No extra calculation is started for the review.