Add a forecast model

A model is ready only when verified provider facts, catalogue declarations, builder behaviour, fixtures, and published documentation agree.

Verify before code

Provider fields, levels, semantics, sentinels, packing, schedules, domains, and access limits are facts that can change. Verify them against the live feed first and record a dated [verified YYYY-MM-DD] entry in the living forecast feed reference. Prior notes and community folklore are hypotheses, not sources.

1. Record the provider evidence. Update site/src/content/docs/docs/reference/forecast-model-feeds.mdx with source paths, exact field/level identifiers, timing, semantics, sentinels, packing, domain, limits, and licence or attribution obligations. Propose substantive prose rewrites to the author; add only the verified facts your model needs.
2. Declare the model. Add one entry to models.json. Slug is the identity; declare cadence, grid, horizon, deterministic/ensemble kind, experimental status, and every capability or absence exactly.
3. Choose a transport. Reuse the relevant Datamart or indexed NOAA primitives when the feed matches; add a new transport boundary only when its request, packing, or sampling model genuinely differs.
4. Build source-shaped hours. Normalize units, winds, intervals, and optional fields while preserving absence. Pass verified per-document semantics into the shared derivation.
5. Publish through shared utilities. Use shared rounding, current profile, manifest, history, and run-index conventions rather than custom output.
6. Register the supported command. Add the slug and dispatch to pipeline/src/windgram/cli.py; its registry test requires exact catalogue order. Add a scheduled invocation only when the model is ready to publish.
7. Prove the declaration. Add focused fixture-based tests for run selection, URLs/records, conversion, sentinels, domain guards, optional fields, semantics, output paths, and error handling. Assert catalogue capability parity.
8. Update affected writing. Keep the model capability guide and provider reference true. Add a research article only if the work yields a genuine dated result, not merely because a model was added.

Do not place a model in a frontend list, infer behaviour from its slug, or borrow capabilities from a similar system. A model exists for consumers when the catalogue declares it.

Run the focused Python tests, then the full gates listed in Tests by change. A provider smoke run is an explicit network operation performed only after fixture tests and review.