Rubin, the alert stream and the discoverer's toolkit

On 5 February 2026 the Minor Planet Center received a single batch from the Vera C. Rubin Observatory containing about 20,000 candidate discoveries and 246,000 observations. The MPC had built a dedicated path for it. Rubin’s observations arrived already linked into multi-night candidates, so the MPC added extra manual vetting, checked them against known objects, fitted orbits and searched its Isolated Tracklet File for earlier unlinked detections. All of it was processed. Then a bug in the final publication step left the correctly computed orbits out of the next Daily Orbit Update (MPC Newsletter, February 2026).

The episode is small, and the bug was found and documented, but it shows the shape of discovery in the Rubin era. A body becomes known through a sequence of states. A detection is a pixel excess in a difference image. An association groups detections that plausibly belong together. An orbit is a dynamical solution with an uncertainty. A recognised discovery has a designation and a public orbit. Each transition is performed by different software, often run by a different institution, and each can fail independently. “Accepted internally”, “visible in an explorer” and “present in a daily export” turned out to be three distinct states.

This chapter follows a moving object through that chain. It starts with the Legacy Survey of Space and Time (LSST) and Rubin’s own Solar System Processing (SSP), which turns difference-image sources into linked, fitted, reported objects. It then turns to the alert stream and the community brokers that sit on it, and finally to the services and libraries, from the MPC’s APIs to Horizons, SkyBoT, SSOIS, ASSIST, Find_Orb and Sorcha, that an individual discoverer uses. The linking algorithms themselves are developed in Chapter 12, orbit determination in Chapter 13 and the survey simulator in Chapter 16.

The telescope and the survey

What Rubin is

The Simonyi Survey Telescope on Cerro Pachón in Chile has an 8.4 m primary mirror with an effective aperture of about 6.5 m, a field of view of 9.6 square degrees and a 3.2-gigapixel camera with 0.2-arcsecond pixels (Ivezić et al. 2019). The usual shorthand for its single-visit depth is $r=24.5$ at five sigma. The design paper gives the five-sigma depth of a visit as

where $C_f$ is a filter-dependent constant, $m_{\rm sky}$ the sky brightness in magnitudes per square arcsecond, $\theta_{\rm eff}$ the effective seeing in arcseconds, $t_{\rm vis}$ the visit exposure time in seconds, $k_f$ the atmospheric extinction coefficient and $X$ the airmass. Its fiducial single-visit depths in $ugrizy$ are 23.78, 24.81, 24.35, 23.92, 23.34 and 22.45 AB mag. The newer population forecasts describe typical $r$ observations nearer 24.0. Seeing, sky, airmass and trailing all move the limit, and a single number should not be applied to every exposure.

Two consequences of the magnitude relation of Chapter 2 matter for what Rubin can find. A distant reflected-light body near opposition has $r\simeq\Delta$, so its flux falls as $r^{-4}$. A gain of $\Delta m$ in depth therefore extends the distance reach of an otherwise identical body by a factor of only $10^{\Delta m/10}$: one magnitude buys 26% more distance, not 58%. And astrometric precision degrades near the limit roughly as the PSF width divided by the SNR, so the faintest detections are also the least precise. A useful random-error model for photometry is

with $\gamma\approx0.039$, giving $\sigma_m\approx0.2$ mag at $m=m_5$ (Merritt et al. 2025).

Pairs, not quads

The historically consequential decision was the cadence. Traditional asteroid surveys such as Pan-STARRS and ATLAS take three to five exposures of each field in one night, which is enough to recognise a convincing same-night track (Chapter 14). Rubin’s survey serves many sciences, so it visits each field typically twice in a night. A pair of detections determines a position and an angular velocity and nothing more. The burden of discovery thereby shifts from one night to linking weak nightly fragments across several nights, and with millions of unrelated pairs per night the number of possible combinations explodes. Much of the Solar System history of LSST is about suppressing that explosion.

The separation of the pair is a compromise. For two positions with independent errors $\sigma_\theta$ separated by $\Delta t$, the angular rate is measured to

A longer gap measures slower motion, but it widens the search area for partners, lets fast objects leave the field, and makes it harder for the scheduler to complete pairs. Schwamb et al.’s cadence study recommended about 33 minutes. It also recommended a single 30 s exposure per visit in place of two 15 s snaps, which gave about 8% more visits in the tested schedules, and coverage of the Northern Ecliptic Spur (Schwamb et al. 2023). For a body at distance $r$ au near opposition, Earth’s orbital reflex moves it about $148/r$ arcseconds per hour. At 150 au a 33-minute pair spans only about 0.54 arcseconds. The yield forecasts adopt a minimum tracklet displacement of half an arcsecond, which is why the nominal reach of standard processing for distant bodies is quoted as roughly 150 to 200 au. That limit is set by the motion cut, not by the photons: a custom search using the parallax over a season can go farther (Chapter 9).

Solar System Processing

Rubin’s operational approach is detect then link. Every moving object must first appear as a five-sigma source in at least two difference images per night on at least three nights within a fourteen-day window. The alternative, integrate along a trajectory then detect, is left to community tools such as KBMOD (Chapter 17). Faster linking can recover objects already present in the source catalogues. Only a trajectory search can recover photons that never became catalogue detections.

Known-object association

The prompt chain begins with calibrated visit images and a template of the static sky. Difference imaging (Chapter 10) produces DiaSource detections, which include artefacts, unresolved variable sources, subtraction residuals and genuine moving bodies. Predicting where every known asteroid should be is itself a large survey computation. Rubin uses Sorcha’s ephemeris engine and a sky index for it. In Data Preview 2 (DP2), candidate object-detection pairs within one arcsecond are sorted by separation within each detector and visit, and accepted one at a time as long as neither member has already been used (DP2 documentation). This gives a one-to-one positional match. The public description says it uses no positional uncertainty, brightness, colour, morphology or rate.

A fixed gate makes the trade-off explicit. If unrelated detections have local surface density $\lambda$, a gate of radius $r_g$ is occupied by chance with probability about $\lambda\pi r_g^2$. As an illustration, 10,000 detections in a 9.6 deg² visit is about 1,040 per square degree. A 1-arcsecond gate covers $\pi/3600^2\approx2.4\times10^{-7}$ deg², so the chance occupancy is about $2.5\times10^{-4}$. That is small on average but not near the Galactic plane, and a poorly known orbit can be off by far more than an arcsecond. Too aggressive an attribution hides new objects among known ones. Too timid an attribution floods the blind search with known asteroids. The DP2 association also used an MPC orbit snapshot of 13 March 2026 restricted to arcs longer than two days and excluding comets, so later discoveries do not appear in the released association table even when their photons are in the images.

Tracklets

make_tracklets finds pairs (or more) of detections within one night consistent with linear motion, at separations of five to ninety minutes in the intended daily cycle (DP1 documentation). A naive search over all pairs of $D$ detections costs $O(D^2)$. A spatial index over the second image restricts each search to an annulus set by the allowed rates, giving expected cost $O(D\log D+P)$, where $P$ is the number of pairs accepted. The output term is what matters. For unrelated surface densities $\lambda_1$ and $\lambda_2$ over a common area $A$, the expected number of accidental pairs is

before cuts on minimum rate, morphology and masking. False pairs grow with the square of the source density and the square of the largest search radius. Doubling the maximum rate quadruples them. Correlated artefacts can be worse than this uniform estimate. For the small Data Preview 1 (DP1) campaign, Rubin deliberately used stricter settings: at least three detections per tracklet, at least five arcseconds of motion, and a maximum rate of 1.5°/day.

HelioLinC3D

The multi-night linker is HelioLinC3D, Ari Heinze’s three-dimensional development, with Siegfried Eggl, Mario Jurić and others, of the HelioLinC idea of Matthew Holman and colleagues (Holman et al. 2018). The original HelioLinC paper applied the method to the MPC’s Isolated Tracklet File and established orbits for about 41,000 new minor planets. The later THOR paper quotes about 200,000 for the same work (Moeyens et al. 2021). The 41,000 is the figure in the original text. Either way it was an archival discovery, not a Rubin result.

The idea is to supply the two numbers a tracklet lacks by hypothesis. Let $\mathbf R(t)$ be the observatory’s heliocentric position and $\hat{\mathbf u}(t)$ the observed direction. A hypothesised heliocentric distance $r_h$ fixes the range along the line of sight through a sphere intersection,

keeping physical positive roots. A hypothesised radial velocity $\dot r_h$ then gives the range rate,

and with it the full state $\mathbf r=\mathbf R+\rho\hat{\mathbf u}$, $\dot{\mathbf r}=\dot{\mathbf R}+\dot\rho\hat{\mathbf u}+\rho\dot{\hat{\mathbf u}}$. Each tracklet becomes a heliocentric position and velocity. Propagate all of them to a common epoch with two-body dynamics. Tracklets of one real body, under a hypothesis close enough to the truth, land on nearly the same state. Unrelated tracklets scatter. Linking becomes a nearest-neighbour search in six dimensions instead of an enumeration of triples. The denominator $\mathbf r\cdot\hat{\mathbf u}$ is small when the line of sight grazes the hypothesised sphere, which makes interior orbits ill-conditioned. A separate tool, heliovane, handles that niche (heliolinx).

Several implementation details carry real consequences.

• The hypothesis is about distance, not gravity. A hypothesis file specifies a distance, a radial velocity and a radial acceleration $\ddot r_h$, the second derivative of the distance. For a circular orbit it is zero, although the gravitational acceleration is not. Confusing the two produces a wrong template bank.
• Units in state space. Positions and velocities are combined as $\mathbf y=(\mathbf r(t_0),\,\tau\,\mathbf v(t_0))$ with $\tau=T_{\rm span}/4$, a quarter of the data span. This is the mean absolute offset from the central epoch for uniformly spread observations, and it puts velocities in position units.
• Range query, not DBSCAN. Older descriptions used DBSCAN clustering. The current code uses a kd-tree range query by default, because an eligible object may contribute only three tracklets, and the hypothesis grid must make even that minimal set fit inside a compact neighbourhood. DBSCAN’s ability to follow extended structures is unnecessary there and can merge unrelated tracklets into one cluster.
• A distance-scaled radius. Angular errors map to physical errors proportional to geocentric distance, so the neighbourhood radius scales with it in overlapping logarithmic bins, with a floor near the Earth. The README calls near-Earth linking a difficult optimisation problem: too small a floor makes the grid impractically fine, too large a floor mixes objects.

In outline:

unexplained = remove artefacts and confident known matches from DiaSources
tracklets   = make_tracklets(unexplained, observer ephemeris, motion limits)
for each radial hypothesis (r, rdot, rddot) in the bank:
    for each tracklet and each admissible line-of-sight root:
        state = heliocentric state from tracklet + hypothesis
        propagate state to the common epoch; scale velocity by tau
    for each overlapping geocentric-distance bin:
        build kd-tree of scaled states
        for each state: neighbours = range query within scaled radius
            if neighbours span >= 3 distinct nights: emit candidate linkage
candidates = link_purify(all linkages)   # fit, reject outliers, resolve overlaps
attribute to known orbits; recover more detections; report to MPC

For $N$ tracklets and $H$ hypotheses, the cost when neighbourhoods are sparse is about

where $C_{\rm prop}$ is the cost of building and propagating one state and $K$ the number of neighbour relations returned. The often-quoted $O(N\log N)$ holds at fixed $H$ and controlled occupancy. Dense fields can make $K$ quadratic, and orbit verification is extra. DP1 used 324 hypotheses spanning heliocentric distances of 1.5 to 9.8 au and nearly all bound radial velocities, with a clustering radius equivalent to $1.33\times10^{-3}$ au at 1 au from the Earth (Rubin Observatory Team 2026). No elapsed time or hardware for that linking run is reported.

Purify, fit, report

Raw linkages overlap heavily and include false combinations. link_purify fits a Keplerian orbit, iteratively rejects the worst outlier, enforces the minimum numbers of detections and nights, and picks the best of mutually overlapping linkages, so that no detection belongs to two accepted candidates. Orbits are fitted with the method of Herget, and accepted linkages must have sub-arcsecond residuals. A cheaper earlier test, link_planarity, projects observations onto the hypothesised sphere and rejects points far from a common orbital plane before any fitting. Its README reports run times a factor of a few shorter in suitable large cases, with the warning that a slightly wrong distance hypothesis can make a real object look non-planar.

