Reading tonight's activity against the recent baseline…
usual range (recent)
needed to see it here
tonight
Current conditions
OVATION chance here
—
model probability at this cell
Magnetic latitude
—
centred-dipole estimate
3-day outlook
About these numbers
The anomaly gauge — how "usual" is defined method
The gauge compares tonight's Kp to a rolling baseline built from the readings we have on hand — roughly the last three days of stored snapshots. The shaded band is the middle half of that recent range (25th–75th percentile); the dot is now. It is deliberately simple, and honest about its limits: this is "usual lately," not "usual for this place and season." Kp is a planetary index — the same number everywhere on Earth at a given moment — so the baseline says nothing location-specific on its own; what makes it local is the "needed here" line, set by your magnetic latitude. A proper per-location seasonal climatology would need years of history and a real model; that's a later milestone (a longer-term data store), not this.
Kp index what it measures
Kp is a 0–9 planetary index of geomagnetic disturbance, issued every three hours by NOAA from a network of magnetometer stations. Higher means the Earth's magnetic field is being shaken harder by the solar wind, which pushes the auroral oval further from the poles. It's a global average, not a local reading — so a high Kp is necessary but not sufficient to see aurora where you are; that depends on how far the oval reaches your latitude (next card).
Magnetic latitude & "Kp needed here" the threshold
Aurora sits over the geomagnetic poles, which don't line up with the geographic ones — so what matters for you is your magnetic latitude, not the one on a map. We estimate it with a centred-dipole approximation (a tilted-bar-magnet model of Earth; pole near 80.6°N, 72.7°W). The "Kp needed here" figure uses the well-known rule of thumb required Kp ≈ (66 − |magnetic latitude|) ÷ 2. It's a rough estimate, not a precise forecast — it ignores the non-dipole wrinkles of the real field and local sky conditions — but it's honest about which places need a big storm (low magnetic latitude) versus a quiet night (under the oval).
OVATION probability the model
OVATION Prime is NOAA's short-term auroral-precipitation model. Every few minutes it estimates, on a 1° global grid, the chance of visible aurora overhead — driven by live solar-wind measurements from the DSCOVR/ACE spacecraft upstream of Earth. The "chance here" number is that model's value at your exact grid cell (we snap your coordinates to the nearest degree). It's a genuine physical model, but a short-range one: it says what the sky is likely doing in the next ~30 minutes, not tonight as a whole, and it can't know your clouds.
A running accuracy record for the AI narrator. Each time it offers a "verdict" about the sky, we log what it said and the data it was standing on — then, once enough time has passed, check it against what NOAA's own instruments actually recorded. Misses are shown as plainly as hits. This is a record, not a highlight reel.
Awaiting outcomes. These six entries are the seed set — the narrator's real lines beside the exact data they were grounded in. The outcome and verdict columns stay pending until the narrator has been running live long enough to compare each line against later NOAA readings. Nothing here is back-filled with invented outcomes.
Pending — awaiting outcome
Hit
Partial
Miss
What's needed to backfill real verdicts: the deployed narrator already stores each line with its grounded_in data and generated_at timestamp (DynamoDB NARRATION items). To fill the outcome column, a small validation job (the governance layer) reads, for each past entry, the actual NOAA data from the window that entry was about — the same 3-hour Kp block for a "now" line, or the forecast's target day for an "outlook" line — from the READING / FORECAST snapshots the poller is already accumulating. It then scores directionally: Hit = the felt claim matched what happened, Partial = right direction, wrong magnitude or timing, Miss = it contradicted the record. This needs (1) the backend deployed and running for days–weeks so real dated entries accumulate, and (2) that validation job written. Until both exist, this table honestly reads "pending."