What a pack contains
A pack bundles everything needed to make one source searchable and portable. That includes the source text and metadata, vector embeddings for semantic search, an HTML backup of the original pages for offline browsing, and optionally a ZIM archive, PDF collection, or transcript artifacts.
The metadata layer records what the source is, what license it carries, when it was last updated, and which topics it covers. That makes it possible to browse, compare, and selectively install packs without loading all of them.
Why packs instead of a single database
A monolithic knowledge base is hard to update, hard to audit, and impossible to carry offline. Packs decouple the runtime from the knowledge layer. The app stays stable while sources are added, refreshed, or swapped independently.
This also makes the knowledge layer legible. You can see exactly what is in the collection, choose which packs to include in a search, and trust that nothing outside your selection is influencing an answer.
How packs move between hosted and local
The hosted app runs a curated set of packs maintained by the project. A local install can use the same packs, add its own, or run entirely on a custom collection. The pack format is the same in both cases.
Packs with offline backups can be carried to air-gapped environments or loaded onto a Raspberry Pi. The search experience and citation behavior stay consistent regardless of where the pack is running.
Where this is heading
The current collection is preparedness-focused. As the pack model matures, the aim is a browsable library where each pack has a profile page covering source quality, refresh history, license, and hosted versus offline compatibility. Packs will be installable by anyone running a local deployment without rebuilding them from scratch.