Conditionals

Routing lives on edges, not in a decision node. Each outgoing edge either carries a condition or is the fallback. On success, Orbital tries the conditioned edges from the highest weight down, takes the first match, and only then considers the fallback.

A condition compares one context path with a literal: verdict == 'pass', outcome != 'failed' or attempt == 2. A bare path tests truth and !path negates it. Missing values, false, zero and empty text are falsy. There are no boolean operators and no comparisons between two context paths, which keeps every route readable in the graph rather than hidden in an expression.

Choose the cheapest observation

Use a built-in probe when Orbital already observes the fact. The ticket workflow routes on pull request state without asking an agent whether a merge happened.

For another exact observation, use a script command with declared bool, number or text facts, and emit the final JSON object exactly as declared. Keep the script read-only when it only inspects something.

For judgement, declare an agent choice. Orbital infers the allowed values from the node’s outgoing conditions and rejects any other answer, so outputs="verdict:choice" with edges for pass and reject accepts nothing else.

Cover every case

Give conditioned edges distinct weights; two edges cannot share one. A branching node needs a fallback unless its conditions already cover every value of its declared choice. No matching edge is an error at run time, so validation asks for the fallback up front.

A fallback handles successful observations outside your named cases. It never handles a failed stage. Failure routing is separate and deliberate; see loops and error handling.

Work through how to do branching for a complete graph, and check error handling before reading a value produced on only one branch.