The workflow lifecycle

A workflow is a versioned thing: one stable identity that owns a series of numbered versions, each moving through the same three states. A published version never changes — evolution always means a new version. Everything else on this page follows from that rule.

Three states, two transitions

State	What it means
`Draft`	The working copy. The only state that accepts edits — change the graph as often as you like.
`Published`	Frozen and runnable. Can never be edited again; its only remaining move is to `Archived`.
`Archived`	Retired. No longer runnable, kept for provenance.

The only legal transitions are Draft → Published and Published → Archived. There is no way back: you can't unpublish, and you can't unarchive.

Delete exists only for drafts, and it is permanent. A published version can never be deleted — if you want it out of the way, you archive it.

Versions

Version numbers count up — 1, 2, 3 — and are never reused or rewound. To change a published workflow, you start a new draft; publishing it creates the next version.

Several published versions of the same workflow can coexist, and each one stays runnable. Running one is always an explicit version choice: nothing silently substitutes "the latest" for the version you asked for. (Triggers are the one place a latest-version policy exists, and even there it is a choice you state explicitly — see below.)

Validation happens at publish

There is no separate Validate step in the editor: clicking Publish runs the checks, and if anything is wrong it refuses and reports every problem at once — wiring mistakes, missing required pins, writes with no gate in front of them — in a single list, so you fix in one pass instead of resubmitting to discover the next complaint. The list is exhaustive: once it is empty, the publish goes through. The problems list lives in the editor. Agents can run the same checks as a true dry run — without attempting a publish, freezing nothing — via the workflow_validate_draft tool.

Publish freezes the graph

Publish validates one last time, then freezes the draft. From that moment the graph is immutable and sealed with a checksum; every run records exactly which frozen graph it executed, so what you reviewed is provably what ran.

One thing lives outside the freeze: the display name. Renaming with Rename touches all versions of the workflow and never alters a graph — a rename is always safe, even on published versions.

For the full mechanics of the freeze, see the architecture chapter on workflows.

Ways a workflow starts

A workflow executes nothing by itself; every start becomes a mission. Three doors:

Attach at mission creation. You create a mission and pick a workflow as its plan. Runs then happen on that mission — see Runs, acceptance & changements.
Invoke. You run the workflow directly with Invoke; ARDS creates a new mission for it. Same loop from there.
Triggers. A schedule, a webhook, or a platform event starts the workflow automatically. You configure them from the workflow list: Manage triggers opens the dialog where you pick Schedule, Webhook or Event and name the mandatory provider and model. Each trigger binds either a pinned version or the latest published one — you state which when you create the trigger — and names its model and provider up front (there is no silent fallback). A trigger never bypasses a gate: an automatic start pauses at every approval a manual start would.

Clone

Cloning always lands a new draft you own — never a published version.

From a template. System templates clone into an editable draft; edit and publish it like any other.
From a mission. "Save this run as a workflow." If the mission was itself born from a workflow, the source graph is re-drafted verbatim. If it was an organic, planner-decomposed mission, ARDS reconstructs a graph from what actually ran — and attaches a notes list of every repair it made along the way, so you can judge the reconstruction before trusting it.

Changing a sub-workflow reference

A workflow can embed another workflow by reference (see Anatomy of a workflow). You can rebind that reference — point it at a different workflow, or a different version — but rebinding invalidates any gate ratification given against the old target. Nothing carries over silently: the rebound draft passes through your approval again before it can publish.

Getting started with ARDS