Outcome route

Use Outcome route to evaluate a value and make it available to later work. Downstream branch conditions decide what runs next; an optional bounded loop sends requested changes back for another pass. In YAML, an Outcome route uses kind: condition.

Configuration

- key: route_review
  name: Route Review Outcome
  kind: condition
  needs: [await_review]
  checks:
    - kind: value_equals
      value: "${steps.await_review.outputs.outcome}"
      equals: review_approved
  outputs:
    outcome: "${steps.await_review.outputs.outcome}"

Without onFailure, the route completes whether its checks match or not. It publishes only the outputs you declare; the match result is recorded as execution evidence, not an automatic output. Set onFailure.action to block or fail when a mismatch should stop the run; declared outputs are retained. Use loop_back for the bounded repetition described below.

Downstream steps depend on the route and use their own when checks to choose their path:

- key: verify_task
  name: Verify Task
  kind: tool
  needs: [route_review]
  when:
    - kind: value_equals
      value: "${steps.route_review.outputs.outcome}"
      equals: review_approved
  tool:
    id: pm_task
    action: change_status
  inputs:
    taskKey: "${workflow.inputs.taskKey}"
    to: verified

A false when skips the downstream step; it does not fail the run. Each branch is evaluated independently: more than one branch can run, or all can skip. Use mutually exclusive checks when only one branch should run. A route does not choose a branch automatically.

Supported checks

Values can come from literals, workflow inputs, upstream outputs, or runtime loop values. All authored checks must match for the route to report a match; no checks means a match.

Bounded loop back

Add loop_back when a failed check should return to a strict earlier step:

- key: route_review
  name: Route Review
  kind: condition
  needs: [await_review]
  checks:
    - kind: value_equals
      value: "${steps.await_review.outputs.outcome}"
      equals: review_approved
      domain: [review_approved, review_changes_requested]
  outputs:
    outcome: "${steps.await_review.outputs.outcome}"
  onFailure:
    action: loop_back
    to: request_revision
    max: 3
    exhausted: block

The loop target must be a strict dependency ancestor of the route. A loop-back check uses one value_equals check with a non-empty, unique domain that contains equals and lists every possible observed value; a value outside that closed domain blocks the run. Keep the repeated path between the target and route narrow: its steps cannot declare retry, its child workflows cannot use forEach or detached, and loops cannot overlap. Side branches cannot read outputs from the repeated path or rejoin work that depends on the route. Valdr preserves every attempt, so the run inspector shows each implementation and review pass.

Inside the loop, ${runtime.loop.currentPass} and ${runtime.loop.maxPasses} are available when a prompt or output needs the pass number.

In Valdr UI

Add Outcome route from the Builder library. Select Add closed condition check, then set Outcome to evaluate, Outcome that continues, and Allowed outcomes. This guided form edits one value_equals check; other check types or multiple checks use Authored checks JSON.

Under Routing, choose When outcome does not continue. For Repeat (loop_back in YAML), select Repeat from, Total passes (includes first), and When exhausted. Connect downstream work and configure its branch conditions separately.

Next step

Return to Workflow Steps or use Run Workflow Steps to compose a reusable process into the selected branch.