Orbit fitting itself is not expensive per candidate. Jones et al. timed Find_Orb on one 3.1 GHz core for a six-observation, sixteen-day arc: 0.3 ms for the Gauss initial orbit and 26 ms for Herget refinement (Jones et al. 2018). The cost is in the number of candidates. The goodness-of-fit statistic is the usual

with nominally $2n-6$ degrees of freedom for $n$ two-coordinate positions and a six-parameter orbit. That count is not a calibrated false-alarm rate after a hypothesis search, outlier clipping and selection. In the pre-Rubin MOPS tests, a fixed RMS threshold in arcseconds accepted false orbits when the real astrometry was much better than the threshold; residuals normalised by their uncertainties discriminated better (Vereš & Chesley 2017). The daily cycle ingests the previous night’s detections, updates tracklets and the rolling search, refines candidates, associates known objects, searches for additional detections and submits in the ADES format. It must finish within 24 hours.

Tested before first light

Two pre-Rubin studies made the paired-visit strategy credible. Peter Vereš and Steven Chesley ran the Pan-STARRS MOPS linker on simulated LSST data that included statistical false detections and subtraction artefacts. They reached 93.6% linking efficiency for $H<22$ NEOs meeting the observing criteria, with 96% of NEO linkages correct, over a twelve-day window (Vereš & Chesley 2017). The twelve-day window means these figures should not be relabelled as present fourteen-day SSP performance. R. Lynne Jones and colleagues estimated false-detection densities from DECam data, with an upper limit of about 450 per square degree, and predicted 66% completeness for potentially hazardous asteroids and 61% for NEOs at $H<22$ in the then-baseline survey (Jones et al. 2018).

First results

Rubin Operations began on 25 October 2025. Public alerts began on 24 February 2026, and the start of the LSST was formally declared on 29 June 2026 (Guy et al. 2026, RTN-011). As of mid-October 2026 there is no completed survey year and no audited first-year discovery census. The real results so far come from two data previews and the early stream.

DP1 contains ComCam observations of seven fields of about a square degree each, taken over seven weeks in late 2024. Its Solar System campaign was small enough to inspect by hand but exercised the real chain: transformation, linking, orbit fitting and MPC submission. The candidate funnel is instructive. 269,581 tracklets produced 5,691 raw linkages and 281 refined candidates. Removing known bodies left 97, of which four were discarded conservatively because of outliers caused by the template subtracting the object from itself. The remaining 93 were accepted by the MPC as new main-belt asteroids (Rubin Observatory Team 2026). DP1 associated 5,988 detections with 431 objects in all, mostly within 0.1 arcseconds. No complete synthetic population was injected, so the funnel has no efficiency denominator. It demonstrates that the chain works, not how complete it is.

The September 2026 DP2 draft describes about 8.1 million source associations to 299,819 Solar System objects, from LSSTCam data taken between April 2025 and January 2026 (RTN-115). This is an association census against the input MPC catalogue, not a count of discoveries. Of the 299,819 objects, 17,528 have a single association and 212,181 have at least ten, a useful workload statistic for anyone planning light-curve work. 35 objects were observed beyond 50 au. The first characterisation results are already appearing: Vavilov, Eggl and Greenstreet analysed 9,417 asteroids with at least eighty photometric points from DP2 and public Rubin data and found 66 candidate super-fast rotators, including two of about 2 km with periods under six minutes, though the sizes depend on an assumed albedo (Vavilov et al. 2026).

The early-science plan is frank about the state of the stream. Templates are incomplete, so the first year’s alert production is limited and opportunistic. Moving-object histories may be missing, physical parameters may be null, and Solar System reporting is still partly ad hoc. Robinson et al. simulated the cost of building templates incrementally: significant discovery begins two to three months into the survey, and the first-year discovery metric drops by 28-63% across populations relative to a survey with templates already in hand, with the Northern Ecliptic Spur and rarely used filters worst affected (Robinson et al. 2025). A slow body present in the template also subtracts against itself, which is exactly what DP1’s four discarded candidates showed.

What Rubin is forecast to find

The best integrated forecast, by Kurlander and colleagues, runs Sorcha over the v3.4 baseline cadence of about two million visits with updated population models (Kurlander et al. 2025). It predicts a linked catalogue of about 5.36 million objects with 1.1 billion observations, of which about 3.9 million would be new.

For NEOs, the forecast gives Rubin-only cumulative completeness of 91% above 1 km and 72.4% above 140 m. For potentially hazardous asteroids larger than 140 m it is 72.7%, or 3,152 of 4,333 modelled objects. The first two years produce about 69% of the eventual main-belt sample, 72% of the TNOs and 53% of the NEOs larger than 140 m. These are fractions of the final Rubin-discoverable sample, not of the real populations. The forecast models SSP’s selection rules rather than running the production linker on synthetic difference images. It assumes 95% linking efficiency, gives each eligible opportunity an independent chance, and assumes perfect recovery of all in-survey detections after discovery. It did not model shift-and-stack discoveries, crowding losses, Sednoids or Planet Nine. Its NEO part alone cost about 60,000 core-hours, including 428 million tiny NEOs sampled from a modelled population of 1.9 billion bodies between 1 and 10 m. The interstellar and imminent-impactor forecasts are discussed in Chapter 14.

The alert stream

From ZTF to Rubin

Before 2018, transient notices were selected announcements: IAU circulars, Astronomer’s Telegrams, GCN notices, VOEvents, few enough to read by hand. The Zwicky Transient Facility on Palomar’s 48-inch Samuel Oschin telescope changed this by distributing every threshold-crossing difference-image source and leaving interpretation to the recipients (Patterson et al. 2019). Maria Patterson, Eric Bellm, Ben Rusholme, Mario Jurić and colleagues built the distribution on two pieces of industry software. Apache Avro serialises each alert as a binary record with an explicit schema. Apache Kafka distributes partitioned, append-only streams that consumers can replay from a recorded offset. (A Kafka “broker” is a messaging server. An astronomical “broker” such as Fink is something else that happens to share the name.)

ZTF’s stream carried 0.6 to 1.2 million alerts per full night, about 60 KB each, more than 70 GB a night, on 16 partitions per topic with a 7-day cache. Distribution tests reached about 80,000 alerts per minute. A ZTF packet carries the detection, its identifiers, 30 days of previous detections or limits at that position, catalogue matches and three image cutouts (science, template, difference). The 30-day history is a cone search at a fixed sky position. For a moving body it is not the object’s light curve.

