What a workflow is

A workflow is a saved, versioned graph of steps — reads, model calls, coder work, approval gates — that a mission can execute instead of ad-hoc planning. Four rules define how workflows behave in ARDS. Learn them on this page; every other page in this section builds on them.

A workflow executes nothing by itself

A workflow executes nothing by itself. It is a plan, not a process. The only thing that executes in ARDS is a mission: the workflow describes what should happen, and it stays inert until a mission runs it.

A workflow meets a mission in exactly two ways:

  • Attach it to a mission. You pick a published workflow (and its version) for a mission — typically in the attach dialog when you create the mission — and the mission runs it.
  • Invoke it directly. You start from the workflow itself, and ARDS creates a new mission around it, because a run always needs a mission to live in.

Both roads lead to the same place: one mission, running one workflow, on the mission's own branch. There is no third road where a workflow "just runs" in the background on its own.

Runs propose; you accept

Each execution of a workflow inside a mission is a run. A run does its work on its own branch and is born Proposed. From there you choose what happens: Accept run lands its changes as Accepted; a run you decline ends Rejected — discarded by an agent, or auto-rejected when a competing sibling wins. The run states are summarized in the states cheatsheet.

Accepting a run lands exactly one changement — a single reversible delta — on the mission's branch. Discarding lands nothing, so there is nothing to undo. The full loop, revert included, is walked through in Runs, acceptance & changements.

Nothing is automatic by default

Workflows carry gates: points where the run pauses and waits for a decision in your Decisions queue. No gate auto-approves unless that specific gate was explicitly opted in — auto-resolution is per-gate, tracked, and off by default. It is never a platform-wide switch.

And approval always changes hands: you can't approve your own proposal. Whoever proposed a piece of work — human or agent — cannot be the one who approves it. Gates are covered in Control flow; the wider rules live in Governance.

Acceptance is physical

When you click Accept run, the merge is validated mechanically before anything lands: the system validates the run branch by exercising the merged result — never by an LLM verdict — and it refuses rather than waving anything through when it can't verify. Treat this as a requirement the platform enforces on every accept, not a feat any single run demonstrates: if the mechanical check cannot complete, the accept refuses, and the right move is to start a fresh run. A model saying "looks good" is never acceptance.

What's in the box

How to read this section

Pick the path that matches where you are: