Product principles

StormTrust is a severe-weather intelligence and operations platform built initially for roofing and restoration organizations.

Its purpose is not merely to answer where hail occurred. It must explain what StormTrust knows, how it knows it, which properties matter, which actions are allowed, and what happened after those actions.

StormTrust combines several capabilities:

• weather and storm-event intelligence
• geospatial and property analysis
• monitoring and field operations
• customer and opportunity management
• marketing automation and attribution
• evidence, reporting, APIs, and integrations

StormTrust does not hide uncertainty. Its advantage comes partly from making uncertainty more explicit than competing systems.

StormTrust turns severe-weather evidence into decisions:

Forecast
   ↓
Radar-derived evidence
   ↓
Ground observations
   ↓
Evidence fusion
   ↓
Derived storm event
   ↓
Property exposure
   ↓
Impact assessment
   ↓
Prioritization
   ↓
Action plan
   ↓
Field or campaign activity
   ↓
Outcome
   ↓
Attribution

Every derived object should retain enough provenance to answer:

• Which sources contributed?
• When did StormTrust acquire them?
• Which source and algorithm versions applied?
• Which event revision contained the result?
• Was the result predicted, modeled, observed, reviewed, or verified?
• What changed, and why?
• Which downstream actions depended on it?

StormTrust is not merely a radar viewer, hail polygon provider, property database, canvassing CRM, lead generator, report generator, marketing tool, or AI wrapper. It does not replace every contractor CRM.

A Maximum Estimated Size of Hail (MESH) value is not a roof inspection. A storm report is not automatically verified at every nearby property. A parcel intersection is not proof of damage. A high opportunity score is not authorization to contact someone. An AI recommendation is not an authoritative weather determination.

StormTrust preserves these distinctions.

Automation acts only on sufficiently understood data:

Evidence
  → classification
  → confidence
  → eligibility
  → action

StormTrust avoids treating every signal as an automatic action.

Derived intelligence without provenance is incomplete intelligence. Important records retain source, source asset, source and acquisition timestamps, normalized representation, algorithm release, event revision, confidence, evidence classification, review state, and downstream dependencies.

Storms evolve. StormTrust does not continuously mutate an opaque polygon and pretend the current geometry was always known.

StormEvent
    ├── Revision 1
    ├── Revision 2
    ├── Revision 3
    └── Revision N

The stable event identifies the phenomenon. Revisions record how StormTrust understanding changes.

StormTrust may determine that a property intersects an estimated hail swath, experienced estimated hail above a threshold, was near a ground observation, or sits within a high-confidence impact region.

Those facts support an impact assessment. They do not independently establish physical damage.

High-consequence actions retain explicit approval boundaries. Examples include certifying evidence, activating paid advertising, exporting protected contact data, sending marketing communications, overriding storm boundaries, and marking physical damage as confirmed.

StormTrust avoids disconnected representations of the same event. The same StormEvent underpins maps, alerts, property impacts, action plans, field assignments, reports, public pages, campaign eligibility, attribution, and API responses.

A system that recommends where to go but cannot measure the result is incomplete. StormTrust should eventually connect candidate structures to priorities, assignments, contacts, inspections, opportunities, signed jobs, and attributable revenue.

Owners need to understand which markets deserve attention, how storms become opportunities, whether campaigns and crews produce returns, and whether the organization operates compliantly.

Operations managers need event timing, location, severity, deployment recommendations, capacity, and assignment progress.

Sales managers need prioritized properties, territory ownership, contact history, and follow-up status.

Field representatives need destinations, property context, supporting evidence, capture requirements, and expected actions.

Reviewers need source evidence, derivation methods, revision history, defensibility, and certification controls.

Marketing operators need eligible audiences, suppression reasons, draft campaigns, approval requirements, and performance.

Administrators need user, role, tenant, integration, source, security, billing, entitlement, and audit controls.

Developers need API resources, webhooks, schemas, authentication, rate limits, error semantics, event contracts, and data-use restrictions.

An upstream data producer. Examples include National Oceanic and Atmospheric Administration (NOAA) MRMS, National Weather Service (NWS) alerts, Storm Prediction Center (SPC) products, licensed property providers, and user field observations.

An immutable or externally identified object acquired from a source. Examples include one MRMS GRIB2 file, one NWS Common Alerting Protocol alert, one NEXRAD Level II object, or one provider parcel response.

A normalized fact or signal that may support a conclusion.

A stable StormTrust identity representing a coherent severe-weather phenomenon.

A versioned representation of what StormTrust believed about an event at a particular time.

A geographic representation of hail-related estimates over time.

A derived relationship between an event and a property.

A versioned recommendation for operational response.

A recorded result of an action.

The relationship between upstream intelligence, actions, costs, and measurable results.