Rubin’s design scales this up. It supports an average of 10,000 alerts per visit and at least 40,000 in a single visit, the familiar “ten million alerts per night”. About 400 per visit on average are expected to be moving objects, rising to 5,000 in dense ecliptic fields, and a packet is estimated at up to about 82 KB (Graham et al. 2024, DMTN-102). The latency requirement is that 98% of alerts from a qualifying visit (one with fewer than 40,000 alerts) leave the data facility within 60 seconds. That clock stops at the facility boundary. Broker ingestion, enrichment and any follow-up decision come afterwards. Ten million a night is a design figure. RTN-011 says explicitly that early alerts have not yet reached the velocity, latency or fidelity of full operations.

The alert threshold acts on significance in the difference image: Rubin considers detections above S/N 5 in either positive or negative flux. That significance is not the probability of anything astrophysical, and it includes none of the trials of the searches that follow. The end-to-end recovery of a body through a broker is a chain of conditional factors,

where $O$ is an observable object, $A$ its entry into the alert stream, $B$ its acceptance into a broker’s Solar System branch, $L$ successful linkage and $R$ recovery and identification. Improving $L$ cannot repair losses in $A$ or $B$. An object whose individual detections never crossed S/N 5 is not in the stream at all.

The brokers

Rubin’s broker page, updated 3 July 2026, lists seven full-stream brokers (ALeRCE, AMPEL, ANTARES, Babamul, Fink, Lasair and Pitt-Google) and two downstream brokers, SNAPS and POI (Rubin alert brokers). Their Solar System capabilities differ more than their names suggest.

Fink has processed the public ZTF stream since November 2019. Its founding architecture combined Spark Structured Streaming, Kafka, HDFS and HBase, so the same code could run on the nightly stream and reprocess history. Replay tests reached 100,000 incoming alerts per minute on a cluster of 11 machines and 162 cores. Typical streaming triggers fired every 400 alerts or 15 seconds, whichever came first, and science throughput was about 10 alerts per second per core (Möller et al. 2021).

ALeRCE classifies a new detection from its first three cutouts and metadata. Carrasco-Davis and colleagues crop the 63×63-pixel stamps to 21×21, combine rotation-invariant convolutional features with metadata, and output probabilities over AGN, supernova, variable star, asteroid and bogus. Balanced-test accuracy is 94.1±0.4%, and inference takes about 21 ms per alert (Carrasco-Davis et al. 2021). Training required three days on five GTX 1080 Ti GPUs for 133 hyperparameter settings. An “asteroid” label routes an alert. It does not give an orbit or an identity. A 2025 revision added a satellite class using the amplitude of the Fourier transform of the full 63-arcsecond difference stamp. A cropped 16-arcsecond model’s satellite accuracy rose from 72.0% to 87.8% with the FFT summary, against 95.9% for the full images (Carvajal et al. 2025). Satellite glints are a large contaminant: in ZTF, Karpov and Peloton found 73,368 glint events in 6,450 tracks affecting 3.6% of exposures (Karpov & Peloton 2022).

ANTARES aggregates alerts into a Locus around a sky position, enriches each with context and runs user-written Python filters. Its system paper says explicitly that discovering new moving objects requires a different approach and is beyond its scope. Known-object alerts can instead be routed to specialists looking for activity (Matheson et al. 2021). Lasair lets users compose SQL filters over packet features and its Sherlock cross-match. Its 2024 paper describes a partnership with Adler for Solar System alerts. Its current documentation says Lasair does not handle Solar System bodies, although its source code contains ingestion branches for Solar System tables (Williams et al. 2024). Code that exists, a plan, and a public service are three different kinds of evidence. SNAPS computes outlier ranks for known asteroids across 32,752 feature subspaces. On a synthetic five-million-object catalogue, 5% of the feature spaces took 14.49 hours on four A100 GPUs. That is GPU-accelerated characterisation, not discovery (Gowanlock et al. 2024).

The deployment population matters as much as the accuracy. If a selection has true-positive rate $u$ and false-positive rate $v$, and asteroids are a fraction $\pi$ of the stream, then

Balanced-test accuracy says little about purity in a stream where the class of interest is rare.

Fink-FAT: a broker that fits orbits

The most complete published test of discovery inside a broker is Fink-FAT, by Romain Le Montagner, Julien Peloton, Benoît Carry and colleagues, deployed in Fink in 2022 (Le Montagner et al. 2024). It has three stages.

1. Known-object attribution. ZTF matched alerts against a daily MPC ephemeris file within 30 arcseconds using astcheck. Fink kept a known-object label only if the separation was under 5 arcseconds and the alert was not closer to a Pan-STARRS star than to the predicted asteroid.
2. Unknown-candidate selection. An alert became a candidate if it matched no known object, was new or had at most two detections less than 30 minutes apart, and was not within 5 arcseconds of a star-like Pan-STARRS source (sgscore1 > 0.76).
3. Trajectory building and fitting. Detections and tracklets are joined night by night using kd-tree pair searches with gates on angular speed, magnitude change and turning angle,

The default inter-night gates are 0.3°/day, 0.1 mag/day in one band (0.5 across bands) and 1.0°/day of turning, set at the 90th percentiles of observed main-belt distributions. Trajectories with at least six alerts within a 15-day window go to the Pisa OrbFit suite, about 0.5 s per trajectory per core.

Over 755 nights from November 2019 to December 2022, Fink processed 111,275,131 alerts. 389,530 survived the unknown-candidate selection, a reduction by a factor of 286 before any linking. Nightly candidate counts had a median of 308 and a maximum of 12,889, so a system sized for the median would fail on bad nights. The search produced 327 candidate orbits, of which 65 had no MPC match in March 2023. That is a dated non-match, not 65 discoveries.

