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.

What it means

A shape's schema travels once, on the lane entry itself, whichever lane carries it and however the shape was declared — a shape the site wrote and one shipped in code both reach the client by the same route. A lane with no shape omits the key entirely rather than serving an empty schema, so a reader can tell "this lane promises nothing" from "this lane promises an object with no properties" without inspecting the fields it does not have. The schema slot on an individual port stays free for something no lane-level copy could hold: a narrower schema observed from one run of one node, which is authoring information for that instance alone and must never be treated as something enforcement checks.

Example

A site declares a shape for the lane order.

The site's shape for the order lanestored
{
  "id": "order",
  "label": "Customer Order",
  "enabled": true,
  "schema": { "type": "object", "properties": { "id": { "type": "string" }, "total": { "type": "number" } } }
}
The properties served on the order lane entryserved
["id", "total"]
The properties served on the error lane entry, shipped in codeserved
["message", "code", "node_id", "retryable"]

A shape the site declares and one shipped in code arrive on the served lane list by the identical path; neither is stamped onto the ports that declare the lane.

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