continueIf and Shorthand (Legacy)

if: "X" desugars to if: { equals: "X", then: continue, else: abort }:

if: "READY"
# identical to:
if: { equals: "READY" }

This is convenient for simple equality gates where the defaults (continue on match, abort on miss) are what you want. The shorthand is purely syntactic — the parser expands it to the full form before validation.

Use the full object form when you need:

• A non-equals condition (integerRange, contains, jsonMatches, etc.)
• A non-default then: action (jump, write)
• A non-default else: action (anything other than abort)

continueIf: "X" is the legacy form from before typed gates existed. It desugars to the same thing as the shorthand:

continueIf: "READY"
# identical to:
if: { equals: "READY", then: continue, else: abort }

The desugaring happens at parse time. The runtime never sees continueIf — it only sees the expanded if: block. This means all gate evaluation logic (per-node pruning, step-level action, observability events) works identically for both forms.

Hard rules:

• continueIf and if are mutually exclusive. Declaring both fails validation: Step "X": cannot declare both "continueIf" (deprecated) and "if" — use only "if".
• continueIf has no effect on a single-node step (a step with no nodes:). Validation warns when this is detected.
• Existing published ladders using continueIf continue to work unmodified. There is no deprecation timeline — the form is supported indefinitely.

New ladders should always prefer the typed if: form. It covers every case continueIf does, plus richer conditions (ranges, substrings, sets, JSON Schemas) and richer actions (jumps and writes, not just continue/abort).

To migrate an existing ladder, replace every continueIf: "X" with if: "X" (or the full object form if you want to customize the actions). The behavior is identical. The benefit: your ladder now uses the modern form that supports all condition types and actions.