HailScore™ Methodology

1. Executive summary

HailScore™ is an address-level hail exposure score on a 0–100 scale, derived from public meteorological datasets published by the National Oceanic and Atmospheric Administration (NOAA) and the National Weather Service (NWS). The score is intended to give homeowners, roofing professionals, public adjusters, and insurance carriers a calibrated, reproducible answer to the question:

How much hail damage has this specific property been exposed to, and how recent and severe is that exposure?

The score is computed in real time from six independent data feeds, three of which update within minutes of severe weather. The scoring components, decay behavior, and material adjustments are described in §4 and have remained stable since the v4 calibration of February 24, 2026.

This document is the authoritative reference for the scoring methodology and the data behind it. It is intended to support due diligence by insurance carriers, reinsurers, independent adjusters, and academic reviewers. Comments and corrections may be sent to hello@myhailscore.com.

2. Problem definition

Hail is the leading cause of severe-convective-storm insured loss in the United States, exceeding $20 billion in annual claim payouts in recent years per insurance industry reporting. Despite the scale of the loss, three operational gaps persist for property-level decision-making:

1. Temporal lag. NOAA's finalized hail-event datasets (Storm Events, SWDI radar) carry a 60–90 day quality-control lag. A roof hit on June 15 may not appear in finalized records until mid-September. Adjusters, contractors, and homeowners need an answer the day after the storm.
2. Spatial granularity. Most existing hail-event lookups operate at the storm-cell or city level, not the property level. A single supercell may produce dramatically different impacts on properties three blocks apart.
3. Integration of disparate feeds. Severe-weather data exists across at least six NOAA/NWS publications, each with different latency, spatial resolution, and confidence characteristics. A score that synthesizes them must be explicit about how.

HailScore is built to close those three gaps. It ingests live and finalized data continuously, scores at the geocoded street-address level, and publishes its full methodology — this document — so that downstream users can audit the inputs and reproduce the outputs. Every event surfaced in a report cites the underlying NOAA / NEXRAD / MRMS record ID so the source can be re-verified independently.

3. Data sources

Every HailScore is derived from one or more of the following sources. All are publicly available and cited individually on every generated report.

3.1 NOAA MRMS — Multi-Radar Multi-Sensor (live)

The Multi-Radar Multi-Sensor system at NOAA's National Centers for Environmental Prediction (NCEP) fuses every NEXRAD WSR-88D radar in CONUS into a continuous 0.01° (~1 km) grid updated every two minutes. The product HailScore ingests is MESH_Max_1440min: maximum estimated hail size at each grid cell over the trailing 24 hours, expressed in millimeters and converted to inches.

We pull MESH grids every 4 hours from https://mrms.ncep.noaa.gov/data/2D/MESH_Max_1440min/. Cells with values ≥ 0.75″ within the CONUS land bbox are written to our live-radar store with the grid's valid-time timestamp. Latency from radar observation to a row in our database is typically under two hours, including ingest interval and processing time.

Retention: MRMS is the live/near-real-time feed; NCEP does not retain an indefinite historical archive on the public endpoint and our table mirrors that — we currently keep the most recent rolling window (typically the last several weeks) for low-latency lookups. Validation of events older than that window relies on the finalized NEXRAD SWDI record (§3.2) and the NOAA Storm Events Database (§3.3), both of which carry the full historical range from 2015 forward.

The MESH algorithm itself is documented in Witt et al. (1998) and the WSR-88D Build documentation maintained by the NWS Radar Operations Center. Estimation skill for MESH degrades for hail sizes above approximately 3.0 inches, where saturation effects in the underlying reflectivity moment become significant; HailScore reflects this by capping the size-score contribution at the same threshold (§4.1).

3.2 NEXRAD via SWDI (finalized radar)

The Severe Weather Data Inventory (SWDI) published by NOAA's National Centers for Environmental Information (NCEI) provides finalized NEXRAD Level-III hail-signature records (nx3hail) after a 60–90 day quality-control review. HailScore has ingested every nx3hail record ≥ 0.75″ for the contiguous US from 2015 onward — 6.1M+ finalized radar records in our database. This dataset is the historical backbone of the score and is continuously appended as SWDI finalizes more recent quarters.