The known-object test shows the trade-off between purity and completeness more clearly than any other source in this chapter. Of 87,076 known objects in a 24-night test, 43,919 met Fink-FAT’s own detectability conditions. It returned 39,628 orbit candidates, 72.5% of them pure, covering 45.4% of the detectable bodies. Requiring a successful differential correction with uncertainties left 13,252 candidates at 97.0% purity, but only 24.5% efficiency. In the stricter set, recovery was 25% for main-belt bodies, 3.9% for Amors, 2.1% for Apollos, and none of the eight detectable KBOs. Widening the gates towards NEA-like motion made things worse: run time rose to about 15 hours and the number of fitted unknown candidates fell from 327 to 213, because more competing associations interfered with the sequential assignment of detections to tracks.

The run time divides in a way that bounds any acceleration. On the 24-night, 796,486-alert known-object test, the whole run took about 168 minutes: 119 for orbit fitting on 24 cores, 40 for association on a single 2.3 GHz core and 10 for database retrieval. Association run time grew quadratically with nightly volume up to 30,000 alerts per night, while fitting scaled inversely with cores from 2 to 128.

How fast a candidate must be followed up is shown by its prediction error. For orbits fitted to arcs with a median length of nine days, the median discrepancy between Fink-FAT and MPC-based predictions grew from 1 arcminute after a week to 7 after a month, 38 after four months and 577 after a year.

The latency of a usable decision is a sum,

and Rubin’s 60 seconds covers only the first two. ZTF measured a median of 8.5 minutes from exposure to alert packet in a June 2018 sample (6.7 and 12.6 minutes at the 5th and 95th percentiles) (Masci et al. 2019). ANTARES’s historical median residence time per alert was about 11 seconds. For moving objects the binding term is usually none of these. It is the time to the next useful observation, before the uncertainty region outgrows a follow-up telescope’s field.

The discoverer’s toolkit

A discoverer outside a survey team, with a candidate from a broker, an archive or their own images, needs a set of services and libraries that no single package provides. The map below pairs each question with its tool and the boundary of what the tool’s output means.

The Minor Planet Center

The MPC collects astrometry of minor bodies, identifies observations with objects, computes and distributes orbits and assigns designations. On 12 November 2025 it moved observation intake to AWS, with RabbitMQ routing work into a Python and Docker processing architecture and observations replicated to Cambridge, Massachusetts. Every submission, including rejected ones, now gets a unique submission_id (MPC Newsletter, November 2025). The same newsletter records that automatically generated tracklet identifiers grew from 10 to 12 characters. Such a change breaks any downstream code that assumed fixed-width fields.

Submissions use the Astrometry Data Exchange Standard (ADES) in XML or pipe-separated form, validated against submission-specific schemas plus further checks. A valid ADES file is not automatically an acceptable submission. Astrometry must carry the observing site’s code and correct times. A broker’s location is not an observatory, and Rubin’s TAI time fields must not be passed off as UTC (MPC ADES). The data interfaces include an observations endpoint, https://data.minorplanetcenter.net/api/get-obs, which takes a JSON body with a list field desigs, and an orbit endpoint, .../api/get-orb, which takes a singular desig and returns MPC_ORB JSON (format version 0.5 as of September 2025). The asymmetric naming should be copied exactly. For bulk work the MPC replicates its PostgreSQL tables through the Small Bodies Node. At inspection the observations and identity tables were marked ready and mpc_orbits partially populated (MPC replicated tables). Two measurements from one exposure are not independent evidence, and the MPC now groups exact and near-duplicate measurements explicitly.

Ephemerides: Horizons and local integration

JPL Horizons, designed and implemented by Jon Giorgini with the Solar System Dynamics Group and first described in 1996, answers a target-and-observer question. It produces observer tables, Cartesian vectors, osculating elements and SPK trajectory files. Its HTTP API, introduced in July 2021, accepts up to 10,000 discrete epochs per request (Horizons API). Astroquery’s jplhorizons module wraps it. For a validation sample, archive exact requests and responses. For a large search, a design that makes a remote call per epoch pays network latency repeatedly and obscures which orbit solution was used. Propagate locally and spot-check against Horizons.

The local tools are REBOUND and ASSIST. REBOUND, by Hanno Rein and Shang-Fei Liu, is an N-body framework (Rein & Liu 2012). Its IAS15 integrator, by Rein and David Spiegel, is a 15th-order adaptive Gauss-Radau scheme (Rein & Spiegel 2015). ASSIST, by Matthew Holman, Arya Akmal, Davide Farnocchia, Rein and colleagues, uses them to integrate massless test particles in the force field of JPL’s ephemerides (Holman et al. 2023). The model is

with the Sun, planets, Moon, Pluto and 16 massive asteroids read from the ephemeris rather than integrated, plus relativistic terms, the important gravitational harmonics and parameterised non-gravitational forces $\mathbf a_{\rm NG}$. Its acceleration terms match JPL’s to machine precision.

Integration error is rarely the binding error. In Sorcha’s validation, a simulated trajectory of ‘Oumuamua differed from JPL’s by about 24 arcseconds in right ascension, because JPL’s solution includes non-gravitational acceleration and the simulation did not (Holman et al. 2025). A faster or more accurate integrator cannot fix a missing term in the force model. Independent test particles also do not interact, so the cost is $O(NSB)$ for $N$ particles, $S$ steps and $B$ perturbers, with no all-pairs force calculation.

Who is in my field, and where else was it?

SkyBoT, by Jérôme Berthier, Frédéric Vachier, William Thuillot and colleagues at IMCCE, answers the inverse question: given a field, an epoch and an observer, which known bodies are in it? (Berthier et al. 2006). It precomputes ephemerides, currently sampled daily and stored every ten days over 1889 to 2060, and interpolates. Its numerical accuracy is a few tens of milliarcseconds, but poor orbits can be off by hundreds or thousands of arcseconds, and newly discovered bodies take hours to days to appear after its weekly updates (SkyBoT). A failed SkyBoT match is not evidence of novelty, especially near the time of discovery.

SSOIS, by Stephen Gwyn, Norman Hill and J. J. Kavelaars at the Canadian Astronomy Data Centre, answers the opposite question: given an orbit or ephemeris, which archived images could contain the object? (Gwyn et al. 2012). A static cone search fails for a moving target. SSOIS cuts the trajectory into segments, stores coarse integer-day and integer-degree bounding boxes, joins them to the image database, and refines only the surviving candidates by interpolating to the exposure midpoint and testing real coverage. The 2012 paper matched a 20-year ephemeris against 1.6 million images in 0.3 seconds. By 2022 the archive held 75 million images. Daily interpolation can be 2 to 3 arcminutes wrong for close approachers, and the uncertainty is a fixed box rather than a growing ellipse. The coarse-to-fine join is the whole trick: computing a precise prediction for every archived exposure would throw away its advantage. Chapter 13 covers precovery in depth.

