AI astronomy needs an inspectable alert queue

Rubin Observatory issued 800,000 scientific alerts on its first alert night in February 2026.

Processing that stream requires deciding which changes need another observation. Researchers need enough context to assess urgency before choosing a follow-up that could help identify the event.

That allocation of attention is what interests me about AI in astronomy. A system can help route a signal to someone able to investigate while the event is still observable. Rubin's first-alert announcement

An alert begins an investigation

Rubin's February 25 announcement identifies February 24, 2026 as the first scientific alert night. It describes up to seven million alerts per night as an eventual scale. The first-night count is an observation; the larger figure describes an anticipated workload.

One object can produce repeated alerts as it changes. Some alerts concern known objects, while apparent changes can also be image artifacts. Establishing a discovery therefore requires investigation beyond counting incoming alerts.

Images can show the change a signal describes. Previous measurements can establish whether it has happened before. Matching the source against a catalog may identify an object already known to researchers. Each input can affect which follow-up is appropriate.

A summary needs to make those inputs distinguishable. An image-based suggestion carries different evidence from an identification supported by earlier observations.

Add context before requesting telescope time

An alert broker receives the stream, then adds information researchers can use to select follow-up. Rubin describes catalog matching among its functions. Brokers can also filter alerts or classify events, with interfaces through which scientists inspect them. ALeRCE receives the full alert stream as one of Rubin's brokers. Rubin's broker documentation

ALeRCE's foundational paper describes real-time ingestion followed by aggregation. The pipeline matches catalogs before applying classification methods, then presents results visually. It uses quick image-based classification alongside methods that examine brightness over time, a history called a light curve. The ALeRCE broker paper

The first assessment can support a decision while an event is young. Later observations may change that assessment. Waiting for a complete history can mean losing an earlier opportunity to observe something that would have helped explain the event.

The interface needs to state how much evidence supports the current assessment. A suggestion based on one detection should show that limited history, allowing a reviewer to distinguish it from a longer sequence of consistent observations.

Let the reviewer examine the selection

I'd want a ranked candidate to open onto its images with the measurement history. Catalog matches should be visible beside the reason it passed a filter. If the model's assessment changed, the record should show the change.

ALeRCE's stamp-classifier paper describes SN Hunter, which presents supernova candidates for expert selection before reporting. The paper separately counts candidates confirmed through spectroscopy, a method that examines light split into wavelengths. Those stages supply different evidence about the object's identity. ALeRCE's stamp-classifier research

I want the interface to connect a suggestion to an action the scientist can take. Inspecting its evidence should let them decide whether the next observation is justified.

Rejecting a candidate also needs a usable path. If each dismissal requires investigating the software, the review process consumes the attention the broker was intended to save.

Evaluate selection under survey conditions

The stamp-classifier paper reports high accuracy on a balanced test set. That experiment evaluates performance under its chosen class proportions. Estimating the reliability of rare candidates in a live stream requires evaluation under the stream's conditions.

Live data can have different class proportions from the test set. Image conditions may change too, with some events outside the training examples. A researcher also needs to know how many promising events were missed, then how much follow-up time went to targets that proved unhelpful.

I'd carry those questions into the application design. Record which candidates received follow-up. Preserve the selection rules so later analysis can account for how software influenced the observations researchers obtained.

These are requirements I'd investigate when using classification to allocate attention. Each broker's implementation needs its own evidence about how it handles selection.

Work with the astronomy expertise

My original note moved too quickly from a solar-system visualization to scientific agents. Both involve asynchronous data displayed through an interface. Interpreting a transient or choosing an observation requires astronomy expertise beyond what an orbit animation demonstrates.

A software engineer can work with researchers to make provenance visible. Changing assessments need a readable history. The review action should fit the scientist's question, with the full path tested from alert arrival to inspection by the intended person.

The system can reduce a large stream to candidates a researcher can investigate. Scientific judgment remains necessary when deciding what the next observation should test.

I'd want to build a queue in which opening a candidate reveals why the signal was selected, with enough evidence for the researcher to decide what to do next.