# The basics

Product design

This page describes the product model and requirements. Examples illustrate the model, not a guaranteed API or completed feature. Check the [application contracts](/stormtrust/apps/) and [dataset inventory](/stormtrust/product/platform-and-data/datasets-and-source-contracts/) for implemented scope. Use [operations guides](/stormtrust/engineering/operations/) for runnable procedures.

StormTrust presents one intelligence graph through several task-focused surfaces.

## Connected intelligence journey

[Storm Forecast → Storm Alert → Storm Radar → Storm Map → Storm Impact → Storm Report](/stormtrust/product/platform-and-data/intelligence/) connects preparation and warnings to inspectable evidence, a storm timeline, geographic priorities, and a reviewed field report. The first [Storm Report release](/stormtrust/product/platform-and-data/intelligence/report-contract/) can precede parcel matching and Forecast ingestion. Platform and data owns these capability explanations and their shared contracts. The descriptions below summarize the broader product surfaces.

[Storm History](/stormtrust/product/platform-and-data/intelligence/storm-history/) and [Storm Replay](/stormtrust/product/platform-and-data/intelligence/storm-replay/) support the whole journey: users find earlier evidence, reopen reports, and inspect observations through time. Their shared contracts also support product testing, with isolated execution and explicit fixture labels.

## Storm Map

The Storm Map is the primary visual intelligence surface. It should answer:

- Where is severe weather occurring?
- What occurred, and what is forecast?
- Which events and properties matter?
- What evidence supports each event?
- Which areas should teams work?
- What changed over time?

### Forecast layers

[Storm Forecast](/stormtrust/product/platform-and-data/intelligence/storm-forecast/) uses outlooks for preparation. Watches and warnings retain their separate [Storm Alert](/stormtrust/product/platform-and-data/intelligence/storm-alert/) semantics and publisher instructions.

### Radar intelligence layers

Radar layers include MESH, MESH accumulations, Probability of Severe Hail (POSH), radar quality, and optional verification layers.

### Observation layers

Observation layers include preliminary reports, reconciled reports, and field confirmations.

### StormTrust-derived layers

Derived layers include event and revision boundaries, severity, confidence, hail swaths, and cumulative exposure.

### Property layers

Property layers include property points, licensed parcels, commercial buildings, watched properties, impacts, and priorities.

### Operations layers

Operations layers include territories, deployment zones, assignments, completed visits, and unresolved opportunities.

## Storm events

An event result exposes stable identity, status, timing, geography, maximum estimated hail, severity, confidence, evidence labels, current revision, revision history, sources, property impacts, alert state, and report state.

## Properties

A property surface summarizes address, geometry, parcel, structure, roof attributes, permitted provider metadata, watched status, event exposures, latest impact, contact eligibility, actions, reports, photos, and customer relationships.

## Watchlists

Users can monitor individual properties, customer portfolios, installed roofs, commercial portfolios, territories, neighborhoods, ZIP codes, and counties.

## Alerts

An alert represents a policy-qualified, notification-worthy condition. It records triggering evidence, threshold, monitor, recipient, event revision, time, channel, delivery state, acknowledgment state, and deduplication key.

## Search

Search should support address, city, county, state, ZIP code, coordinates, storm event, customer, property, business, territory, report, and historical date.

## Filters

Common filters include event timing, hail size, confidence, evidence class, severity, geography, radius, territory, property use, roof attributes, watched status, assignment, contact, inspection, and opportunity status.

## Timelines

An event timeline combines source and operational activity:

```txt
Forecast issued
Warning issued
MRMS hail signal begins
Event created
Boundary revised
Ground report received
Alert delivered
Crew deployed
Property visited
Inspection completed
Campaign approved
Lead received
Outcome recorded
```

The timeline distinguishes external source timestamps from StormTrust processing timestamps.

## Reports

Report creation begins from a known storm, property, portfolio, date range, or evidence package. For the report model, refer to [Reports and evidence](/stormtrust/product/operations-and-growth/reports-and-evidence/).