Orbit fitters

Bill Gray’s Find_Orb is the practical workhorse. It is used interactively, in batch as fo, through a web interface, by ZTF’s ZMODE and by the Interstellar Crusher that flagged 2I/Borisov (Find_Orb). OpenOrb, by Mikael Granvik, Jenni Virtanen, Dagmara Oszkiewicz and Karri Muinonen, adds statistical ranging, which samples the non-Gaussian orbit distribution of a short arc instead of reporting a single covariance ellipse (Granvik et al. 2009). Layup, from Holman and colleagues, is a newer C++ engine with a Python interface built on ASSIST. It supports Gauss and Bernstein-Khushalani initial orbits, covariance-aware predictions, radar, streaks with rates, and space-based astrometry (layup). A detection from digital tracking carries a rate, and an orbit fitter that discards it throws away information. Layup’s documentation distinguishes converged from accepted, and its covariance-degeneracy flag is checked only when non-gravitational parameters are fitted. A wrapper that collapses these states into “success” loses exactly the information a benchmark needs. Finally, at least three different programs are called orbfit: the Pisa OrbFit suite used by Fink-FAT and NEODyS, Bernstein and Khushalani’s TNO fitter, and informal references to Find_Orb. Record the repository and version, not the executable name.

Linkers and stackers

Two community engines complement SSP. THOR, by Joachim Moeyens and colleagues, chooses trial heliocentric orbits, gathers detections near each one’s predicted path, transforms them into a frame co-moving with the trial orbit, and searches for straight-line clusters with DBSCAN (Moeyens et al. 2021). It needs no same-night tracklets, which makes it independent of cadence. On two weeks of ZTF data it recovered 20,940 of 21,542 known objects with at least five observations, 97.2%, using 821 test orbits on 23 nodes of 28 cores in under 18 hours. KBMOD, by Peter Whidden, Bryce Kalmbach and colleagues, works below the catalogue threshold on a GPU (Whidden et al. 2019). It precomputes, for each image $i$,

where $I$ is the image, $P$ the PSF and $V$ the pixel variance, and then evaluates the likelihood $\nu=\sum_i\Psi_i/\sqrt{\sum_i\Phi_i}$ along each trial trajectory. The 2019 paper reports about 240 billion trajectories through 30 4K×4K images in 180 s, and 39 previously unknown KBOs in 150 square degrees of DECam data. Chapter 17 is devoted to it.

Sorcha and the interoperability layer

Sorcha, from Stephanie Merritt, Grigori Fedorets, Megan Schwamb and a large team, simulates what a survey should detect (Merritt et al. 2025). Its ephemeris engine avoids the all-objects-by-all-visits calculation with a time-dependent spatial index Holman et al. call a picket. For each object, compute directions on three successive nights, interpolate the path through the intervening two days, and record every HEALPix cell (about 0.45° at nside=128) it crosses. Each pointing then queries only the overlapping cells, and only those candidate objects are integrated precisely (Holman et al. 2025). Each object gets its own integrator, so a close encounter does not force a small step on every other body.

Reusing the IAS15 interpolating polynomial inside an accepted step makes an individual evaluation about 30,000 times faster than a full step, but the survey-level gain is only 2 to 4 times, because everything else remains. Its linking stage, miniDifi, counts eligible detections and applies a 95% probability. It does not generate false tracklets or run HelioLinC3D, so it cannot certify a new linker’s completeness.

Underneath everything sit Astropy, astroquery and sbpy. Astropy makes physical assumptions explicit in types: a Time object with a scale, not a float called epoch; a coordinate frame, not two columns (Astropy Collaboration 2022). Sbpy adds small-body Orbit, Ephem, Obs and Phys containers and phase laws, under the stated principles that “physical parameters are quantities” and “epochs must be Time objects” (Mommert et al. 2019). These libraries prevent errors more than they save time.

A reasonable workflow for a candidate found in one’s own data looks like this:

query MPC for known identities and astrometry near the candidate
check known bodies in each field with SkyBoT (record the catalogue date)
run the detector/linker; fit orbits with Find_Orb or layup (keep covariance)
verify a few ephemeris points against Horizons
search SSOIS for archival images along the predicted path; measure; refit
re-check identity against updated MPC orbits
prepare ADES with true site codes, UTC times and uncertainties; submit
track the submission_id until designation and publication

Each step should store the version of every catalogue, kernel and code it used. “Not in SkyBoT on 3 March” is a reproducible statement. “Unknown” is not.

Limitations and open problems

The threshold boundary. Brokers receive a censored view of the images. No downstream network can recover pixels that were never transmitted. Forced photometry or cutout requests add evidence for known positions, but a search below the threshold must return to the images, which for Rubin means the full visit images that full DP2 will release. RTN-011 attributes the delay in releasing those images partly to limited bandwidth between the US Data Facility and Google Cloud.

Uncertainty is lost between stages. A classifier exports a score, a linker a membership list, a fitter a nominal orbit, and an archive tool a box. A non-Gaussian short-arc posterior rarely survives the trip. No source examined here shows a calibrated posterior passed end to end.

Identity is not ground truth. Fink-FAT’s recovered (525570) and its Jupiter moons, and 316 objects whose names failed to match consistently in its orbit-class accounting, show that known-object labels are imperfect. Training classifiers on such labels propagates both false associations and population selection.

Purity can hide completeness. Fink-FAT’s 97% purity came with 24.5% efficiency within its own detectable set, and with near-zero recovery for NEOs and KBOs. High recovery of known main-belt asteroids is evidence with a selection function, not a sensitivity certificate.

Regimes outside the standard rules. Very slow bodies fail the minimum-motion cut or subtract against their templates. Very fast ones trail, leave the field or cannot be seen on three nights. Near-Earth encounters strain two-body propagation and distance-scaled clustering. Unbound orbits require HelioLinC3D’s universal-variable option with a suitable hyperbolic excess velocity. Running a bound-orbit configuration does not validate completeness for interstellar objects.

