Project overview
meteo by Azohra splits a published forecast into layers with hard edges: an engine derives and publishes versioned JSON documents, and packages validate, analyze, and render what it published. A club, pilot, researcher, or application can run any layer on infrastructure it controls. This page maps each layer’s responsibility.
The responsibility boundary
Section titled “The responsibility boundary”| Layer | Responsibility | Output or policy |
|---|---|---|
@azohra/meteo.grib and @azohra/meteo.j2k, the decoders | Provider bytes beneath the engine: GRIB2 sections, grids, and packing, and the JPEG 2000 codestreams inside ECCC messages | Decoded grids, gated bit-for-bit against ecCodes |
@azohra/meteo.forecast, the forecast engine | Provider input, model-dependent sampling, and quantities that require unpublished inputs or cross-run authority | Published profile values |
| Versioned JSON | Portable model, site, time, semantics, source-field, and derived-value documents | The data boundary between publisher and consumer |
@azohra/meteo.briefing npm package | Contract validation, pure document derivations, scene construction, hit-testing, and reference SVG | Reusable analysis and presentation primitives |
@azohra/meteo.station npm package | Live weather-station reading, derivation, and display — client, server, React, and custom-element bindings | The station capability |
@azohra/meteo.core, the shared foundation | Units, angle and wind-vector math with one sign convention platform-wide, zod primitives, and the upstream-failure vocabulary | The shared physical vocabulary every layer imports |
| This website | Documentation, logbook entries, and reproducible teaching figures | Technical learning and project reference |
| Downstream publisher | Location selection, schedule, hosting, retention, presentation, access, verification, and safety language | A complete publication for its audience |
An operator’s pipeline — the cron schedule, the site catalogue, the storage credentials — is the downstream publisher’s own repository, composing the engine; the platform ships the engine, not an instance.
Authority by quantity
Section titled “Authority by quantity”The forecast engine owns values that cannot be derived from the published profile alone, including its boundary-layer, thermal-velocity, cloud-base, and usable-lift series. The npm package owns pure functions of the published document and the reference renderer. Presentation parameters—such as timezone, windows, palette, overlays, and sink-rate choices exposed by the renderer—belong to the consumer.
The parameterized usableLiftTopM is the explicit exception spanning that boundary. The
implementation is the package’s pure function; the engine imports it and stores its 1.0 m/s
evaluation as the authoritative published value, so a consumer projecting another sink rate runs
the same code that produced the stored series.
The model catalogue is authoritative for capability and provider semantics. The model-capabilities guide explains how consumers render those declarations.