FlowDrop Workflow Specification 1.0-draft

A declined node routes a structured verdict out its error port

A decline is a real outcome an author can handle, delivered where every other node failure is delivered. It is deliberately not a pair of branch ports that appear and disappear with a configuration flag.

The rule

Normative: this is the rule
  1. A declined node that was scheduled in the graph must not be executed, and the decline becomes an error output on the node's reserved error port carrying the code confirmation_declined and details naming the interrupt type, the reason, who declined, when, and the interrupt's identifier; those details are forwarded as the error edge payload's optional details.
  2. Where an error edge is wired the decline is a handled failure (ERR-7); otherwise the run's default failure behaviour applies (ERR-8).
  3. A decline must not be surfaced as branch ports that exist only when confirmation is configured; a port surface that depends on a configuration flag breaks the canvas contract.
  4. An author who wants first-class branching on a human decision uses an explicit confirmation node.

What it means

A decline is not a second set of branch ports appearing on the node because confirmation happens to be turned on for it. It is the same error port every other failure on that node would use, carrying a verdict shaped like any other structured error. An author who wants a decision a workflow can branch on wires an explicit confirmation node instead; a gate is not that node.

Example

A node the operator declines never runs; what its reserved error port carries instead:

What the declined node's error port carriesdeclined
{
  "code": "confirmation_declined",
  "details": { "type": "confirmation_declined", "reason": "declined" }
}
Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · RT-GATE-4 · changed in spec 1.0