Modules and workflows

Understand analysis modules, workflow revisions, runs, and artifacts.

Modules are versioned analysis steps

A module describes an analysis operation, its typed inputs and outputs, its documentation, and the immutable container image that executes it. Administrators register module revisions after validating their manifest and referenced assets.

Workflows connect modules

A workflow is a directed acyclic graph. Connections pass a compatible output from one step to an input on another step. Visible Workflow Input nodes declare what a user supplies when starting a run; Workflow Output nodes choose its public results. The editor immediately checks connections using the shared type contract, and the server compiler validates the full graph.

Ports can carry resources or inline values such as integers, numbers, booleans, and strings. Scalar/batch shape is separate from the value type. Elementwise steps run once per batch item; scalar inputs broadcast, and explicit whole-batch steps can reduce the successful items.

Saving a workflow freezes its source, module signatures, and compiled plan in an immutable revision. Editing later produces another revision instead of changing the definition used by an earlier run.

Runs preserve execution context

Starting a run freezes the workflow revision, module revisions, input authorizations, and execution plan. The configured execution backend schedules the work. Public results can be resource artifacts or typed inline values. Intermediate outputs remain in node details.

Expected per-item failures leave a run partial: successful ordinals continue downstream without being renumbered. Node details retain the full batch domain, item statuses, and provenance. Infrastructure and invalid-result failures remain fatal.