Weather Data Reproducibility

Weather Data Reproducibility creates a compact provenance manifest identifying the exact weather inputs, subsets, software, transformations, and output artifacts a run used, and verifies that manifest before anyone claims the result can be replayed or reproduced. It records and checks lineage only - it does not discover or download data itself, and pairs with whatever model, observation, radar, or satellite fetching skill actually pulled the data.

It starts by forcing a decision about which claim the workflow actually supports: traceable (source and processing history can be audited), replayable (the same identified inputs can still be retrieved and the procedure rerun), bitwise reproducible (a rerun in a pinned environment is expected to produce identical bytes), or scientifically reproducible (equivalent inputs and methods produce the same conclusion within a stated tolerance) - since mutable remote objects, floating software versions, lossy images, and platform-dependent code can make the stronger claims impossible no matter how much is logged.

def write_manifest(path, manifest):
    path = Path(path)
    temporary = path.with_suffix(path.suffix + ".tmp")
    payload = json.dumps(
        manifest, ensure_ascii=False, sort_keys=True, separators=(",", ":")
    ) + "\n"
    temporary.write_text(payload, encoding="utf-8", newline="\n")
    os.replace(temporary, path)

The manifest is a versioned JSON document that keeps request intent separate from what was actually resolved: dataset/product/requested-valid-time on one side, actual initialization/forecast-hour/valid-time/provider on the other. For every input it records provider, exact key or immutable URL, ETag as opaque identity (not assumed to be an MD5 or SHA digest, since that varies by provider and upload method), Last-Modified, content length, and a locally computed SHA-256 of the actually materialized bytes. When only part of a source was used - a GRIB2 byte range, a Zarr chunk, an API query - it records the exact selection (inventory hash, byte ranges, chunk keys, query parameters) separately from the full object's identity, because the source object alone is insufficient proof of what was actually used.

Time semantics get explicit UTC fields per domain rather than one ambiguous timestamp: model initialization/forecast-lead/valid-time, station observation/correction/ingestion time, radar/satellite scan start and end. Processing capture is deliberately narrow - application version and commit (including dirty-tree status), decoder and library versions, unit conversions, QC decisions, and a deterministic random seed if randomness is present - rather than dumping an entire unrelated environment because it's easy.

Replay verification re-resolves every immutable object identity and fails if something changed unless the reproducibility contract explicitly allows an equivalent substitute, reapplies the recorded selection and confirms the materialized-subset hash, recreates the pinned environment, and compares artifact hashes (for bitwise claims) or documented metrics and tolerances (for scientific claims) - reporting the first mismatch with its role, expected value, and actual value, and writing a new run manifest that references but never overwrites the original.

Temporary data lifecycle rules tie in directly: the final artifact and its manifest are written before request-owned input files are deleted, cleanup lives in finally so failures don't leak large GRIB2/NetCDF/radar files, a shared user cache is never deleted as request cleanup, and if raw inputs get deleted from a mutable or short-lived remote source, the run is downgraded to traceable rather than claimed replayable.

Use it when a map, sounding, time series, or benchmark needs to be auditable; when inputs came from mutable URLs, mirrors, byte-range subsets, or caches; when a result must distinguish model initialization from forecast lead and valid time; when temporary GRIB2/NetCDF/radar/satellite files will be deleted after processing; when two outputs differ and their inputs or environment need comparing; or when a publication needs machine-readable data and software provenance.

Do not claim bit-for-bit reproducibility merely because a source URL and run time were logged - that claim requires pinned identity, environment, and verified replay, not just a log entry.

Input is a weather-data processing run's sources, selections, software versions, and output artifacts. Output is a versioned JSON provenance manifest recording request intent, resolved data identity, exact input selections and hashes, processing environment, and artifact checksums, plus (on replay) a new manifest reporting the first mismatch found against the original, if any.

Atmospheric data engineers and researchers who need a run's inputs and processing to be auditable or replayable - distinguishing what can actually be proven (traceable, replayable, bitwise, or scientifically reproducible) instead of assuming a logged URL and timestamp are enough.