Storm Alert

Storm Alert starts a user's journey with a relevant warning. Opening the alert should restore the triggering warning, its issue time and affected area, then lead to Storm Radar and the associated storm on Storm Map.

The warning is an authoritative message from its publisher. A StormTrust notification is a separate delivery decision. Preserve both identities and the exact warning revision that caused the notification. Show issuer, event type, validity, source link, delivery time, and why the user received it.

A warning can arrive before matching MRMS evidence. Show Evidence pending and the available warning context; do not require a radar result before presenting an otherwise eligible warning. Later evidence can enrich the journey. It cannot silently rewrite the original notification.

An alert destination must retain warning ID and revision, linked storm ID when known, geographic scope, and source time. Authentication should return the user to that context. An expired or cancelled warning opens its history with an explicit status, rather than appearing as an active alert.

When no storm has been associated, open the warning area and say that the association is unresolved. Do not create a fake storm ID. A warning can relate to several storm tracks, and a track can have multiple warnings.

The Kansas City hail-alert application evaluates actual public NWS Severe Thunderstorm Warnings with observed hail in its declared market. It has a decision ledger, warning map, replay, and bounded team email delivery. It is isolated from the command center. This broader warning-first journey and its integration are requirements, not a change to that application's qualification or delivery policy.

The NWS API documentation ↗ provides the authoritative warning interface. Warning messages and MRMS radar products use distinct source contracts.

A monitor may target a property, customer, installed roof, commercial portfolio, territory, polygon, ZIP code, county, or radius.

A proposed monitor defines a target and policy thresholds. This example is not an implemented API or an approved threshold:

{
	"type": "property",
	"propertyId": "prop_123",
	"conditions": {
		"meshMinInches": 1.0,
		"confidenceMin": 0.7
	}
}

New event revision
      ↓
Find affected monitors
      ↓
Evaluate thresholds
      ↓
Apply deduplication
      ↓
Apply user policy
      ↓
Generate alert
      ↓
Deliver

Potential channels include in-app messages, email, SMS, webhooks, customer system actions, and push notifications if later clients support them.

The proposed policy avoids notifying users for every two-minute MESH update. Deduplication considers the event, monitor, threshold, prior alerts, severity increase, and meaningful revisions.

A new severity threshold crossing may create another alert.