Domain packs

The core engine is domain-agnostic — it knows nothing about cases, encounters, or citations. All domain vocabulary is contributed by a pack: a signed, declarative extension that the runtime loads and confines. See the Packs page for the shipped packs.

The pack model

1. Manifest — a pack declares its object types, relationships, embedding namespaces, and the type-tags it is authorized to touch, plus the core version it needs.
2. Sign & seal — the manifest is cryptographically signed into a sealed package. The signing key is held in a secure vault and never ships with the pack, so a pack is provably exactly what its author published.
3. Verify & load — at load time the runtime verifies the signature and a core-version compatibility bound before allocating anything. An unsigned, tampered, or too-new pack fails closed and is never registered.
4. Sandbox — every pack touches data only through a sandbox that enforces its declared scope. Reads and vector searches are limited to authorized tags and owned namespaces; out-of-scope access is denied and audited. A pack can never bypass encryption, permissions, or audit.

Shipped vs. roadmap

The three first-party packs (Legal, Medical, Research) ship compiled into the engine and are invoked as CLI subcommands (athenadb legal | medical | research). The signed seal → load → sandbox mechanism that makes packs true add-ons is built and tested; dynamic pack install and pack purchase are on the roadmap.

Building a pack

The manifest is the contract. Declare your object types, relationships, and namespaces; implement deterministic extractors, rules, workflows, and context templates against the pack interfaces; sign the manifest. The runtime loads it and confines it in a sandbox. A packaged public SDK and third-party trust model are planned.