Skip to main content

​
Overview

A manifest says which resources belong to a sync target. Targets live in sync-config.yaml; manifests live next to the metadata repository and list resources by slug. Manifests let you split resources by team, customer, business unit, or deployment unit. A target can reference one manifest or many.

​
Manifest Format

manifest_version: "1.0"
metadata_dir: kodexa-resources
resources:
  activity-plans:
    - invoice-intake
  data-definitions:
    - invoice-data
  data-forms:
    - invoice-review
  task-templates:
    - invoice-review
  task-statuses:
    - in-review
    - approved
  projects:
    - invoice-processing
Top-level fields:
FieldPurpose
manifest_versionManifest format version. Use "1.0".
metadata_dirDirectory where resource YAML files live, relative to the manifest file.
resourcesMap of resource type to resource slugs.
projectsOptional fine-grained project resource configuration.
modulesOptional module definition file paths relative to the sync root.

​
Example: Shared Business Process

manifest_version: "1.0"
metadata_dir: kodexa-resources

resources:
  labels:
    - invoice
    - needs-review

  data-definitions:
    - invoice-data

  data-forms:
    - invoice-review

  service-bridges:
    - finance-erp

  modules:
    - invoice-extractor

  activity-plans:
    - invoice-intake

  task-templates:
    - invoice-review

  task-statuses:
    - in-review
    - approved

  project-templates:
    - invoice-processing-template

​
Example: Project Target

manifest_version: "1.0"
metadata_dir: kodexa-resources

resources:
  projects:
    - invoice-processing

projects:
  invoice-processing:
    knowledge-items:
      - vendor-exception-rules
    triggers:
      - intake-starts-invoice-activity
Project resources are used when a specific project owns resources or bindings that should not be shared globally.

​
Activity-Centered Resource Shape

For new work, model orchestration around Activity Plans:
ResourceRole
activity-planThe reusable automated process definition
task-templateThe human review or approval surface created by an Activity
task-statusReusable status definitions for task progression
data-definitionThe business data model and validation/event behavior
data-formThe Task review UI
service-bridgeExternal calls used by Activity BRIDGE_CALL steps and scripts
projectThe bound workspace where resources are used
triggerThe project-level event that starts an Activity
Task templates should stay focused on human work. Activity Plans should own extraction, routing, scripts, Service Bridge calls, LLM steps, agent steps, and approval flow.

​
Resource Type Reference

Use current names in new manifests. Some compatibility aliases are accepted by the CLI, but the current names below are the ones docs and examples should use.
Manifest keyScopeDirectory
labelsOrganizationlabels/
data-definitionsOrganizationdata-definitions/
data-formsOrganizationdata-forms/
document-storesOrganizationdocument-stores/
data-storesOrganizationdata-stores/
modulesOrganizationmodules/
prompt-templatesOrganizationprompt-templates/
service-bridgesOrganizationservice-bridges/
knowledge-item-typesOrganizationknowledge-item-types/
knowledge-feature-typesOrganizationknowledge-feature-types/
knowledge-feature-instancesOrganizationknowledge-feature-instances/
knowledge-setsOrganization or projectknowledge-sets/
intakesOrganizationintakes/
activity-plansOrganizationactivity-plans/
project-templatesOrganizationproject-templates/
projectsOrganizationprojects/
task-templatesOrganizationtask-templates/
task-statusesOrganizationtask-statuses/
knowledge-itemsProjectprojects/<project>/knowledge-items/
triggersProjectprojects/<project>/triggers/

​
Module Paths

Modules can be listed in resources.modules or in the top-level modules path list. Use path entries when a module folder includes implementation files: 
modules:
  - modules/invoice-extractor/module.yml
Inside the module YAML, use current module metadata names: 
type: module
slug: invoice-extractor
metadata:
  moduleRuntimeParameters:
    module: invoice_extractor

​
Push Order

kdx sync pushes in dependency order so references resolve:
  1. Labels
  2. Core organization resources: data definitions, data forms, document stores, data stores, modules, prompts, Service Bridges
  3. Knowledge type definitions
  4. Knowledge feature instances
  5. Intakes and Activity Plans
  6. Project templates and projects
  7. Task templates, task statuses, and knowledge sets
  8. Project resources such as knowledge items and triggers

​
metadata_dir

metadata_dir controls where resource files are stored: 
manifest_version: "1.0"
metadata_dir: kodexa-resources
Common values:
ValueResult
kodexa-resourcesStandard dedicated resource directory
resourcesShorter dedicated resource directory
.Files live next to the manifest

​
Excluding Resources

Comment out resources that exist on the server but should not be managed by this metadata repository: 
resources:
  data-definitions:
    - invoice-data
    # - experimental-claims-data
Repeat kdx sync pull --discover later to merge newly created server resources. Commented entries are treated as intentional exclusions and are not re-added.