FlowDrop Workflow Specification 1.0-draft

Shape compatibility is nominal and mostly derived

Two shapes match because they carry the same name, never because their schemas happen to agree; otherwise edge legality would drift every time a schema gained a field.

The rule

Normative: this is the rule
  1. A shape is compatible with another because they share an id, never because two schemas were compared.
  2. Structural matching would make edge legality depend on schema evolution: two unrelated shapes that coincide today would silently interconnect, and silently disconnect when one gained a field.
  3. Every shape matches itself, and derives a one-way widening into json and into the sink: a consumer already typed json must keep accepting a shaped value without being rewired, and the reverse is refused because a bare object carries no guarantee of the shape.
  4. Any further widening is a hand-written rule that states its reason where it is declared.
  5. Shapes join the lane list before the sink and control rules are generated, so a new lane receives those by construction rather than by a second derivation.
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 · SCH-43 · changed in spec 1.0