FlowDrop Workflow Specification 1.0-draft

A shape's schema is served on the lane, not on every port

One copy of each shape's schema, on the lane entry, keeps it fresh when a site edits a shape and leaves the per-port slot free for the narrower thing that actually needs it.

The rule

Normative: this is the rule
  1. A shape's JSON Schema is served on the lane entry, once.
  2. It is absent rather than empty where the lane has no shape, so a client can tell "promises nothing" from "promises an object with no properties".
  3. It is not stamped onto each port declaring the lane: a per-port copy repeats on every node type wearing the lane, and it would go stale when a site edited a shape, because the lane payload's invalidation tracks shape edits while a per-node-type payload does not.
  4. The per-port schema slot stays free for the one refinement that needs it: a narrower schema observed on a run, which is per-instance information and could never live in a payload cached per node type.
  5. Such an observed schema is authoring information only: it is a sample, not a contract, and must never become what enforcement checks.
  6. A stored overlay entry for the same lane id replaces the composed entry whole, its schema included.
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-46 · changed in spec 1.0