# How WeatherNext 3 made observation freshness part of model design

How the route from GraphCast and GenCast to WeatherNext 3 made observation freshness an architectural question rather than a final dashboard detail.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-03
Original announcement: https://blog.google/innovation-and-ai/models-and-research/google-deepmind/introducing-weathernext-3/
Canonical URL: https://retrivium.ai/retrospectives/weathernext-3-observation-to-forecast/

WeatherNext 3 is a useful retrospective marker because weather prediction depends on when information enters the system, not only on how quickly a model runs. The path behind the announcement leads through the age of evidence.

## The dated path

- 2023-11-14: [GraphCast: AI model for faster and more accurate global weather forecasting](https://deepmind.google/blog/graphcast-ai-model-for-faster-and-more-accurate-global-weather-forecasting/).

- 2024-12-04: [GenCast predicts weather and the risks of extreme conditions with state-of-the-art accuracy](https://deepmind.google/blog/gencast-predicts-weather-and-the-risks-of-extreme-conditions-with-sota-accuracy/).

- 2026-09-03: [Google introduces WeatherNext 3](https://blog.google/innovation-and-ai/models-and-research/google-deepmind/introducing-weathernext-3/).

## Why inference speed was an incomplete objective

A model can finish quickly after receiving an input that already describes an older state of the world. For a slowly changing phenomenon this may be tolerable; for a rapidly evolving local event it can dominate the value of the output. Our interpretation of the research progression is that forecast quality and data freshness became inseparable design questions. Improving execution time alone cannot recover observations that never reached the model before its forecast was issued.

## The causal chain begins upstream

Consider the path from an observation to a usable forecast: collection, transport, quality checks, assimilation or representation, inference and delivery. Each stage can contribute delay or uncertainty. A model benchmark that starts after preprocessing hides the earlier stages. A useful operational account keeps their timestamps visible and distinguishes the observation time from the issue time. This does not imply that every stage should be minimized independently; a quality check can take time while improving the usefulness of what follows.

## A counterfactual with the same model

Run the same forecasting method against input snapshots with different ages while holding the evaluation period fixed. That comparison can reveal the contribution of fresh evidence separately from the contribution of a new model architecture. An apparently better forecast may otherwise benefit from seeing a more recent world state. Retrospectively, this is why the observation pipeline belongs in the scientific description of a forecasting system. It is part of the conditions under which the result was produced.

## What an infrastructure operator should measure

The relevant service record can include observation age, forecast issue time, model identity and delivery delay. Missing or late observations should remain distinguishable from a healthy inference worker that received incomplete input. These are engineering implications, not measurements of Google’s internal service. WeatherNext 3 also follows earlier learned forecasting systems rather than appearing without a history. The broader lesson for AI providers is that end-to-end freshness can matter more to a user than an isolated execution-time improvement reported at the model boundary. A freshness objective should name the source timestamp it uses, so different services cannot report incompatible starting points as the same latency.

## Technical background

Related engineering context: [Latency measurement](/journal/provider-monotonic-latency-measurement/); [Latency distributions](/journal/provider-latency-histogram-aggregation/).