Kusha Sahu
← Projects

NovaTrace

2026 · Kusha Sahu

What it is

When a gamma-ray burst or fast radio burst goes off, the observation doesn't arrive as one message. It arrives as a scatter of machine-generated notices from whichever instruments caught it, followed over hours or days by human-written GCN Circulars reporting follow-up observations — a redshift here, an optical counterpart there, often from telescopes that don't know about each other. Reconstructing what is actually known about a single event means stitching those fragments together by hand.

NovaTrace does that automatically. It ingests the alert stream in real time, decides which notices and circulars describe the same astrophysical event, extracts the measurements out of prose, and maintains one evolving record per event.

How it works

A Kafka consumer subscribes to NASA GCN's real-time topics and writes each notice to a canonical event record. GCN Circulars arrive on the same stream, get extracted by a local LLM pipeline — measurements, instruments, author affiliations — and are linked back to the event they concern. A separate service recomputes each canonical event as new information lands: best available localization, earliest trigger time, notice count, whether a skymap exists.

NovaTrace ingestion pipelineNASA GCN real-time topics feed a Kafka consumer. The consumer splits the stream two ways: machine notices are written straight to a canonical event record, while human-written circulars first pass through a local LLM extraction step that pulls out measurements, instruments and author affiliations before being linked to the event they concern. A separate recompute service reads the canonical record and writes back the derived fields — best available localization, earliest trigger time, notice count and whether a skymap exists — every time new information lands.NASA GCNreal-time topicsKafka consumersubscribenoticescircularsLLM extractionlocal pipelineCanonical event recordone per eventRecomputederived fields
Ingestion path from GCN publication to a single evolving event record. Recompute derives localization, trigger time, notice count and skymap presence.

The hard part is identity, not ingestion

Different instruments name the same burst differently, and the same instrument emits several notices per event as its localization improves. Getting that wrong either splits one event into many or collapses distinct events together. NovaTrace resolves identity through an explicit per-source registry rather than a heuristic fallthrough — a design that came directly from watching the naive version fail three times in a row and leave ~11% duplicate records behind.

Numbers

Measured over the last 30–90 days.

  • 5,050 notices across 2,057 distinct events, plus 12,691 circulars ingested to date
  • Currently ~12 notices/day resolving to ~6.6 events/day
  • Sources live: Fermi GBM (664 notices / 175 events over 90d), CHIME FRB (288/248), SVOM (206/182), Einstein Probe WXT, IceCube, MAXI, Fermi LAT
  • Ingestion latency p50 = 1.0s, p90 = 3.0s from GCN publication to stored record
  • The whole LLM pipeline costs ~$0.20/month across ~900 model calls

Where it goes next is on the Starithm roadmap, and the product itself is at starithm.ai.