claims
How Storm Data Shows Up on a Claim
Florida law ties the date of loss to NOAA verification, which tells you how load bearing the public storm record is on a claim file.
A statute that writes NOAA into the definition
Almost every disagreement on a storm claim is really a disagreement about a date. One state put that into its statute books. Section 627.70132 of the Florida Statutes provides that for claims resulting from hurricanes, tornadoes, windstorms, severe rain, or other weather-related events, the date of loss is the date the hurricane made landfall or the date the event is verified by the National Oceanic and Atmospheric Administration.
That is worth sitting with. A state legislature took the single fact that decides whether a claim is timely and tied it to a federal data product. The same section bars a claim or a reopened claim unless notice was given to the insurer in accordance with the terms of the policy within one year after the date of loss, and bars a supplemental claim unless notice came within eighteen months of the date of loss. The date is the hinge, and a federal agency's verification is what sets it.
This is Florida law, and only Florida law. Other states define the date of loss on their own terms, or leave it to the policy language. Read your own state's statute and read your own policy before relying on any of this. Nothing on this page tells you what your deadline is.
What the Florida rule does establish, wherever you work, is that the public weather record is not background color on a claim file. In at least one state it sits inside the operative definition. So it is worth knowing precisely what that record contains, when each piece of it arrives, and what each piece is labeled.
The near real time layer, labeled preliminary
The fastest public record is the daily storm report. The Storm Prediction Center builds it from NWS Local Storm Reports, usually sent in near real time, and groups them into a day that runs from 1200 UTC to 1159 UTC rather than midnight to midnight. The current day's page refreshes every ten minutes, starting at 6 AM CST or 7 AM CDT, and yesterday's page covers 6 AM to 6 AM local time. Older days are retrievable by date, and SPC publishes the same reports as KML files and through a REST service.
Two labels matter here. SPC shows these reports as is and calls them preliminary. The daily report page carries the notice All Reports Are Considered Preliminary. SPC also does not decode non-thunderstorm Local Storm Reports, so hurricane-related wind will not turn up in this particular feed. For post-storm summaries, SPC points users to NWS Storm Data through NCEI.
Behind those reports are people. Local NWS offices gather the information from sources such as damage surveys, emergency managers, and SKYWARN spotters. A report exists because somebody observed something and passed it along.
The record that arrives months later
The authoritative version runs on a much slower clock. According to the NWS, the Storm Data publication and the Storm Events Database reports both land 90 to 120 days after the event. That database covers tornadoes since 1950, severe thunderstorms since 1955, and all other weather events since 1996.
One detail on that page is easy to skim past and hard to work around. Certified, official copies have to be requested from NCEI, not from a local NWS office. If a file needs a document that functions as an official record of the event, that is where it comes from, and a local office cannot supply it.
So the sequence is fixed and it is not optional. Everything that happens in the first weeks after a storm happens against a record that is explicitly provisional. The version that certified copies come from lands roughly a quarter of a year later.
Radar archives answer a different question
Radar-derived history is the third layer, and it is the one most often read as more than it is. NCEI's Severe Weather Data Inventory holds NEXRAD Level-III hail signatures, storm cell structure, mesocyclone and tornado signatures, and lightning strikes from the Vaisala network. It is reachable through an interactive map, a bulk CSV download of the whole database over HTTP, and web services, in Shapefile, KMZ, CSV and XML.
The page is blunt about scope. SWDI adds no quality control beyond archival processing. Missing data does not mean no severe weather occurred. And much of the automatically derived content is radar-based, representing probable rather than confirmed conditions. NCEI also notes that it is migrating data to the cloud, which can cause temporary access delays, and that order fulfillment is intermittently degraded.
None of that is a criticism of the data. It is a definition of what the data is for. A radar hail signature over a neighborhood is a reason to go look. It is not a confirmed hailstone on a specific roof.
The live feed does not hold history
The free NWS web API at api.weather.gov is where most code against the public record starts. No key is required, though every request must carry a User-Agent header identifying the application, and the page says API keys will be introduced later.
What it will not do is history. There is no long-term archive behind it, and its alerts endpoint reaches back only seven days. NCEI hosts the official archive of NWS alerts. On radar, the API serves only radar status data, with display imagery coming from separate services. A pull made six weeks after a storm against the live API will not return the warning that was in effect that afternoon. That has to come from the archive, or from a copy somebody kept.
The gap between the decision and the record
Put the three layers side by side and a structural gap appears. The record available while a claim is new is labeled preliminary. The record that certified copies come from arrives 90 to 120 days after the event. Radar history is available right away but is labeled probable.
Nothing in the public record promises that the early version and the later version agree. Reports get added as damage surveys come in and as local offices work through what reached them. That is the reporting system operating normally, not a flaw in it. But it means a file assembled in week two and a record pulled in month five can read differently, and whoever kept the week-two copy is the only party who can show what the record said at the time.
Why a missing report proves so little
The most common misuse of this data is treating silence as a finding. The NWS addresses it directly: if an event is missing from both Storm Data and the Storm Events Database, it was not reported to the National Weather Service. That is a statement about reporting, not about weather.
SWDI says the same thing in its own words: missing data does not mean no severe weather occurred. Reports come from observers, and observers are not evenly spread across the map. An absent report is consistent with no storm, and equally consistent with a storm nobody reported.
This cuts in both directions. Absence is weak support for the position that nothing happened, and weak support for the position that something did. The defensible sentence is narrower: the public record contains no report for that location and that date. That is smaller, and it is true.
What to actually do with a pull
Three habits cover most of it.
Name the source precisely. "NOAA" is not a source. SPC's preliminary daily report for a specific 1200 UTC to 1159 UTC day is a source. A Storm Events Database entry is a different source. An SWDI hail signature is a third, with a different label attached to it. Writing which one you used costs a sentence and settles arguments later.
Record the date you pulled it. The early record changes as reports come in. A pull is a snapshot of a moving record, and a snapshot with no timestamp cannot be reproduced or defended.
Keep the pull. Save the file itself, not a photograph of a map on a screen, and save it the day you got it. When the Storm Data version lands 90 to 120 days after the event and reads differently, the only way to show that it changed is to still hold the earlier copy.