FlowDrop Workflow Specification 1.0-draft

Initial data fills a node's ports only where no edge did

The rule

Normative: this is the rule
  1. Initial data supplied with a run, keyed by node identifier, fills that node's input ports underneath anything an edge delivered: an edge-delivered value wins, including an edge-delivered null.
  2. An entry keyed for another node, or one that is not a map of port names to values, is ignored.

What it means

Initial data is a fallback, not a second source competing with an edge: it only ever fills the ports an edge left untouched. An edge-delivered null still counts as delivered, so it still wins over a seeded value at the same port — the merge is keyed on presence, not on usefulness. An entry keyed for a node other than the one running is ignored outright, and an entry that is not itself a map of port names to values is dropped rather than merged in some other shape.

Example

A node's message port is fed by an edge; its seed port is not. Initial data carries a value for both ports, keyed to this node.

What the run's initial data offers this nodeoffered
{"message": "from_initial_data", "seed": "only_in_initial_data"}
What the node actually receivesmerged
{"message": "from_edge", "seed": "only_in_initial_data"}

The wired port keeps the edge's value; the unwired one takes the seed. Where the edge instead delivers an explicit null on message, the node still receives {"message": null} — the seed does not get a second chance because the delivered value happens to be empty.

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 · DATA-6 · changed in spec 1.0