Data architecture

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:

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:

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

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.