StormTrust uses one event-and-revision contract for live and historical MRMS. Retention and lifecycle differ, but the decoder, provenance, manifest, and read paths remain the same.
Storm History and Storm Replay are customer capabilities built on these foundations. Their product and testing contract owns the required discovery, time modes, access, and acceptance behavior. Current bounded reads and benchmark retention do not establish a complete customer archive.
For configured cadence, queue retries, persistence checkpoints, and recovery limits, see Polling and triggers.
The live mrms-conus event is a national feed container. Named benchmarks are
selected replay windows. These existing revision paths do not establish physical
storm detection or warning-to-storm association. See Storm events and revisions
for that product requirement and Storm Map
for the intended individual-storm journey.
MESH and reflectivity source observations may differ by seconds. The ingestion service assigns each observation to a two-minute UTC window and publishes a revision only after both required products exist.
Source products
↓
Two-minute observation window
↓
Partial revision
↓ both products present
Immutable R2 manifest
↓
Ready revision with monotonic sequenceA corrected source object creates a new source version and a new event revision. It does not overwrite the provenance of the earlier revision.
org/apps/data/worker/mrms-history.ts returns up to 100 event records. Revision
reads default to 24 frames and allow 2–360. readEventHistory in revisions.ts
selects ready rows by descending publication sequence, then reverses that
bounded result for the response. This is publication order, not a guaranteed
observation-time or as-known-then reconstruction when corrections arrive late.
The product replay policy and complete-range retrieval remain required work.
The D1 outbox records a ready-revision event in the same processing flow that publishes the revision. A dispatcher sends it through the revision Queue. One Durable Object per event broadcasts the notice to connected WebSocket clients.
The notice contains an event ID, revision ID, sequence, observation time, bounds, and immutable manifest URL. It is an invalidation signal, not the authoritative payload. Clients read revisions from the API after receiving it.
The map follows a new revision only when the user is at the live edge. While a user scrubs an earlier frame, the interface preserves the selected frame, viewport, filters, layers, and result selection. It presents one Jump to latest action with the number of buffered revisions.
| Class | Purpose | Lifecycle |
|---|---|---|
| Operational | Maintain the current national feed and recent history | Raw objects expire after 72 hours; derived frames expire after 30 days |
| Benchmark | Reproduce a named event for replay and evaluation | Event-prefixed raw inputs, frames, and manifests are excluded from operational cleanup |
The repository defines kansas-city-hail-2026-03-10 from 22:30 UTC on March
10 through 04:30 UTC on March 11. The UTC window intentionally crosses a date
boundary. A National Weather Service local storm report ↗
recorded 3-inch hail southeast of Weatherby Lake at 6:30 PM CDT on March 10, 2026. That report makes the window useful for replay; it does not label every
parcel in the window as damaged.
Use Inspect a local benchmark for the runnable procedure. It uses the shared local launcher to prepare D1, start the service graph, and request the checked-in benchmark.
Production deployment does not expose that route publicly. The two-minute data scheduler reads the checked-in benchmark registry and invokes each incomplete definition after migrations and deployment. Completed D1 backfill records make that bootstrap a no-op on later runs.
The backfill endpoint accepts historical windows no longer than 12 hours. It queries every UTC date touched by the window, records source versions in D1, and sends the same schema-versioned jobs as live discovery.
MRMS plus parcels can calculate exposure features. They cannot, by themselves, measure whether a roof was damaged or whether an opportunity converted. Probability accuracy requires an outcome label with an allowed use and known observation time.
Each evaluation case pins:
- Storm event and event revision.
- Parcel stable ID and parcel dataset version.
- Immutable feature snapshot.
- Outcome label, label source, and label observation time.
- Consent or allowed-use classification.
- Model version and evaluation release.
Split training, calibration, and test cases by storm event or time window, not random parcel rows from the same storm. This reduces spatial and temporal leakage. Keep a benchmark test set frozen. Report calibration and performance by geography, hail range, property class, source coverage, and data freshness.
Do not use the March 10 report as a property-damage label. Use it to verify temporal alignment, replay behavior, source lineage, and exposure-feature generation until authorized property outcomes exist.