# Storm Forecast

Storm Forecast helps a team prepare before a warning exists. Users inspect possible severe weather over their service area, select a forecast period, and decide what to monitor. This is a proposed capability; no forecast-ingestion or forecast-notification implementation is established by these docs.

## Preparation before response

The information journey begins with **Forecast → Alert → Radar → Map → Impact → Report**. These are entry points, not a mandatory sequence. A forecast may never lead to a warning, and an observed storm may enter the system without a stored forecast. Forecast ingestion does not block the first [Storm Report](/stormtrust/product/platform-and-data/intelligence/storm-report/) release.

Use the forecast to prepare staffing and watch areas. Keep active warnings in [Storm Alert](/stormtrust/product/platform-and-data/intelligence/storm-alert/), and measured or radar-derived evidence in [Storm Radar](/stormtrust/product/platform-and-data/intelligence/storm-radar/). Forecast probabilities do not become observed hail, damaged roofs, or permission to dispatch a field team.

## Initial source scope

Start with NOAA/NWS Storm Prediction Center outlooks. The [NWS briefing reference](https://www.weather.gov/bgm/briefingmain) presents Day 1 and Day 2 hazard-specific outlooks, Day 3 severe-weather guidance, and Day 4–8 outlooks. The [NOAA outlook GIS service](https://mapservices.weather.noaa.gov/vector/rest/services/outlooks/SPC%5Fwx%5Foutlks/MapServer) is a discovery lead for geographic products, not an approved StormTrust source contract.

Preserve the native product, issue time, valid start/end, forecast day, hazard, category or probability definition, geography, and narrative. Verify the exact product version before decoding it. Do not relabel a combined severe-weather probability as hail probability, average nested contours, or turn a probability near a point into the probability that a county or roof will be damaged.

Longer-horizon guidance supports broader preparation. It does not locate a future neighborhood hail swath. Display the publisher's confidence and uncertainty statements, including cases where no risk area is drawn; absence of a polygon is not an all-clear.

## Time and revision behavior

Separate **issued at**, **valid for**, **retrieved at**, and **last checked**. A day label depends on the selected issuance and valid period, not the viewer's local calendar alone. Show UTC with an explicit local-time conversion.

A new issuance supersedes the live view while preserving older issuances for historical comparison. Keep the user's selected historical forecast pinned. Missing retrieval, expired guidance, and a publisher's low-risk assessment need different states. A later warning should link to the relevant forecast revision through a recorded association, never overwrite it.

## Watch and warning boundaries

A watch concerns possible severe weather across an area. A warning concerns severe weather reported or indicated by radar and calls for protective action. Keep these distinctions and the original NWS instructions visible; do not present a forecast as an imminent warning. See [NWS alert definitions](https://www.weather.gov/safety/thunderstorm-ww).

## Implementation readiness

Before implementation, approve the source interface, geometry and category mapping, update/freshness policy, historical retention, service-area intersection, and optional notification policy. Record retrieval and parsing evidence against a pinned product revision. The [journey contract](/stormtrust/product/platform-and-data/intelligence/journey-contract/) keeps forecast readiness separate from the first report release.