# Data architecture

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 selects storage according to data behavior rather than forcing every record into one database.

| Data class                                    | Primary storage            |
| --------------------------------------------- | -------------------------- |
| Users and tenants                             | D1                         |
| Source catalog, storm events, and revisions   | D1                         |
| Dataset releases and parcel-partition catalog | D1                         |
| Impact assessments and action plans           | D1                         |
| CRM, campaign, and audit metadata             | D1                         |
| Raw weather objects                           | R2                         |
| Evidence, reports, photos, and exports        | R2                         |
| Hot cacheable reads                           | KV or Cache                |
| Per-event connected-client coordination       | Durable Objects            |
| Asynchronous processing                       | Queues                     |
| Durable multistage process state              | Workflows when appropriate |

## D1

D1 stores relational application state that requires relationships, transactions, indexes, lifecycle state, and tenant boundaries.

StormTrust does not store massive raw radar grids or nationwide parcel geometry in relational tables merely because D1 is available. D1 stores their catalogs, versions, relationships, quality state, and R2 object keys.

## R2

R2 stores object data. Candidate keys include:

```txt
mrms/raw/...
mrms/frames/...
mrms/events/{eventId}/raw/...
mrms/events/{eventId}/frames/...
mrms/events/{eventId}/revisions/{revisionId}/manifest.json
datasets/{datasetVersionId}/partitions/...
```

Keys support operations. Database metadata and content hashes establish immutable identity.

## Durable state

The data service implements one Durable Object room per storm event:

```txt
storm:{eventId}
```

The room broadcasts revision notices and remembers the last notice for a newly connected client. D1 and R2 remain authoritative. StormTrust does not replace ordinary relational storage solely because Durable Objects are available.

## Caching

StormTrust caches only data that it can safely recompute or invalidate. Examples include public event summaries, map tile metadata, common searches, configuration snapshots, and source catalogs.

Cache is not the canonical store for audit history.

## Data lineage

```txt
Source system
   ↓
Source asset
   ↓
Normalized evidence
   ↓
Storm event revision
   ↓
Impact assessment
   ↓
Action plan
   ↓
Campaign
   ↓
Outcome
```

## Retention

Retention is class-specific for raw and derived weather, operations, contacts, audits, campaigns, evidence, and exports. Vendor agreements and applicable law may impose shorter or longer periods.

## Backups and recovery

Recovery planning distinguishes application configuration, relational state, raw source archives, generated reports, tenant evidence, and rebuildable derived data. Documentation identifies which outputs can be reproduced from retained sources and algorithms.