Missing measurements. There is no published SSP false-alarm rate, no all-sky HelioLinC3D benchmark of wall time, hardware and completeness together, no service-wide MPC or Horizons latency benchmark, and no common benchmark across the brokers that runs from images through linking to MPC identity.

Where the room is

The Rubin era makes the computational question concrete: billions of detections, millions of orbits, a 24-hour cycle. The evidence in this chapter also shows where speed matters and where it does not.

Accelerate the right stage. In Fink-FAT’s dense test, orbit fitting took about 70.83% of the wall time. Amdahl’s law,

with $f=0.7083$ gives at most $3.43\times$ for infinitely fast fitting, and $2.76\times$ for a tenfold speed-up. An end-to-end factor of ten needs less candidate work, not just a faster fitter. Fink’s own 286-fold cut in candidates before linking was a larger gain than any kernel.

Reuse work across radial hypotheses. HelioLinC3D repeats state construction and neighbour indexing for every hypothesis. The state transforms are embarrassingly parallel and suit a GPU. Rebuilding a kd-tree per hypothesis is irregular and memory-bound. Nearby hypotheses produce nearby states, which suggests incremental grids, sorted spatial keys or shared coarse partitions with exact checks. A metric on hypothesis space,

where $\mathbf y(h)$ is the transformed state under hypothesis $h$ and $W$ a weight matrix, would let the bank be placed adaptively, as template banks are in gravitational-wave searches (Chapter 38). The difficult part is guaranteeing that coarse pruning never drops a minimal three-tracklet cluster at a cell boundary or near the Earth. Any claim of equal sensitivity needs injections concentrated in exactly those regions.

Use uncertainty in association. DP2’s one-arcsecond, one-to-one gate is simple and throws away information. Orbit covariances, along- and cross-track residuals, detection reliability and broad photometric consistency could give calibrated association probabilities with recoverable alternatives. Brightness and colour cannot be hard vetoes, because rotation, activity and phase-curve errors are real. Fink-FAT’s experience, where widening the gates reduced the output, argues for keeping competing branches alive with scores rather than assigning each detection irreversibly to its first acceptable track.

Treat data movement as part of the algorithm. The delay of DP2’s visit images was a network limit, not an arithmetic one. ZTF in Chapter 14 hit database and file-system limits with CPU to spare. Routing compact columnar detection records to linkers and keeping cutouts for vetting, running image searches next to the data, and caching matched-filter products such as KBMOD’s $\Psi$ and $\Phi$ can matter more than peak tensor-core throughput. One constraint is fixed: a broker cannot compute a large-field FFT from a small cutout. Context that needs surrounding pixels must be computed upstream.

Search below the catalogue, where the cadence allows. For $N$ equal exposures on a known trajectory, stacking gains $1.25\log_{10}N$ magnitudes. Searching $M$ trajectories raises the threshold to roughly $z\sim\sqrt{2\ln(M/\alpha)}$ for false-alarm target $\alpha$. Rubin’s wide-fast-deep visits are sparse and mix filters, so the natural first targets are the deep-drilling fields and other repeated areas, with parallax-aware trajectories over longer baselines (Chapter 20). A full-survey cost estimate must include finding and reading the images, preparing PSFs and variances, masking and vetting, not just KBMOD’s accumulation kernel.

Eliminate work before accelerating it. SSOIS and Sorcha both win by sparse intersection in sky and time. A GPU ephemeris or archive search must be compared with an indexed, interpolating CPU implementation, or it will merely rediscover the optimisation. For orbit fitting, batches of independent fits suit GPUs, single small fits do not, and close encounters and non-gravitational cases need their own accurate path. Mixed precision needs measured error propagation all the way to angular residuals and accept/reject decisions.

Build the missing benchmark. One frozen observation set, one catalogue and kernel snapshot, injected objects across every dynamical class and real artefact backgrounds, with completeness versus magnitude and motion, false accepted orbits, calibration of predictions, wall time, energy and data volume all reported, stage by stage and in total. Without it, an order-of-magnitude efficiency claim at equal sensitivity cannot be tested. With it, the limits that are engineering, such as hypothesis banks, gates, templates, I/O and daily budgets, can be separated from the limits that are physical: photons, sky access and the information in a short arc. Chapter 42 takes up that separation across the book.

References