3.3 NOAA Storm Events Database

The Storm Events Database aggregates spotter reports, emergency-management reports, and law-enforcement observations of hail events ≥ 0.75″, after quality control by NCEI. HailScore uses these as ground truth for event verification (§4.4) and for the largest-event narrative on each report. Approximately 299,000 verified hail events are currently indexed.

3.4 SPC Local Storm Reports (LSR)

The Storm Prediction Center publishes preliminary ground reports within hours of observation. We poll the day and previous-day CSV exports continuously. These reports are not as quality-controlled as Storm Events but provide significant temporal advantage and serve as a partial bridge in the gap before MESH/NEXRAD finalization.

3.5 NWS Active Alerts (warning polygons)

The NWS API publishes Severe Thunderstorm Warnings and Tornado Warnings with explicit polygon geometry and parsed parameters including maxHailSize and maxWindGust. We poll api.weather.gov/alerts/active every 60 seconds during the April–September hail season. When a polygon contains a queried address and the alert is unexpired, the report surfaces a real-time warning banner. These alerts do not directly enter the score but are surfaced to the user.

3.6 CoCoRaHS

The Community Collaborative Rain, Hail and Snow Network is a volunteer-staffed precipitation observation network coordinated by Colorado State University and the Cooperative Institute for Research in the Environmental Sciences. Observers record hail size at their specific property after each event. CoCoRaHS reports supplement SPC and Storm Events ground truth at finer spatial resolution.

4. Scoring algorithm

The HailScore is a weighted combination of four components plus a cumulative-damage bonus, optionally multiplied by a roof-material factor and clipped to 0–100. In rough order of contribution, the components are:

• Hail size — magnitude of the most damaging event near the property (a primary driver)
• Frequency — how many qualifying events have occurred (a primary driver)
• Recency — temporal weighting of the most recent damaging event (a secondary driver)
• Cumulative damage — total weighted hail volume across all events (a small bonus)

Each component is described below in general terms. The exact weights, decay constants, and calibration coefficients are part of HailScore's proprietary implementation and are not published; the goal here is to make the approach transparent and reproducible in structure, not to specify the production constants.

4.1 Hail size contribution

For each event near the property, a hail-size factor is derived from the estimated stone diameter in inches.

The factor is intentionally non-linear: insurance industry damage thresholds begin near 1.0″, escalate sharply between 1.5″ and 2.0″ where shingle puncture and metal denting become common, and saturate above ~3.0″ where total replacement is essentially certain regardless of additional size.

The hail-size contribution to the score is taken from the single most damaging qualifying event, attenuated by its distance from the property (§4.4). It is one of the two largest components of the score.

4.2 Frequency contribution

Frequency captures cumulative storm exposure. Each event contributes its full distance-and-recency-weighted value, summed across all events in the lookup window. The total is compressed on a logarithmic scale so that a property with five events does not receive five times the points of a property with one — the first events matter most and additional events add diminishing weight.

Frequency is the other of the two largest components of the score.

4.3 Recency contribution

Recency weights recent hail more heavily than old hail, using an exponential decay with roughly a 10-year half-life. For a roof installed more recently than that window, the effective half-life is shortened proportionally so that scoring is normalized to the roof's own lifetime. Recency is a secondary component of the score.

4.4 Distance decay

All event contributions are weighted by a steep distance decay measured from event coordinates to the geocoded property location. The decay is deliberately steep: hail swaths are typically 0.5–2 miles wide and damage attenuates rapidly beyond the swath core, so a storm a few miles away contributes only a small fraction of the weight of one directly overhead. The lookup window extends to roughly 8 miles, beyond which an event's contribution is effectively zero.

4.5 Cumulative damage bonus

In Colorado specifically, our calibration data showed that repeated moderate hail can accumulate more total damage than a single severe event. A small bonus is added for cumulative weighted hail volume across all events, also on a logarithmic scale so that it saturates rather than growing without bound.

4.6 Roof material multiplier

