Skip to main content
Python modules (moduleType: model) are executable code that processes documents on the Kodexa platform. They are the core building block for inference, transformation, and event-driven workflows.

Project Structure

A Python module has a simple structure:

Module Definition (module.yml)

Every module needs a module.yml that describes it to the platform:
Key fields:
  • slug: Unique identifier within your organization
  • orgSlug: Your Kodexa organization slug
  • moduleRuntimeRef: The runtime environment that executes your module (see Module Runtimes)
  • contents: Glob patterns for files to include in the deployment

Writing an Inference Module

The most common module type processes documents. The entry point is an infer function in module/module.py:

Magic Parameter Injection

The Kodexa bridge automatically injects parameters based on your function signature. Declare only what you need:
Available parameters: For document family, content object, and raw event metadata, use pipeline_context:
  • pipeline_context.document_family
  • pipeline_context.content_object
  • pipeline_context.document_store
  • pipeline_context.context

Inference Options

You can define options that are displayed in the UI and passed to your function:
Options are injected as parameters by name:

Status Reporting

Use status_reporter for live UI updates during processing:
Status types: thinking, searching, planning, reviewing, processing, analyzing, writing, waiting.

Writing an Event Handler Module

Event handler modules react to platform events (e.g., document uploads or status changes). Add the eventAware flag and implement handle_event:
The bridge does not inject a standalone event parameter. Read raw event fields from pipeline_context.context. See Event Handling with Modules for more details.

Using Module Sidecars

Sidecars let you share code between modules. Reference other modules as sidecars in your module.yml:
You can then import from the sidecar module in your code:
See Module Sidecars for more details.

Targeting a Custom Package

By convention, the runtime imports the module/ package and calls infer. If your ZIP contains multiple Python packages, set metadata.moduleRuntimeParameters.module so the bridge imports the correct one:

Example: Document Classifier

Here’s a complete example of an inference module that classifies documents:

module.yml

module/module.py

Deploying

Deploy with the KDX CLI:
This will:
  1. Create or update the module metadata in the platform
  2. Package all files matching metadata.contents patterns
  3. Upload the implementation

Debugging a Deployment

To keep the deployment ZIP for inspection, add keepZip: true to your metadata:
To download a deployed module’s metadata:

Using Your Module

Once deployed, you can add your module to an Assistant in your project. The module will appear in the list of available modules for your organization. See Working with Modules for more details.

Troubleshooting

Module import errors

  • Ensure your Python environment has the correct dependencies installed
  • Verify import statements use the correct package name
  • Check that your metadata.contents patterns match your project structure

Deployment failures

  • Verify KDX CLI is configured: kdx config --list
  • Check the orgSlug in module.yml matches your organization
  • Ensure module.yml is valid YAML
  • Run kdx apply from the directory containing module.yml

Module not working as expected

  • Add logging to your function to trace execution
  • Check that you’re returning the document from your infer function
  • Verify the module is receiving the expected document format
  • Review execution logs in the platform UI