Release, deploy, execute

Decisions and workflows are edited freely as artifacts, but nothing runs in an environment until it is cut into a release and deployed. This is the governance boundary: a release is an immutable, versioned snapshot, and a deploy is an explicit, audited promotion of one release to one environment.

1. Save your artifacts

Both the loan_risk/loan_pricing decisions and the loan_application workflow from the previous pages need to exist as saved artifacts in the same project first (POST /api/projects/{project}/decisions and .../workflows — see Projects & artifacts).

2. Cut a release

A release snapshots every decision and workflow artifact currently in the project:

curl -sS -X POST "$RULEFLOW_API/api/projects/lending/releases" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "notes": "initial loan-approval flow" }'

{
  "id": "rel_4a1c...", "tenant": "acme", "project": "lending", "version": 1,
  "notes": "initial loan-approval flow", "createdBy": "alice@acme.com",
  "createdAt": "2026-07-21T18:00:00Z",
  "items": [
    { "kind": "decision", "name": "loan_risk",    "model": { "...": "..." } },
    { "kind": "decision", "name": "loan_pricing", "model": { "...": "..." } },
    { "kind": "workflow", "name": "loan_application", "model": { "...": "..." } }
  ]
}

A release is immutable once created — editing artifacts afterward never changes a past release. Two releases can be compared with GET /projects/{project}/releases/{releaseId}/diff/{otherId} (semantic diff, down to the changed table rule).

3. Deploy it to an environment

curl -sS -X POST "$RULEFLOW_API/api/projects/lending/environments/dev/deploy" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "releaseId": "rel_4a1c..." }'

{ "environment": "dev", "releaseId": "rel_4a1c...", "version": 1, "updatedBy": "alice@acme.com" }

Deploying to staging or prod requires the approver (or admin) realm role — dev does not. On deploy, every workflow artifact in the release is compiled and substituted into a real AWS Step Functions state machine: placeholders like the engine ARN are resolved, decision models are inlined verbatim from the release (no runtime fetch — the machine is a self-contained snapshot of that exact release), and default timeouts are injected where the author set none. In-flight executions of a prior deploy are unaffected — Step Functions snapshots a machine’s definition at start, so only future executions pick up the new one.

Roll back with the equivalent .../environments/{env}/rollback call, gated the same way for protected environments.

4. Start an execution

curl -sS -X POST "$RULEFLOW_API/api/projects/lending/executions" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -H "Idempotency-Key: loan-app-2026-07-21-0001" \
  -d '{ "workflow": "loan_application", "env": "dev",
        "input": { "credit_score": 780, "annual_income": 80000, "debt_to_income": 0.2, "requested_amount": 10000 } }'

{ "id": "exec_88df...", "workflow": "loan_application", "env": "dev", "status": "RUNNING", "startedAt": "2026-07-21T18:05:00Z" }

Send the same Idempotency-Key again with the same request and you re-attach to the original execution instead of starting a second one — see Executions § idempotency. Starting an execution also reserves a monthly quota slot and records metered usage (workflow_execution) — see Usage & quotas.

5. Watch it, complete the human task

curl -sS "$RULEFLOW_API/api/projects/lending/executions/exec_88df..." \
  -H "Authorization: Bearer $TOKEN"

The response merges the stored execution record with a live status/history pull from Step Functions. Once the workflow reaches review, the execution pauses; list and complete the pending human task:

curl -sS "$RULEFLOW_API/api/projects/lending/executions/exec_88df.../tasks" \
  -H "Authorization: Bearer $TOKEN"

curl -sS -X POST \
  "$RULEFLOW_API/api/projects/lending/executions/exec_88df.../tasks/review/complete" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "output": { "signedOffBy": "underwriter-42" } }'

Completing resumes the paused execution; disburse (the service_task) then runs through its bound connector. See Workflows and Executions for the full lifecycle, retry/catch semantics, and failure taxonomy.