WeatherNext 3 gives energy and industrial planning teams a reason to reassess their weather inputs—not permission to wire a new forecast directly into dispatch. Google announced the model on 3 September 2026, with hourly initializations, observation-informed predictions and finer surface detail. The procurement catch is in the delivery documentation: hourly model runs do not mean forecasts arrive within an hour. Validate the specific data product, arrival time and applicable terms before approving a pilot.
What changed in WeatherNext 3
The Google announcement describes live geostationary satellite inputs, forecasts refreshed every hour and multiple spatial resolutions: approximately 5 km for selected station-calibrated surface predictions, 10 km for other surface variables and 25 km for atmospheric variables. WeatherNext 2's operational baseline used a 25 km grid and six-hour increments. Do not read “5 km” as a promise that every output variable uses that grid.
The research paper, dated 3 September, makes another distinction explicit: satellite observations supplement analysis inputs; the system does not eliminate numerical-weather-prediction dependencies. Its overview specifies two analysis frames and the most recent satellite mosaic frames. Different output heads also have different time resolutions. A new initialization every hour is not the same as every variable being sampled hourly.
For renewable-energy planning, the announcement highlights 100-metre wind, cloud cover and solar-radiation predictions. These are relevant inputs to turbine and solar-output models, not delivered megawatt forecasts for a particular site. Converting weather into power still requires the asset's power curve, availability, curtailment state and local calibration. A global forecasting improvement cannot establish a site's dispatch benefit on its own.
The delivery schedule matters more than the refresh headline
Google's dissemination schedule lists a 00:00 UTC main initialization with target delivery at 07:45 UTC in Cloud Storage and 08:10 UTC in BigQuery and Earth Engine. Those are published targets, not measured service levels from this article. The four main six-hourly cycles provide the full 15-day horizon. Interim hourly initializations are described separately as surface and station products, with target delivery at initialization plus 7 hours 10 minutes for Cloud Storage and plus 7 hours 25 minutes for BigQuery and Earth Engine.
The same page describes typical timing variation of about 15 minutes and occasional variation of 60 minutes or more. It was marked updated on 2 September at retrieval. That public schedule sits awkwardly beside the launch's real-time language; do not silently resolve the difference in the vendor's favour. Confirm the schedule for the exact product offered to your account and measure actual arrivals during shadow operation.
An energy planner needs at least four timestamps: initialization, target valid time, first availability to the customer and local ingestion. Add the decision cutoff as a separate business constraint. A backtest that picks the latest initialization before a trading decision, without checking whether its files had arrived, can evaluate information that the operator never had. This is a product-availability test, not merely a model-accuracy test.
Access: datasets are not custom inference or open weights
The updated forecast-access guide explicitly lists WeatherNext 3 through Cloud Storage, Earth Engine and BigQuery. Operational dataset access requires an allowlist request using a Google Account; the guide gives a typical review time of 5–7 business days, not an entitlement or guaranteed deadline. A paid Cloud contract is not required to request access. Global forecast coverage is not proof of EU-region storage, EU-only processing or a particular enterprise SLA.
The surfaces expose different products. Cloud Storage provides the raw 64-member ensemble and summary statistics. BigQuery and Earth Engine expose precomputed surface means and percentiles, according to the access guide. Choose SQL summaries for asset joins when those statistics are sufficient; choose ensemble data when the experiment genuinely needs joint scenarios across sites and time. Marginal percentiles do not preserve the full joint uncertainty needed to simulate a portfolio's power output.
Do not extrapolate dataset access into WeatherNext 3 custom inference. The managed-inference guide retrieved for this article still states that only WeatherNext 2 is available. Likewise, the open-source guide lists WeatherNext 2, Gen and Graph—not WeatherNext 3 weights. Treat a self-hosted WeatherNext 3 deployment as unverified, rather than assigning it the predecessor's availability or licence.
Pricing and licensing: a discrepancy to resolve before reuse
The linked experimental data terms, marked last modified 12 November 2025, say Google does not currently charge for access and reserves the ability to introduce fees with notice. That statement does not make storage, query execution, transfers or custom inference free. No WeatherNext 3 end-to-end production price or guaranteed SLA was established in the sources reviewed. Budget the selected data surface, ingestion, retained snapshots and ongoing validation separately.
There is also a concrete documentation mismatch. The updated disclaimer page describes historical data using a one-hour boundary, while the linked PDF terms still use 48 hours. The distinction concerns the time the data relates to; it must not be replaced with an invented rule about file-download age. Do not assume the more permissive interpretation governs redistribution. Ask Google for the applicable version in writing and have counsel review the intended use, recipients and retention. This article identifies the inconsistency; it does not decide which legal terms prevail.
Decision checklist for an energy-planning pilot
1. Freeze the purchased data product
Record the model identifier, data surface, variables, units, spatial grid, ensemble or summary format, forecast horizon and dataset version. Obtain a sample through the intended account before committing to the integration. Acceptance evidence is a reproducible ingestion manifest—not a screenshot from Search or Maps.
2. Prove availability at the decision cutoff
Persist first-seen object times, ingestion completion and missing-cycle events. Replay decisions using only records available before the original cutoff. Inject a late delivery and a missing initialization. The pilot passes this checkpoint only when stale or incomplete data is flagged and a declared fallback takes over. Use the existing failure-domain placement approach to keep a cloud-data outage from becoming an implicit site-control dependency.
3. Compare the actual business decision
Run the existing forecast and WeatherNext 3 through the same downstream power-conversion and planning logic. Compare site and horizon segments, ramp-event errors and the operator's chosen cost metric. Separate improvements caused by better weather inputs from changes in asset calibration. Set acceptance thresholds with the process owner before seeing results; no universal percentage improvement is justified here.
4. Keep forecast confidence separate from control authority
Check uncertainty calibration against local observations; do not assume an ensemble's spread covers every operational risk. Google's paper reports limitations, including under-dispersion in some cyclone-intensity evaluations. That result is not a wind-farm calibration score, but it is a reason not to treat uncertainty bands as guarantees. Apply the OT observation–inference–control boundary: advisory output must not acquire unrestricted actuator credentials.
5. Make the pilot reversible and contract-aware
Keep the previous approved forecast source and a tested switchback procedure. Bind parsing logic, site mapping, calibration and expiry rules into the same release record using the model-nameplate and rollback pattern. Resolve access rights, documentation discrepancies and data-location requirements before promoting the pilot. For safety-related decisions, retain official meteorological warnings and the established operating procedure as independent inputs.
What the evidence does not establish
This article is based on the announcement, research paper and developer documentation checked on 6 September 2026. It does not report a hands-on WeatherNext 3 deployment or an independent site-level benchmark. Google links to Brightband's live evaluations; no independent leaderboard result is asserted here. Vendor-reported forecast skill and finer grids are promising, but neither proves a reduction in balancing costs, safety incidents or procurement risk for a German operator.
Google itself describes the forecasts as experimental and warns against relying on them as the sole source for protecting life or property. The immediate next step is therefore a bounded data-access and shadow-evaluation exercise, not automatic dispatch migration. For support defining the ingestion contract, availability replay and approval boundary, use the AI automation and implementation services. The useful deliverable is a documented go/no-go decision with measured latency, site-level evidence and a working fallback.
