Storm Replay lets users play, pause, seek, and compare a storm's retained evidence over time. A supervisor can explain why a county was prioritized; a canvasser can review the evidence behind a report; the product team can test how the same journey behaves with a fixed historical window.
MRMS history reads, a map history bar, and playback controls already exist. The complete product contract—including revision selection, historical knowledge cutoffs, report links, and durable evidence retention—still needs implementation and verification. The shared contract separates existing code from those requirements.
Enter from Storm History, a map timeline, or a report's evidence link. Keep the selected scope and revision while advancing observation time. Play, pause, previous/next observation, and seek should have keyboard and touch controls, with a readable event list that does not depend on animation or color.
Show actual observation times and visible gaps. Playback speed changes how quickly the user reviews frames; it does not change storm duration. If a frame is missing or cannot load, mark the gap and distinguish retry from skipping. Do not animate an interpolated path as measured movement.
Replaying evidence does not resend alerts, deliver reports, or dispatch a team. A retrospective report or analysis is a separate reviewed action. Historical warning instructions remain historical; current safety information has its own check time and context.
| View | Question |
|---|---|
| Evidence timeline | What does the selected retained evidence show at each observation time? |
| As known then | What had StormTrust actually received and made available by a stated cutoff? |
| Retrospective comparison | What does a new rule or later evidence change relative to the original result? |
The evidence timeline uses pinned versions, including corrections only under its declared selection policy. “As known then” additionally needs retained receipt and availability history. Late-arriving evidence must not appear before it was available. If those records do not exist, label that view unavailable; source observation time alone cannot reconstruct past knowledge.
A retrospective rerun creates a new analysis with its own rule and data versions. It cannot replace a published report or masquerade as the decision that was made at the time.
While replay is selected, new live revisions should be buffered behind an explicit Jump to latest action. Preserve viewport, selected county or work area, layers, report context, and playback position on reconnect. A live update must not silently rerank an earlier report or switch a paused view to another storm.
The first report slice needs reliable review of a retained pilot window and its published evidence. Broader multi-event comparisons and full knowledge-cutoff simulation can follow when their data contracts are proven. Use the acceptance scenarios for both customer journeys and implementation tests.