Versioning & Publishing

Pipelines uses a versioning system to manage changes to active pipelines safely. Every time you publish changes, a new immutable version snapshot is created, and the system detects what changed to handle in-flight tasks appropriately.

Version lifecycle

1. Edit — make changes in the Pipeline Builder. The pipeline remains on its current published version while you edit.
2. Save / Publish — for draft pipelines, click Publish & Activate (or Publish to Paused). For active/paused pipelines, click Save to create a new version.
3. Activate — the new version becomes the live version. Depending on detected changes and existing tasks, this may happen immediately or require admin review.

Change tiers

When you save or publish, every modification is classified into one of three tiers:

Cosmetic changes

Changes that do not affect task execution or data.

• Node or field label/title text changes
• Helper text changes
• Field reordering within a node
• Pipeline name changes
• Grid layout adjustments

Impact: Applied immediately. No task migration needed.

Behavioral changes

Changes that affect how tasks are processed but do not alter the pipeline graph or data schema.

• Field required/optional toggle changes
• Validation constraint changes (tightening or loosening)
• Adding new dropdown options
• Compatible field type changes (e.g., short text to long text)
• Field configuration changes (placeholder, dynamic settings)
• Review node rule changes (reassignment mode, pass assignment mode)
• Evaluation target changes
• Conditional visibility rule changes
• Claim limit or work schedule changes
• Permission/role changes
• Upstream field visibility changes

Impact: Auto-applied with smart rules for both in-flight and new tasks.

Structural changes

Changes that alter the pipeline graph topology, data schema, or LLM generation behavior.

• Adding or removing nodes
• Adding or removing form fields
• Incompatible field type changes
• Removing dropdown options
• Reordering nodes in the graph
• LLM prompt changes
• LLM model changes
• LLM configuration changes (temperature, context sources, tool bindings)
• Adding new LLM-generated fields

Impact: Requires admin review when the pipeline has existing tasks.

Publishing flow

Save and publish are decoupled actions. You can save at any time without publishing, and validation errors do not block saving — they only block publishing and activation.

Draft pipelines

1. Click Save to save your work without publishing. You can return to it later.
2. Click Publish & Activate to validate, create version 1, and start accepting tasks immediately. Validation errors must be resolved before publishing.
3. Or use the overflow menu Publish to Paused to create the version without activating.

Active / Paused pipelines

1. Click Save. The system saves your changes and compares them against the last published version, classifying every change by tier.
2. If the pipeline has no tasks, the new version activates immediately.
3. If the pipeline has existing tasks, the version enters Pending Activation and the Version Management Modal opens for admin review. If there are validation errors, they must be resolved before the pending version can be activated.

Admin decision UI

For pipelines with existing tasks, the decision dialog shows the detected changes grouped by tier. For structural changes, the admin chooses how to handle each affected task category:

For individual structural changes (e.g., a removed node or field), per-change decision cards appear with more granular options — such as showing new fields immediately, marking removed fields as N/A, or moving tasks backward.

Pending activation

When a version requires admin decisions, it enters Pending Activation:

• The previous active version stays live until the admin confirms.
• A pending version indicator appears in the builder header.
• The admin can activate the pending version (after making decisions) or discard it using the trash icon in the Version Management Modal footer. Discarding deletes the pending version and reverts the builder to the current active version's state.
• Once activated, the previous version is superseded and set to Paused status internally.

Version history

The current version number is shown in the builder header (e.g., v9). Version information is tracked internally for change detection and migration. There is currently no dedicated version browsing interface for viewing past version snapshots.