After raw scoring, a material-based multiplier is applied to reflect documented differences in hail impact resistance and — critically — the financial-exposure asymmetry created by insurance matching-of-materials clauses. The exact multipliers are proprietary; their direction relative to the architectural-shingle baseline is shown below.

Note that modern architectural asphalt shingles are typically Class 3 under UL 2218 by default — Class 3 is not surfaced as a separate tier because it equates to the baseline. Class 4 is the explicit upgrade product line carriers reward with premium discounts. 3-tab is split out because its near-discontinuation makes it materially different from a claims-outcome perspective: any qualifying damage usually forces full roof replacement, regardless of how localized the damage is.

4.7 Final score and tiers

The component contributions and the cumulative-damage bonus are summed, the roof-material adjustment is applied, and the result is clipped to the 0–100 range. The final score maps to a tier:

The score is computed server-side on every lookup. The same address, with the same roof inputs and the same data state, will always produce the same score.

5. Data pipeline

HailScore is hosted on Vercel with a Neon PostgreSQL 17 + PostGIS 3.5 backend in US East 1. Ingestion runs from two independent compute environments for redundancy:

1. MRMS ingest — a Python pipeline executes every 4 hours via GitHub Actions and via macOS launchd in parallel; duplicate observations are de-duplicated on insert.
2. NWS alerts poll — a script polls the active-alerts feed every 60 seconds during hail season (April–September), storing polygon geometry, parsed hail size, and expiration.
3. SWDI batch — periodic backfill of finalized NEXRAD hail records as NOAA publishes additional quarters.
4. Storm Events + CoCoRaHS + SPC LSR — periodic synchronized batch updates.

On a lookup request, the address is geocoded via Mapbox to latitude/longitude. HailScore then queries all six government data sources in parallel for events near that point, de-duplicates overlapping detections, scores the result per §4, and stores the score with its inputs. Median end-to-end response time is under 500 ms when cached and under 3 s on cold lookups including external API enrichment.

Every score retains the latitude/longitude, roof inputs, score, tier, and a snapshot of the storm-event count and largest hail size at the time of computation. This enables reproducibility audits and forms the foundation of the validation roadmap described in §7.

6. Calibration

The v4 calibration of February 24, 2026 was performed against a reference set of properties with confirmed hail-damage outcomes (approved insurance claims), tuned through a documented, versioned process. The objective was to produce scores that meaningfully discriminate damaged from non-damaged properties without generating excessive false positives.

Calibration substantially improved the score's ability to separate confirmed-damage properties from the baseline while keeping the high-exposure tiers selective enough to stay actionable. The specific tuning constants and cohort statistics are part of HailScore's proprietary calibration and are not published; the calibration process — retrospective validation against confirmed outcomes, followed by a documented version bump — is described here and in §9.

The v5 update of May 14, 2026 added MRMS live data to the recency component. Its impact was deliberately surgical: only properties with recent qualifying MRMS events showed any score change, and properties without recent events were unaffected.

7. Validation roadmap

Calibration against a single retrospective panel is necessary but not sufficient. HailScore is committed to publishing prospective validation results on a quarterly cadence beginning in 2026 Q3.

The validation methodology will leverage our outcome-capture dataset, which records inspection results, claim filing status, claim approval, and replacement-cost data for properties scored by HailScore. Each record links a HailScore prediction at time T to a verified outcome at time T+N, where N is the time to inspection or claim disposition.

Initial validation targets include:

• Claim-approval rate stratified by HailScore tier at lookup time
• Median time from score lookup to insurance claim filing
• Comparison of HailScore predictions against contractor inspector findings
• False-positive and false-negative rates against ground-truth Storm Events records

Validation results will be published as appendices to this document. Cohort sizes, methodology, and confidence intervals will be reported in full. We invite independent replication and welcome corrections at hello@myhailscore.com.

8. Known limitations