1. Minor Planet Center (2025). MPC Newsletter, November 2025. minorplanetcenter.net
2. Minor Planet Center (2026). MPC Newsletter, February 2026. minorplanetcenter.net
3. Ivezić, Ž., Kahn, S. M., Tyson, J. A. et al. (2019). LSST: From Science Drivers to Reference Design and Anticipated Data Products. ApJ 873, 111. arXiv:0805.2366
4. Merritt, S. R., Fedorets, G., Schwamb, M. E. et al. (2025). Sorcha: A Solar System Survey Simulator for the Legacy Survey of Space and Time. arXiv:2506.02804
5. Holman, M. J., Bernardinelli, P. H., Schwamb, M. E. et al. (2025). Sorcha: Optimized Solar System Ephemeris Generation. arXiv:2506.02140
6. Schwamb, M. E., Jones, R. L., Yoachim, P. et al. (2023). Tuning the Legacy Survey of Space and Time (LSST) Observing Strategy for Solar System Science. ApJS. arXiv:2303.02355
7. Robinson, J. E. et al. (2025). Tuning the LSST Observing Strategy for Solar System Science: Incremental Templates in Year 1. ApJS. arXiv:2411.19796
8. Holman, M. J., Payne, M. J., Blankley, P., Janssen, R., Kuindersma, S. (2018). HelioLinC: A Novel Approach to the Minor Planet Linking Problem. AJ 156, 135. arXiv:1805.02638
9. Heinze, A., Jurić, M., Kurlander, J. et al. heliolinx (HelioLinC3D) software and documentation. github.com/heliolinx/heliolinx
10. Moeyens, J., Jurić, M., Ford, J. et al. (2021). THOR: An Algorithm for Cadence-Independent Asteroid Discovery. AJ. arXiv:2105.01056
11. Vereš, P., Chesley, S. R. (2017). Near-Earth Object Orbit Linking with the Large Synoptic Survey Telescope. AJ 154. arXiv:1706.09397
12. Jones, R. L., Slater, C. T., Moeyens, J. et al. (2018). The Large Synoptic Survey Telescope as a Near-Earth Object Discovery Machine. Icarus 303, 181. arXiv:1711.10621
13. University of Washington (2023). New algorithm ensnares its first "potentially hazardous" asteroid. washington.edu
14. Vera C. Rubin Observatory Team (2026). The Vera C. Rubin Observatory Data Preview 1. AJ. arXiv:2603.23786
15. Vera C. Rubin Observatory Team (2026). The Vera C. Rubin Observatory Data Preview 2 (draft), RTN-115. rtn-115.lsst.io; DP2 documentation dp2.lsst.io
16. Rubin Observatory. Data Preview 1 documentation: Solar System linking. dp1.lsst.io
17. Guy, L. P., AlSayyad, Y., Bechtol, K. et al. (2026). Rubin Observatory Plans for an Early Science Program, RTN-011 (revised 1 October 2026). rtn-011.lsst.io
18. Vavilov, D., Eggl, S., Greenstreet, S. (2026). Discovery of 2 km Ultra-fast Rotating Asteroid in Rubin DP2 Catalog via Varying Fourier Order Method. arXiv:2610.07584
19. Kurlander, J. A. et al. (2025). Predictions of the LSST Solar System Yield: Near-Earth Objects, Main Belt Asteroids, Jupiter Trojans, and Trans-Neptunian Objects. arXiv:2506.02487
20. Murtagh, J. et al. (2025). Predictions of the LSST Solar System Yield: Discovery Rates and Characterizations of Centaurs. arXiv:2506.02779
21. Patterson, M. T., Bellm, E. C., Rusholme, B. et al. (2019). The Zwicky Transient Facility Alert Distribution System. PASP 131, 018001. arXiv:1902.02227
22. Masci, F. J., Laher, R. R., Rusholme, B. et al. (2019). The Zwicky Transient Facility: Data Processing, Products, and Archive. PASP 131, 018003. arXiv:1902.01872
23. Graham, M. L., Bellm, E. C., Guy, L. P. et al. (2024). LSST Alerts: Key Numbers, DMTN-102. dmtn-102.lsst.io
24. Rubin Observatory (2026). Alerts and brokers. lsst.org
25. Möller, A., Peloton, J., Ishida, E. E. O. et al. (2021). Fink, a new generation of broker for the LSST community. MNRAS 501, 3272. arXiv:2009.10185
26. Le Montagner, R., Peloton, J., Carry, B. et al. (2024). Enabling discoveries of Solar System objects in large alert data streams. A&A. arXiv:2305.01123
27. Förster, F., Cabrera-Vives, G., Castillo-Navarrete, E. et al. (2021). The Automatic Learning for the Rapid Classification of Events (ALeRCE) Alert Broker. AJ. arXiv:2008.03303
28. Carrasco-Davis, R., Reyes, E., Valenzuela, C. et al. (2021). Alert Classification for the ALeRCE Broker System: The Real-time Stamp Classifier. AJ 162, 231. arXiv:2008.03309
29. Carvajal, J. P., Bauer, F. E., Reyes-Jainaga, I. et al. (2025). Tuning into spatial frequency space: Satellite and space debris detection in the ZTF alert stream. A&A. arXiv:2411.03258
30. Karpov, S., Peloton, J. (2022). Impact of satellite glints on the transient science on ZTF scale. arXiv:2202.05719
31. Matheson, T., Stubens, C., Wolf, N. et al. (2021). The ANTARES Astronomical Time-domain Event Broker. AJ 161, 107. arXiv:2011.12385
32. Williams, R. D., Francis, G. P., Lawrence, A. et al. (2024). Enabling science from the Rubin alert stream with Lasair. RAS Techniques and Instruments 3, 362. arXiv:2404.08315
33. Gowanlock, M., Trilling, D. E., Kramer, D., Chernyavskaya, M. (2024). The Solar System Notification Alert Processing System (SNAPS): Asteroid Population Outlier Detection. AJ. arXiv:2405.20176
34. Minor Planet Center. ADES Data Submission; Replicated tables schema. ADES; replicated tables
35. JPL Solar System Dynamics Group. Horizons API documentation. ssd-api.jpl.nasa.gov
36. Rein, H., Liu, S.-F. (2012). REBOUND: An open-source multi-purpose N-body code for collisional dynamics. A&A 537, A128. arXiv:1110.4876
37. Rein, H., Spiegel, D. S. (2015). IAS15: A fast, adaptive, high-order integrator for gravitational dynamics. MNRAS 446, 1424. arXiv:1409.4779
38. Holman, M. J., Akmal, A., Farnocchia, D. et al. (2023). ASSIST: An Ephemeris-Quality Test Particle Integrator. PSJ 4, 69. arXiv:2303.16246
39. Berthier, J., Vachier, F., Thuillot, W. et al. (2006). SkyBoT, a New VO Service to Identify Solar System Objects. ASP Conference Series 351, 367. ADS; service ssp.imcce.fr
40. Gwyn, S. D. J., Hill, N., Kavelaars, J. J. (2012). SSOS: A Moving Object Image Search Tool for Asteroid Precovery. PASP 124, 579. arXiv:1204.4182
41. Gray, B. Find_Orb orbit determination software. projectpluto.com
42. Granvik, M., Virtanen, J., Oszkiewicz, D., Muinonen, K. (2009). OpenOrb: Open-source asteroid orbit computation software including statistical ranging. Meteoritics & Planetary Science 44, 1853. doi:10.1111/j.1945-5100.2009.tb01994.x
43. Holman, M. J. et al. Layup: orbit fitting at LSST scale, software documentation. layup.readthedocs.io
44. Whidden, P. J., Kalmbach, J. B., Connolly, A. J. et al. (2019). Fast Algorithms for Slow Moving Asteroids: Constraints on the Distribution of Kuiper Belt Objects. AJ 157, 119. arXiv:1901.02492
45. Astropy Collaboration (2022). The Astropy Project: Sustaining and Growing a Community-oriented Open-source Project and the Latest Major Release (v5.0) of the Core Package. ApJ. arXiv:2206.14220
46. Mommert, M., Kelley, M. S. P., de Val-Borro, M. et al. (2019). sbpy: A Python module for small-body planetary astronomy. JOSS 4, 1426. doi:10.21105/joss.01426