FlowDrop Workflow Specification 1.0-draft

Compilation always re-enriches node metadata from the live node types

Stored node metadata is a cache, and an author-editable one. Compilation refreshes it from the node types themselves so a run can never be planned against stale or attacker-supplied metadata.

The rule

Normative: this is the rule
  1. Compilation re-enriches every node's metadata from the live node type definitions before planning the run.
  2. This holds at every entry point into compilation: no caller can compile a workflow whose stored node metadata is taken on trust.
  3. The re-enriched workflow is normalized before it is compiled.

What it means

Stored node metadata is a cache the author can edit, not a source of truth. Every time a workflow is compiled, its node metadata is thrown away and rebuilt from the node types themselves, so whatever a stored record claims about a node — up to and including which processor runs it — never survives past compilation unless the live node type still agrees with it.

Example

A stored node claims a description that no longer matches its node type:

What the stored node claimsstale
{ "node_type_id": "live_probe", "description": "Stale description" }
What compilation records for itfresh
{ "node_type_id": "live_probe", "description": "Fresh description" }

The node type's own description wins; the stored claim never reaches the compiled workflow at all.

Why

Recorded under OPEN-19.

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 · CMP-2 · changed in spec 1.0