Skip to main content

Overview

Manifests are YAML files that define which resources should be deployed as part of a sync target. Each target in your sync-config.yaml references one or more manifest files, and each manifest lists the specific resources (by slug) that belong to that deployment unit. Manifests give you fine-grained control over what gets pushed or pulled for a given environment. By splitting resources across multiple manifests, you can share common definitions across teams while keeping division-specific or project-specific resources separate.

Manifest Format

A manifest file has the following top-level fields:
  • manifest_version - The manifest format version (currently "1.0")
  • metadata_dir - Optional directory where resource YAML files are stored, relative to the manifest file location
  • resources - A map of resource type to list of resource slugs
  • projects - Optional map of project slug to project-scoped resource configuration
  • modules - Optional list of module definition file paths (relative to the sync-config.yaml directory)
Resource keys under resources: accept both canonical type names and friendly aliases (see the Resource Type Reference below).

Example: shared.yaml

A shared manifest containing resources used across the entire organization:
manifest_version: "1.0"

resources:
  # Use friendly aliases
  data-definitions:
    - invoice-taxonomy
    - contract-taxonomy

  # Or canonical names
  knowledgefeaturetype:
    - document-metadata
    - text-extraction

  # Stores for shared data
  stores:
    - document-store
    - vector-store

modules:
  # Relative to sync-config.yaml directory
  - modules/invoice-classifier/module.yml
  - modules/contract-analyzer/module.yml

Example: Division-Specific

A manifest for resources scoped to a specific division or team:
manifest_version: "1.0"

resources:
  # Division-specific resources
  data-definitions:
    - division-a-taxonomy

  knowledge-feature-instances:
    - division-a-ocr-prod
    - division-a-extraction-dev

  projects:
    - finance-automation
    - invoice-processing

modules:
  - modules/division-a-parser/module.yml

Project-Scoped Resources

Projects listed in a manifest’s resources.projects section automatically include their nested resources (task templates, assistants, knowledge items, etc.). The project directory structure under kodexa-resources/projects/<slug>/ determines what gets synced. Additionally, manifests support a top-level projects: section for fine-grained control over project-scoped resources:
manifest_version: "1.0"

resources:
  data-definitions:
    - invoice-taxonomy

  # Data forms referenced by task templates
  data-forms:
    - invoice-review
    - validation-summary

  # Projects to sync (includes nested resources)
  projects:
    - invoice-processing

# Project-scoped resource configuration
projects:
  invoice-processing:
    task-templates:
      - review
      - validation
      - extraction-workflow

Task Template Structure

Task templates define review tasks with UI forms, actions, and optional plan templates for orchestrating sub-tasks:
# kodexa-resources/projects/invoice-processing/task-templates/review.yaml
name: "Invoice Review"
description: "Review extracted invoice data"
planned: false
properties:
  subTaskOnly: true
metadata:
  forms:
    - dataFormRef: "my-org/invoice-review"
  actions:
    - label: "Approve"
      type: "APPROVE"
      properties:
        icon: "check"
        color: "#22c55e"
        automaticallyTakeNextTask: true
        onlyEnabledIfNoOpenExceptions: true
    - label: "Reject"
      type: "REJECT"
      properties:
        icon: "cancel"
        color: "#ef4444"
  properties:
    defaultToDataForm: true
    hideDefaultButtons: true
  priority: 5

Orchestration with Plan Templates

Set planned: true to create an orchestration template that coordinates execution steps and sub-tasks:
# kodexa-resources/projects/invoice-processing/task-templates/extraction-workflow.yaml
name: "Invoice Extraction"
description: "Orchestrate extraction and review"
planned: true
planTemplate:
  items:
    - type: EXECUTION
      name: "Extract Invoice Data"
      moduleRef: "my-org/invoice-extractor"
      options: {}
    - type: TASK
      name: "Review Extracted Data"
      taskTemplateRef: "review"
metadata:
  documentFamilyGroups:
    - name: "Invoices"
      documentFamilyFilter: "*.pdf"
      automaticallyAdd: true
      editable: false
  priority: 5

Resource Type Reference

The following resource types are supported in manifests, along with their aliases:
TypeAliasesScopeDirectory
label-orglabels/
exceptiontypeexception-typeorgexception-types/
datadefinitiondata-definition, taxonomyorgdata-definitions/
dataformdata-formorgdata-forms/
storedatastore, data-storeorgdata-stores/
modulecloud-module, modelorgmodules/
prompttemplateprompt-templateorgprompt-templates/
servicebridgeservice-bridgeorgservice-bridges/
knowledgetypeknowledge-type, knowledge-item-typeorgknowledge-item-types/
knowledgefeaturetypeknowledge-feature-type, feature-typeorgknowledge-feature-types/
knowledgefeatureinstanceknowledge-feature-instance, feature-instanceorgknowledge-feature-instances/
knowledgesetknowledge-setorgknowledge-sets/
projecttemplateproject-templateorgproject-templates/
project-orgprojects/
assistant-projectassistants/
knowledgeitemknowledge-itemprojectknowledge-items/
tasktemplatetask-templateprojecttask-templates/
taskstatustask-statusprojecttask-statuses/
workflow-projectworkflows/

Push Order

Resources are pushed in dependency order — labels and exception types first, then definitions/forms/stores/modules, then knowledge resources, then projects, and finally project-scoped resources. This ensures references resolve correctly during push.

The metadata_dir Field

The metadata_dir field in the manifest controls where resource YAML files are stored relative to the manifest file location:
manifest_version: "1.0"
metadata_dir: kodexa-resources   # Files stored in ./kodexa-resources/
If omitted, files are stored in the same directory as the manifest. Common patterns:
  • metadata_dir: kodexa-resources — standard convention for dedicated resource directories
  • metadata_dir: . — files stored alongside the manifest
  • metadata_dir: resources — alternative short name