Kodexa
Activity plans

A recipe for working on content.

A plan is a reusable, shared definition — a graph of steps you can run on any content. When you run one against a project, you get an activity: a live, watchable instance with its own state and audit trail.

PLAN · TEMPLATE

Invoice processing

Reusable. Org-scoped. Versioned.

  • Parse PDF
  • Extract attributes
  • Enrich (script)
  • Reviewer approval
  • Post to SoR
ACTIVITY · RUNNING

INV-2026-04812

Live · started 08:14:02

  • Parse PDF
  • Extract attributes
  • Enrich (script)
  • Reviewer approval
  • Post to SoR
Inside a plan

Steps. Strung together. Seven kinds.

Every step in a plan has a kind. Pick the right one for the job — run a Kodexa module, call a model, drop into a script, hand it to an agent, reach an external service, or bring a person into the loop.

Module

Run a Kodexa module on the content. The workhorse.

kodexa/fast-pdf-model

LLM

Ask a model to generate, classify or extract against a taxonomy.

kodexa/llm-taxonomy-model

Script

Inline JavaScript. Read inputs and earlier results; produce a value.

Custom logic, run server-side

Agent

Hand the work to an autonomous agent that picks its own tools.

For ambiguous, multi-step tasks

Bridge

Call an external service through a configured endpoint.

Partner APIs · downstream systems

Task

Ask a person to do something. The plan waits if you want it to.

"Review this extraction"

Approval

A human gate, with criteria and a captured outcome.

Sign-off before publish

And more

The kind list grows with the platform.

New step kinds ship over time
SPLITPer-document fanout

Some steps run once. Others run once per document, in parallel. The plan rejoins when they're done.

step doc 1 doc 2 doc N join
SCRIPTInline JavaScript

Read the step's inputs and earlier results. Return a value the next step can use. Bring in reusable modules as sidecars.

// post-process extraction
const attrs = steps.extract.result;
const total = attrs.lineItems
  .reduce((s, li) => s + li.amount, 0);

return {
  total,
  vendor: attrs.vendor,
  status: total > 10000 ? 'review' : 'ok',
};
GUARDConditions & typed inputs

Gate a step on an expression. Validate plan inputs against a JSON schema. Templated titles render with the inputs and project context.

when vendor.country == "US" && total > 10_000
A plan in motion

Here's one running.

A real invoice plan: parse the PDF, extract attributes with an LLM, run a script to enrich, wait for an approval, then post the result. Each step's outcome lands on the content object's audit trail.

01MODULE

Parse PDF

OCR, page segmentation, table extraction.

kodexa/fast-pdf-model
02LLM

Extract

Pull structured attributes against the invoice taxonomy.

kodexa/llm-taxonomy-model
03SCRIPT

Enrich

Match vendor, normalise codes, compute totals.

Inline JS
04APPROVAL

Sign-off

A reviewer approves the attributes that carry risk.

Human gate
05MODULE

Post status

Persist the approved content object to the system of record.

kodexa/apply-status
Audit trail · live
08:14:02MODULEkodexa/fast-pdf-model · 4 pages parsed
08:14:18LLM24 attributes extracted · taxonomy v3
08:14:21SCRIPTVendor matched · total $5,432.00
08:14:39HUMANReviewer approved · GST 10%
08:14:41MODULEkodexa/apply-status · POSTED

The content object holds the work.
The activity plan is how the work gets done.

If something fails, retries pick up where the plan left off — completed steps stay completed, only the failed step and what depends on it run again.