Starter
Core Packs
Small, stable packs that should feel dependable in the public app. These are the default surfaces: strong disaster families, core demographics, and broad country-level context.
Docs / Packs
Data packs are the release unit,
not the repo.
DaedalMap treats packs as modular, versioned delivery units so users do not need the full build tree just to use a specific source family or workflow. Packs are how source coverage, quality gates, and access paths become legible to real users.
General Use
Standard Packs
Broader maintained libraries that are good enough for public use but still evolving in scope, freshness, or regional depth. This is where most serious analysis will live.
Selective
Experimental And Private
Some packs are still maturing, region-specific, or partner-restricted. DaedalMap treats those as opt-in or restricted instead of pretending everything is equally ready.
What a pack is
A pack is a versioned unit that bundles metadata, manifest information, and one or more data files in a structure the runtime can install or query. Packs should be independently discoverable and promotable.
Source data sheets
Packs also need a readable public-facing source sheet: who made the source, what methodology they used, when it was updated, what years it covers, and what the main stats or caveats are. That information is not just internal QA detail. It is part of how contributors and users understand what is actually inside a pack.
Why packs matter
Packs separate app delivery from data delivery. That makes it possible to keep the engine stable while releasing, validating, or restricting different data libraries independently. It also means the site can answer a simple user question clearly: what is actually available right now?
Release tiers
Packs can be published at different tiers such as core, standard, experimental, or private. The point is not to make every source appear equal. The point is to state clearly what is broadly ready, what is still moving, and what is restricted.
Registry and runtime
A runtime should distinguish between packs that merely exist, packs installed on the current host, packs the current user is entitled to access, and packs that are actually visible in the active catalog.
What users should expect
The public site should eventually make three things obvious: what data families exist, which ones are currently strong, and which access path is appropriate. Some people just want the hosted app. Others want maintained libraries, local installs, or a clearer view of what is still experimental.
Practical split
- Public app users should see stable default packs and clear coverage.
- Logged-in members should get more persistent workspace behavior and clearer pack visibility over time.
- Analyst and local users should be able to choose, sync, and install the packs they actually need.
Coverage map
Packs are easier to understand when the source families are visible. The public source map is where DaedalMap shows what is currently in the system, what those sources cover, and which areas are strongest today.
Making packs
DaedalMap should not only publish maintained packs. It should also make it possible for collaborators and outside contributors to build source packs of their own, document them clearly, and eventually submit them through the same quality path.