Compute modules

Handlers express orchestration; CEL expresses conditions and field math. When you genuinely need algorithmic work — bounded iteration, aggregation, parsing, structured rendering — a compute module runs it deterministically in a sandbox, without giving up replay or verification.

Declaring a module

Modules are declared in policy.yaml, with their contract stated up front:

policy.yaml

modules:
  structured_renderer:
    kind: python
    path: modules/renderer.py
    abi: python-json-v1          # how input/output are passed (python-json-v1 for Python)
    entry: handle                # python: always handle
    digest: sha256:<64-hex>      # of the source bytes; pins what runs
    input_schema:
      type: object
      properties:
        component: {type: string}
        files: {type: array}
    output_schema:
      type: object
    limits:
      gas: 10000000              # how much work the module may do before it is stopped
      memory_pages: 64           # memory cap, in 64 KB pages
      output_bytes: 262144

The module itself is ordinary Python with one required shape — def handle(input) taking a dict and returning a JSON-compatible dict. The harness owns all transport; author code never reads stdin, writes stdout, or touches bindings:

modules/renderer.py

def handle(input):
    files = input["files"]
    manifest = [{"name": f["name"], "size": len(f["content"])} for f in files]
    return {
        "component": input["component"],
        "file_count": len(files),
        "manifest": manifest,
    }

For compiled modules, declare kind: wasm instead:

modules:
  scorer:
    kind: wasm
    path: modules/scorer.wasm
    abi: core-json-v1
    entry: compute
    digest: sha256:<64-hex>
    input_schema: {type: object}
    output_schema: {type: object}
    limits: {gas: 5000000, memory_pages: 32, output_bytes: 65536}

Python modules run on the embedded CPython-WASI interpreter (shipped in the binary, executed through Wasmtime — no local Python needed); kind: wasm runs your compiled module through the same engine. Either way:

the declared digest pins the exact bytes into the bundle at compile time
execution is metered by the declared limits
the sandbox has no I/O — no filesystem, network, clock, or randomness

Same input, same output, forever — which is what makes module calls replayable.

Calling a module

A handler runs its rules: before deciding what to do; a compute-module rule runs there and stores its result in computed.*, which lives only for that handler:

nodes.yaml

component.submitted:
  rules:
    - id: render_file_bundle
      compute_module:
        module: structured_renderer
        input:                          # simple explicit paths only
          component: payload.component
          files: payload.files
        into: computed.rendered_bundle  # handler-local, never persisted implicitly
      advances_to: rendered
      emit:
        event: component.rendered
        fields:
          bundle: computed.rendered_bundle

The rules that keep this honest, all verified at boot:

input values are simple explicit paths rooted in payload, entity, event, or computed — no expressions smuggled in.
into must target computed.*. Module output is handler context, not state: persisting it requires an explicit data_accumulation write, with its own owner.
A module row cannot emit, advance state, run actions, fan out, or touch entity state — it computes a value, full stop.
An unconsumed into binding is a boot error: if nothing downstream reads the value, the declaration is dead and verify says so.

When to reach for one

Need	Owner
condition, simple field math	CEL expression
finite lookup table, validation predicate	policy sheet rows
bounded iteration, parsing, aggregation, deterministic rendering	compute module
durable external work (API calls, side effects)	activities / connector tools
an LLM judgment	an agent

A compute module is an escape hatch that stays inside the model: logic beyond what rows can express, still deterministic, still verified, still replayable.

Getting started

Core concepts

Build a flow

Handlers

Patterns

Operating Swarm

Declaring a module

Calling a module

When to reach for one

​Declaring a module

​Calling a module

​When to reach for one

Declaring a module

Calling a module

When to reach for one