Downstream access
meteo by Azohra ends at inspectable static artifacts and reusable rendering tools. Authentication, membership, launch discovery, product navigation, alerts, retention, and operational language belong to the downstream application.
Choose access at the hosting boundary
Section titled “Choose access at the hosting boundary”| Publication need | Downstream implementation |
|---|---|
| Public club archive | Static host or object storage with explicit retention |
| Member-only current output | Application or edge authorization in front of the static tree |
| Build-time chart pages | Fetch/validate during the downstream build and deploy generated HTML/SVG |
| Custom interactive viewer | Validate documents, build a scene, and own browser state and accessibility |
The JSON contract does not contain users, roles, sessions, launch permissions, or API keys. Adding them would couple portable forecast documents to one publisher’s policy.
Read independently cached files safely
Section titled “Read independently cached files safely”Static storage can expose a new manifest before the matching profile cache
entry expires, or the reverse. TypeScript consumers should use
loadForecast() from @azohra/meteo.briefing/transport, which returns a run-consistent
pair, a pair flagged stale, or a discriminated miss — the
transport guide defines that contract.
Consumers own caching, credentials, fallback selection, and stale-state
presentation.
At every access level, keep provider attribution with derived material and state the publisher’s operational limitations.
The rendered-page example ends with a directory that can be copied byte-for-byte to any of these downstream boundaries. No meteo process remains running after generation.