Knowledge Packs

A Knowledge Pack is what a customer actually has: not a model, not a database, a pack. It’s a continuously current body of domain and proprietary knowledge, combined by the platform into the single unit every ask, teach, and task in the CLI targets.

The two halves

Every Knowledge Pack combines:

• Domain knowledge, the leading-edge half. Built once per vertical, directed by named experts, and shared across every customer in that space.
• Proprietary knowledge, the private half. Your own documents, databases, connections, and definitions, layered on top and never shared across customers.

The platform combines the two layers and keeps the result current, but nothing about how you interact with a pack depends on which layer answered. An ask can draw on both in the same response, each claim attributed to its actual source rather than blended into one undifferentiated answer. See Sources & provenance for how that attribution works.

Domain knowledge isn’t itself something you ask, teach, or task; it only becomes useful once your proprietary knowledge is combined with it, and that combination is the pack itself. There’s no separate object to find or manage: edisyl pack list shows you packs, not domain knowledge on its own, and there’s no CLI surface where the two halves are addressed independently.

What makes domain knowledge trustworthy

• Built by agents, directed by experts. Agents assemble and continuously refresh it from licensed feeds, industry sources, and public material. Named subject-matter experts direct what goes in and review what agents propose, so accuracy has an accountable owner instead of resting on a model’s best guess.
• Shared, not siloed. One vertical’s domain knowledge serves every customer in it. A cybersecurity pack’s domain knowledge behaves the same way whether it’s answering for a five-person startup or a global bank, because the domain itself doesn’t change per customer. Only the proprietary knowledge layered on top does.
• Always current. It stays current the same way it was built: agents ingest updates and experts review what changed. Its freshness is reported the same way any source’s freshness is, see Sources & provenance.

	Domain knowledge	Proprietary knowledge
Built by	edisyl, directed by named experts	You, through teach and connected sources
Shared across	Every customer in that vertical	Nobody. Private to your pack alone
Changes when	The domain itself changes	Your organization’s own knowledge changes
Example	A cybersecurity pack’s threat and control definitions	Your own incident history and control exceptions

Delivered where you already work

A Knowledge Pack isn’t a destination you open. It’s served over MCP and the CLI directly into whatever AI interface or agent your team already has open, so answering a question doesn’t mean leaving the tool you’re already in to go check a separate system.

One domain, many customers; one customer, many domains

Because domain knowledge isn’t customer-specific, the same body of it underlies every customer’s Knowledge Pack in that vertical, each layered with that customer’s own proprietary knowledge separately. And because proprietary knowledge isn’t domain-specific, one customer can draw on more than one vertical’s domain knowledge, each paired with proprietary knowledge where it applies.

Why split the two layers at all

A single general model answering only from what it already knows, and a system that only ever reads your own data, both fall short of the same thing: an expert-grade decision. Splitting domain and proprietary knowledge, then combining them deliberately, buys three things instead:

• Accuracy. Answers are grounded in expert-directed domain knowledge, not a plausible average across the open web.
• Efficiency. Curated, combined context costs a fraction of what brute-force retrieval, or a much bigger general model, costs as usage grows.
• Portability. Your proprietary knowledge stays yours. It moves with you across models, tools, and vendors, because it never depended on any one of them.

Finding what’s in your pack

Start from edisyl pack list to see the packs you have access to, then use edisyl pack to look at a specific one, including what it’s built on.

Next: Ask, Teach, Task, for how you actually interact with a pack once you have one.