Weather receipts: a format, not a vibe.
A “receipt” is the intended structured explanation for each value: where it came from, what rules selected it, what validations it passed/failed, and why any fallback happened. Goal: no silent overrides — once receipts ship.
This page defines the contract. CurrentWeather.info already tags values obs/model/derived and can show “hybrid” views when different fields win from different sources. A full exportable receipt object (including per-field validation + fallback logs) is not shipped yet. When it is, it will follow this spec.
rw-receipt-v0.1 is the current public specimen format. Future versions will be additive when possible and always logged in Updates.
- receipt_version (format version)
- ruleset (decision logic version)
- generated (timestamp + timezone)
- input (what user supplied: lat/lon, station id, etc.)
- value (normalized units)
- provenance ( obs / model / derived )
- source_id (station/model identifier)
- freshness (age + window)
- validation (pass/fail list)
- fallback_reason (required if not primary)
Specimen below is illustrative. CurrentWeather does not export this receipt object yet.
receipt_version: rw-receipt-v0.1
ruleset: rw-core-2025-01
generated: 2025-01-01T12:00:00Z (illustrative)
input: lat/lon → nearest station
temperature:
value: 72°F
provenance: obs
source_id: KATL
freshness: 6m / 90m-window
validation: [freshness✓, bounds✓, consistency✓]
wind_speed:
value: 8 mph
provenance: model
source_id: open-meteo
fallback_reason: obs missing/invalid
validation: [bounds✓]Notes: “validation” is intentionally explicit. If a field fails a check, it’s recorded. If it falls back, the reason is recorded. If a view mixes winners, the view may be “hybrid” — but each field remains tagged.