Stages

A stage represents an execution environment. CAIP Workflows supports four stages:

Stage	Purpose
test	Development / testing.
int	Integration.
e2e	End-to-end.
prod	Production.

A stage assignment promotes a specific workflow version into a stage and, optionally, binds a configuration to it. This decouples "which version is current for an environment" from the version identifiers themselves — callers can trigger a run per stage without tracking version numbers. A workflow has at most one assignment per stage.

Assigning a Version to a Stage

// PUT .../workflows/ml-training-pipeline/stages/prod
{
  "versionId": "1.0.0",
  "configurationId": "prod-config"
}

• versionId (required) — the version to promote. The API responds 404 if it does not exist.
• configurationId (optional) — the configuration whose values resolve ${config.KEY} references for runs on this stage. The API responds 404 if the referenced configuration does not exist.

The stage that a run executes in also determines its Kubernetes namespace, service account, and shared-storage volume.

A Typical Multi-Environment Setup

Bind the same version to different stages with different configurations:

stage int  → version 1.0.0 + dev-config   (BUCKET=dev-bucket)
stage prod → version 1.0.0 + prod-config   (BUCKET=prod-bucket)

Now a run on int writes to dev-bucket and a run on prod writes to prod-bucket — from one version definition, with no duplication.

Removing an Assignment

Deleting a stage assignment removes the binding for that stage. Deleting the underlying version also removes its stage assignments automatically.

Next Steps

• Define the values each stage uses on the Configurations page.
• Trigger and monitor executions on the Runs page.
• See the full endpoint contract in the CAIP Workflows API Reference.