Knowledge Bases

A Package can include Knowledge Bases, but never documents. You define how documents are indexed and searched; each installer supplies their own. That's what lets the same Package serve a hundred different companies.

1. Define the Knowledge Base

name: Escalation Policy
embedding:
  slot: embedding
  modelPreference: null
searchMode: hybrid
hybridAlpha: 0.5
indexConfig: null
dataMode: schema-only

2. Declare it and its Slots

compatibility:
  requiredCapabilities: [knowledge]

knowledgeBases:
  - name: escalation-policy
    ref: ./knowledge/escalation-policy.yaml

slots:
  - id: embedding
    type: llm
    required: true
    description: >-
      The model that indexes and searches your escalation policy.
      Changing it after install invalidates the index.
    boundTo: [knowledgeBases.escalation-policy]
  - id: escalation-policy-documents
    type: knowledge-source
    required: true
    description: >-
      Your own escalation policy: who is on call, what counts as urgent,
      what must never wait until morning.
    boundTo: [knowledgeBases.escalation-policy]

Write Slot descriptions for the person installing. They're the only guidance that person gets about which documents to bring.

3. Give an Agent access

config:
  knowledge:
    agentic_rag: true
    metadata_filter: false
    knowledge_bases: [knowledgeBases.escalation-policy]
  instructions:
    content: |
      Decide who to route the caller to using only the escalation policy.
      If the policy doesn't cover the situation, route to the on-call person.

4. Validate and build

npx @elizon/cli@<cliVersion> validate
npx @elizon/cli@<cliVersion> build

What the installer sees

In the wizard's Knowledge Base step, for each Knowledge Base, the installer:

1. chooses the embedding model from their own LLM Configurations,
2. chooses what to do about content: upload files, connect a source (for example a web page, crawled together with the pages under it), or skip for now.

Skipping is allowed, but it's shown as a warning: an empty Knowledge Base answers nothing, which looks exactly like a broken Package. The Package installs as installed-incomplete (shown as Needs finishing in Studio) and the reminder stays on its page until the Knowledge Base has content.

Filling it from a script

An installer who skipped the content step, or who keeps the content in another system, can fill the installed Knowledge Base through the public API instead of Studio: find it with GET /knowledge-bases, then upload documents or submit URLs with an API key for the project the Package was installed into. Nothing in the Package changes for this: validate and build treat the Knowledge Base exactly as above.

Testing with documents

Your evaluation suite runs against the installer's documents, not yours. Write cases that hold for any reasonable policy (e.g. "an active failure reaches a person"), not ones that depend on your own document's wording.