Model manifest
Each published model directory contains a manifest.json. It is a small
document that says which run was published, for which sites, over which
forecast hours, with the build’s statistics. The larger site profiles sit
beside it.
On the wire
| Fact | Value |
|---|---|
| Published at | <model>/manifest.json |
| Parse | parseForecastManifestJson from @azohra/meteo.briefing/contract |
| Zod authority | forecastManifestSchema |
| JSON Schema | manifest.schema.json |
| Discovery | one per published model directory; runs.json at the data root indexes every current manifest’s publication identity, but it does not carry the manifest’s site list or forecast extent |
Stable fields
| Field | Meaning |
|---|---|
schemaVersion | Manifest contract version, pinning MANIFEST_SCHEMA_VERSION (1) |
model | Catalogue slug and directory identity |
referenceTime | Provider model initialization time |
generatedAt | Time this publication was generated |
firstForecastHour, lastForecastHour, forecastHours | Published step extent and count (forecast and smoke models) |
memberCount | Ensemble membership; absent on deterministic manifests |
sites | Published site name/slug pairs for this model run |
stats | Stable accounting core plus optional transport-specific numbers |
The stable stats core is downloads, downloadBytes, retries, and
durationMs. Other numeric keys can change, so use them only for
diagnostics.
Publication identity
Treat (referenceTime, generatedAt) as the publication identity. A new
generatedAt with the same referenceTime is a corrected republication, and
you should ingest it again. It does not change the schema.
Compatibility defines the
identity pair and what follows from it.
The manifest and the profile you read with it must describe the same model
and referenceTime. Static files cached separately can disagree for a short
time while a publish is deploying. In TypeScript, use
loadForecast() from @azohra/meteo.briefing/transport,
which checks the pair, instead of making two fetches yourself.
Validate the document
Use parseForecastManifestJson from @azohra/meteo.briefing/contract. A
404 means the model is not published at that root. Treat an invalid document
as unavailable too, and do not guess its missing fields in view code.
The observation datasets (goes18-dsr, goes18-aod) publish a different
manifest. It keeps the identity and stats fields, but carries
firstObservedAt, lastObservedAt, and observationCount in place of the
forecast-hour extent, and its referenceTime equals lastObservedAt.
parseForecastManifestJson rejects it. Parse it with
parseObservationManifestJson, or with parseManifestJson when you do not
know the dataset kind. The
observation document reference
covers these datasets.