• MESH saturation above 3.0″. Radar-derived hail size estimates lose discriminating power above approximately 3.0 inches. HailScore caps the size-score contribution accordingly; however, very large hail events (4.0″+) are scored identically to events near 3.0″. Storm Events ground truth is preferred for these cases when available.
• Geocoding precision. Address geocoding via Mapbox occasionally returns parcel-centroid rather than street-front coordinates. Within dense urban grids this is typically < 30 meters and does not affect score; in rural areas the error may exceed 200 meters.
• Property-level damage variation. Two adjacent properties may experience materially different damage outcomes from the same storm due to tree cover, building orientation, roof slope, and shingle age. HailScore quantifies exposure, not damage. The AI-assisted photo inspection in HailScore Pro is an experimental complement; it is not a substitute for licensed contractor inspection.
• Roof inputs are user-provided. Roof age and material on the free homeowner tier are self-reported. Scores are computed as if the inputs are accurate; users who under- or over-report roof age receive proportionally biased scores.
• Coverage gaps. NEXRAD coverage is excellent over CONUS but degrades in mountainous terrain and along coastal fringes. CoCoRaHS density varies by state. HailScore reports a confidence indicator that reflects coverage density at the lookup location.
• This is not a regulatory or insurance underwriting decision. HailScore is informational. It does not constitute an insurance binding decision, an actuarial determination, or a structural engineering opinion. Use in underwriting requires separate validation appropriate to the jurisdiction and carrier.

9. Governance & versioning

The scoring algorithm is versioned. The version that produced each score is recorded alongside it at the time of computation. Algorithm changes require explicit review, a validation run against a holdout panel, and a documented changelog entry. Silent algorithm changes are explicitly prohibited by internal engineering policy.

HailScore is published by Hailscore LLC, a Colorado limited liability company. Data is hosted in Neon PostgreSQL (US East 1) with at-rest encryption. Application infrastructure runs on Vercel with TLS 1.2+ in transit. Subprocessors include Neon, Vercel, Resend, Mapbox, and Anthropic. SOC 2 readiness is in progress; current security posture is documented at /security.

10. Glossary & references

Glossary

MESH

: Maximum Estimated Size of Hail. NOAA NEXRAD radar-derived hail-diameter estimate, in millimeters or inches.

MRMS

: Multi-Radar Multi-Sensor. NOAA NCEP product fusing all NEXRAD radars into a continuous CONUS grid.

NEXRAD

: Next Generation Weather Radar. 160-station network of WSR-88D Doppler radars operated by NWS, FAA, and DoD.

SWDI

: Severe Weather Data Inventory. NOAA NCEI service publishing finalized radar and storm-report data.

LSR

: Local Storm Report. SPC publication of preliminary observer reports.

CoCoRaHS

: Community Collaborative Rain, Hail and Snow Network. Volunteer precipitation observation network.

NCEP / NCEI / NWS / SPC

: NOAA centers (National Centers for Environmental Prediction / Environmental Information; National Weather Service; Storm Prediction Center).

References

• Witt, A., et al. (1998). An Enhanced Hail Detection Algorithm for the WSR-88D. Weather and Forecasting, 13(2), 286–303.
• NOAA MRMS documentation: https://www.nssl.noaa.gov/projects/mrms/
• NOAA Storm Events Database: https://www.ncdc.noaa.gov/stormevents/
• NCEI SWDI API: https://www.ncei.noaa.gov/pub/data/swdi/
• NWS API documentation: https://www.weather.gov/documentation/services-web-api
• CoCoRaHS: https://www.cocorahs.org/

Authors & acknowledgments

Alex Chicilo · Founder, Hailscore LLC. Active residential roofer in Colorado with a background in business operations. Built HailScore after three storm seasons of watching homeowners, adjusters, and contractors work from incomplete and lagging hail data. Self-taught the data engineering and platform development. Author of the scoring algorithm and methodology.

Methodology development was assisted by AI research and writing tools, including Anthropic's Claude. All scoring logic, calibration decisions, data source selection, and final methodology determinations are the sole responsibility of the author.

The HailScore methodology is sharpened by ongoing input from the insurance and roofing communities. We invite formal collaboration with carriers, adjusters, public adjusters, and academic researchers. Replication, critique, and proposed improvements are explicitly welcomed.

Citation suggestion: Chicilo, A. (2026). HailScore™ Methodology, version v6.2. Hailscore LLC. https://www.myhailscore.com/methodology

Errors, suggested clarifications, and replication results are welcomed at alex@myhailscore.com.