FlowDrop Workflow Specification 1.0-draft

The workflow schema door publishes a bare document

A workflow's declared input and output ports, read by an editor before it can draw the workflow. It is not wrapped in the standard envelope, and its snake_case is as much a contract as the playground's camelCase.

The rule

Normative: this is the rule
  1. A successful read of a workflow's schema answers exactly {schema_version, parameter_schema, output_schema} in that order, snake_case, with no success key and no data wrapper.
  2. parameter_schema and output_schema are the stored snapshot verbatim, and where a workflow declares no ports they are JSON null (not an empty object, and not omitted), so a consumer can distinguish "no ports" from "key missing".

What it means

This door answers with no envelope at all: no success, no data, just the three keys themselves. And where a workflow declares no ports, the missing schema is null, not an empty object and not a key left out — the three shapes ("no ports", "an empty object", "key missing") would otherwise all look the same to a consumer that has to guess which one it is looking at.

Example

A workflow with both a declared input and a declared output:

A workflow's declared parameter and output schemas200 — served
GET /api/flowdrop/workflows/{id}/schema

{"schema_version": "2.1.0", "parameter_schema": {"type": "object", "properties": {"name": {"type": "string"}}}, "output_schema": {"type": "object", "properties": {"result": {"type": "string"}}}}

A workflow that declares no ports at all:

A workflow with no declared ports200 — served
GET /api/flowdrop/workflows/{id}/schema

{"schema_version": "0.0.0", "parameter_schema": null, "output_schema": null}
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 · META-4 · changed in spec 1.0