FlowDrop Workflow Specification 1.0-draft

Priority 1, a value delivered on a wire

The first place a parameter's value can come from is the run itself: a value another node sent down a wire, or a value the launch payload supplied.

The rule

Normative: this is the rule
  1. A parameter takes its value from the runtime inputs when the parameter is internal, or is both connectable and exposed, and the runtime inputs contain a key of that name.
  2. A key present with a null value counts as supplied (CFG-7).
  3. A parameter that fails this test falls through to priority 2 (CFG-5).

What it means

Priority 1 does not just ask whether a value showed up on a wire; it asks whether the parameter was allowed to receive one. An internal parameter always qualifies; an ordinary one needs both gate flags open — connectable and exposed — before a wire or a launch value can reach it at all. Once the runtime carries a key of that name and the gate is open, that value wins even though the author's saved config also holds one for the same parameter: the config is never consulted once priority 1 succeeds. Presence, not truthiness, decides whether the key counts as supplied (CFG-7), so an explicit null on the wire wins here too. Where the test fails — no key, or the gate closed — resolution falls through to CFG-5.

Example

A node's value parameter is connectable and exposed. The workflow's own saved config holds from-config for it, and a wire also delivers a value when the node runs:

The value delivered on the wireresolved
{"value": "from-runtime"}

The saved from-config value is never read: priority 1 already supplied one.

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 · CFG-4 · changed in spec 1.0