The manifest (elizon.yaml)

elizon.yaml sits at the root of a Package project and describes the whole Package. This page explains each section. The authoritative, always-current definition for your CLI version is:

npx @elizon/cli schema

Unknown fields are rejected, not ignored, so a typo or a field from a newer CLI fails validate (MANIFEST_UNKNOWN_FIELD).

A complete example

apiVersion: elizon.ai/v1
kind: Package

metadata:
  name: support-bot
  namespace: acme
  version: 1.0.0
  displayName: Support Bot
  description: Answers product questions from your own documentation.
  license: UNLICENSED

compatibility:
  minPlatformVersion: 0.21.0
  requiredAdapter: agno
  requiredCapabilities: [knowledge]

compliance:
  dataCategories: [personal_data]
  retention:
    conversations: 30d
    documents: retained_until_deleted
  autonomy: advisory
  providers: []

entryPoint: agents.support-assistant

agents:
  - name: support-assistant
    ref: ./agents/support-assistant.yaml
knowledgeBases:
  - name: product-docs
    ref: ./knowledge/product-docs.yaml

slots:
  - id: reasoning
    type: llm
    required: true
    description: The model the assistant answers with.
  - id: embedding
    type: llm
    required: true
    description: The model that indexes your documents.
    boundTo: [knowledgeBases.product-docs]
  - id: product-documents
    type: knowledge-source
    required: true
    description: Your product documentation.
    boundTo: [knowledgeBases.product-docs]

triggers:
  - id: run-manually
    type: manual

apiVersion and kind

Always apiVersion: elizon.ai/v1 and kind: Package.

metadata

The artifact is named <namespace>-<name>-<version>.pkg.

compatibility

Declarations must agree (MANIFEST_CAPABILITY_DISAGREEMENT): every capability a trigger or a policy_set floor rule needs must be in requiredCapabilities. Triggers: schedule needs schedule, knowledge-document needs knowledge, inbound-call needs voice and sip. Floor rules: policy.redaction for a redact action or a data.redaction block, policy.routing for a routing.data_rules rule, policy.ner for an ner.* detector or a data.name_recognition rule.

A manifest that uses policy_set, the confidential_business data category or a policy.* capability must set minPlatformVersion: 0.26.0 or newer: older platforms and CLIs reject those values.

Likewise, a Package whose Agent definitions use skills must set minPlatformVersion: 0.25.0 or newer: platforms older than 0.25.0 reject the field. npx @elizon/cli validate and build refuse the combination with MANIFEST_INVALID_FIELD at compatibility.minPlatformVersion.

compliance

The Package's own statement of what it does with data, shown to the installer before anything is installed and pinned in the audit record at install. Make it honest, not merely valid.

When an update changes this block, the operator is shown the change separately and must acknowledge it. See Update.

entryPoint

Exactly one <collection>.<name> reference to a declared object, e.g. workflows.triage-flow. See Package concepts.

Component lists

agents: [{ name, ref }]
teams: [{ name, ref }]
workflows: [{ name, ref }]
tools: [{ name, ref }]
skills: [{ name, ref }]
knowledgeBases: [{ name, ref }]
dataTables: [{ name, ref }]
voice: { ref }
sip: { ref }

• name is the manifest-local name other objects use (agents.<name>). Lowercase and hyphenated, and unique within its list.
• ref is a relative path inside the project to the object's definition file. No absolute paths and no ... For a Skill it points at the Skill's folder (trailing /).

slots

What the installer supplies: models, credentials, documents, speech providers, a phone trunk. See Slots.

triggers

What starts the entry point: schedule, webhook, inbound-call, api, manual, email, knowledge-document, app. See Triggers.

policy_set

Optional. The policy your Package's agents need (see Package floors and Policies), in two parts:

• floor: rules the Package fixes, written in the policy rules schema (capability, routing, data, code, egress). Nothing an installer or administrator applies to the Package's objects can go below them while the Package is installed. A floor rule that needs an Enterprise capability must be listed in compatibility.requiredCapabilities, and a custom.* or dictionary.* detector (an Organization's own detection library) is refused in a floor.
• parameters: named knobs with bounds you declare. Today every install uses each parameter's default; letting the installer choose a value within the bounds comes in a later release. Each has a name (snake_case), a type and a default:

A default must be inside its bounds and inside the floor, and no two parameters may set the same rule.

policy_set:
  floor:
    egress: { allowed_hosts: [api.bank.example] }
    code: { enabled: false }
  parameters:
    - { name: region, type: region, default: EU, bounds: { allowed: [EU, Local] } }
    - { name: approve_sends, type: approval_toggle, default: true, group: send }

Install creates a Package policy from the floor and the parameters' defaults and attaches it to every Agent, Team and Workflow the install creates. Uninstall removes it; an update replaces it with the new version's.

signature

Optional, and usually omitted. sign records the signature in the archive, not in the manifest. You may pin signature.signerKeyId (ed25519:<32 hex>) so that only that key's signature is accepted. signature.attestations must be empty or absent; counter-signing by a registry is reserved for a future release.

evaluation

Optional. A suite of test cases the installing Organization runs before activating the Package. See Evaluation.

evaluation:
  suite: ./eval/triage-suite.yaml
  authorBaseline: { pass_rate: 1.0 }
  gate: advisory # or must-pass