Docs / Source Data

Every maintained pack needs a
source data sheet.

A pack is easier to trust when people can see who made it, what it covers, how it was prepared, when it was updated, and what caveats matter.

Why this matters

Source packs should not feel anonymous. Contributors deserve recognition, users need context, and maintainers need a consistent way to explain what is inside each pack beyond the raw file tree.

What the sheet is for

A source data sheet is the public summary for a pack. It tells users what the pack is, where it came from, how it was prepared, and what limits or caveats they should know before querying it.

  • Pack name and short summary
  • Source owner or maintainer
  • Original publisher or upstream institution
  • Methodology in plain language
  • Last updated date
  • Timeline covered
  • Geographic coverage
  • Main metrics or fields
  • Update cadence
  • Known caveats
  • Contributor credit and pack history
Field What it answers Why users care
Maintainer Who built or currently maintains the pack? Creates recognition, accountability, and contributor ownership.
Methodology How was the source cleaned, merged, transformed, or normalized? Lets users understand whether a pack is direct-source, merged, modeled, or heavily processed.
Last updated When was this pack last refreshed? Freshness is part of trust, especially for hazards and live-ish data.
Timeline covered What years or periods are represented? Prevents confusion between strong historical coverage and current/live coverage.
Coverage Which geographies, hazards, or populations are included? Users need to know whether the pack is global, regional, or highly specific.
Main stats What are the key fields, metrics, or summary values? Helps people quickly decide if a pack is relevant before opening the app.

Example framing

A strong pack page reads like a compact dossier: what the pack is, where it came from, what it measures, how current it is, and who made it usable.