What Is Actually Verified About Microsoft Aurora?

The most concrete evidence supplied for Microsoft Aurora is a reproducible-looking weather-forecasting workflow published in the context of open-source AI weather-model tooling. The workflow uses the microsoft-aurora package and imports Aurora components including Batch, Metadata, Aurora, and rollout. It is therefore reasonable to describe Aurora as a Microsoft-associated AI weather model that can be run through a documented Python-based workflow using meteorological initial conditions.

It is not reasonable, based on the supplied evidence alone, to turn that information into a complete product specification for “Aurora 1.5.” The verified context does not provide an official Aurora 1.5 release note, version changelog, benchmark table, model-card summary, commercial plan, public API terms, or deployment guarantee. The safest editorial distinction is therefore simple: Aurora is supported by the verified implementation material; the draft’s specific Aurora 1.5 announcement framing is not independently supported by the supplied sources.

This distinction matters because weather-model version numbers can imply a level of continuity, improvement, or production readiness that the available record does not establish. A version label is not a forecast score. It does not identify the resolution, geographic coverage, training data, error distribution, latency, compute requirement, or behavior during rare events. Those questions require documentation and evaluation, not inference from a name.

How the Verified Aurora Workflow Works

The example begins with initial conditions drawn from ERA5 data. ERA5 is used in the supplied workflow as the source of meteorological fields needed to initialize the forecast. The data is accessed through an Arraylake repository named earthmover-public/era5, using a read-only session. This tells developers what data-access path the example uses; it does not mean every Aurora deployment must use Arraylake or ERA5.

The example selects two timestamps: 2026-03-12T18:00:00 and 2026-03-13T00:00:00. The two timestamps are separated by six hours, matching the temporal structure shown in the workflow. Surface-level fields include variables such as 10-metre wind components, near-surface temperature, mean sea-level pressure, skin temperature, surface pressure, total column water, soil temperature, and soil-water variables. The example also fetches pressure-level fields for atmospheric temperature, wind, humidity, and geopotential-related information.

The workflow then maps selected source fields into the names expected by Aurora. Surface variables include two-metre temperature, 10-metre east-west wind, 10-metre north-south wind, and mean sea-level pressure. Atmospheric variables include temperature, wind components, specific humidity, and geopotential. The values are converted into PyTorch tensors before being placed into an Aurora Batch object together with static variables.

Geographic and temporal metadata are supplied through an Aurora Metadata object. The documented example passes latitude and longitude arrays and the final initialization timestamp. The resulting structure is then used with the Aurora model and rollout mechanism. This is the level of technical detail that can be verified: data preparation, variable mapping, tensor conversion, metadata construction, and forecast rollout. The supplied evidence does not justify claims about a particular neural architecture, parameter count, training recipe, or accuracy advantage for Aurora itself.

What Does the Seven-Day, 28-Step Example Mean?

The example defines STEPS = 28 and explicitly comments that 28 six-hour steps equal a seven-day forecast. This is the clearest numerical characteristic in the verified Aurora material. It describes the horizon and cadence of the example, not a universal limit or a guarantee that every Aurora configuration produces exactly the same output.

A six-hour cadence can be useful for medium-range...