Manifests & Resource Types

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:

Field	Purpose
`manifest_version`	Manifest format version. Use `"1.0"`.
`metadata_dir`	Directory where resource YAML files live, relative to the manifest file.
`resources`	Map of resource type to resource slugs.
`projects`	Optional fine-grained project resource configuration.
`modules`	Optional 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:

Resource	Role
`activity-plan`	The reusable automated process definition
`task-template`	The human review or approval surface created by an Activity
`task-status`	Reusable status definitions for task progression
`data-definition`	The business data model and validation/event behavior
`data-form`	The Task review UI
`service-bridge`	External calls used by Activity `BRIDGE_CALL` steps and scripts
`project`	The bound workspace where resources are used
`trigger`	The 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 key	Scope	Directory
`labels`	Organization	`labels/`
`data-definitions`	Organization	`data-definitions/`
`data-forms`	Organization	`data-forms/`
`document-stores`	Organization	`document-stores/`
`data-stores`	Organization	`data-stores/`
`modules`	Organization	`modules/`
`prompt-templates`	Organization	`prompt-templates/`
`service-bridges`	Organization	`service-bridges/`
`knowledge-item-types`	Organization	`knowledge-item-types/`
`knowledge-feature-types`	Organization	`knowledge-feature-types/`
`knowledge-feature-instances`	Organization	`knowledge-feature-instances/`
`knowledge-sets`	Organization or project	`knowledge-sets/`
`intakes`	Organization	`intakes/`
`activity-plans`	Organization	`activity-plans/`
`project-templates`	Organization	`project-templates/`
`projects`	Organization	`projects/`
`task-templates`	Organization	`task-templates/`
`task-statuses`	Organization	`task-statuses/`
`knowledge-items`	Project	`projects/<project>/knowledge-items/`
`triggers`	Project	`projects/<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:

Labels
Core organization resources: data definitions, data forms, document stores, data stores, modules, prompts, Service Bridges
Knowledge type definitions
Knowledge feature instances
Intakes and Activity Plans
Project templates and projects
Task templates, task statuses, and knowledge sets
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:

Value	Result
`kodexa-resources`	Standard dedicated resource directory
`resources`	Shorter 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.

Getting Started

Core Operations

Sync & GitOps

Operational Commands

Document Commands

Overview

Manifest Format

Example: Shared Business Process

Example: Project Target

Activity-Centered Resource Shape

Resource Type Reference

Module Paths

Push Order

`metadata_dir`

Excluding Resources

​Overview

​Manifest Format

​Example: Shared Business Process

​Example: Project Target

​Activity-Centered Resource Shape

​Resource Type Reference

​Module Paths

​Push Order

​metadata_dir

​Excluding Resources

Overview

Manifest Format

Example: Shared Business Process

Example: Project Target

Activity-Centered Resource Shape

Resource Type Reference

Module Paths

Push Order

`metadata_dir`

Excluding Resources