FlowDrop Workflow Specification 1.0-draft

The author's words win over the node's

A node's own annotation describes the port in general. The author describes what this workflow means by it, so the author's text is the one a caller sees.

The rule

Normative: this is the rule
  1. Author-supplied metadata on a manifest entry is overlaid onto the contract fragment after the fragment has been reduced, and overrides any annotation the bound port declares.
  2. The overlay applies to the input side only.
  3. An empty value is dropped rather than overlaid, so blank author metadata does not erase the port's own.

What it means

A port's own schema can carry a title or a description written by whoever built the node type — a general description of what the parameter is. The author writing a manifest entry can say something more specific to this workflow, and when they do, their words are what a caller sees, overlaid onto the fragment after MAN-5 has already reduced it. The overlay applies only to the input side.

The exception is what makes it safe to overlay unconditionally: an empty value is dropped rather than overlaid, so an author field left blank does not erase the port's own words with nothing. Filling it in later is still possible precisely because leaving it blank did not already win.

Example

The workflow declares one input, name, bound to a port whose node type has its own title for the same field.

The author already wrote a title for this input200 — kept
GET /api/flowdrop/workflows/{workflow}/schema?annotated=1

{"parameter_schema": {"properties": {"name": {"type": "string", "title": "Author Title"}}}}
The author left the same field blank200 — filled
GET /api/flowdrop/workflows/{workflow}/schema?annotated=1

{"parameter_schema": {"properties": {"name": {"type": "string", "title": "Text value", "description": "A plain text field."}}}}

An authored title stands even when the bound port's own annotation disagrees; a blank one is filled from the port instead of publishing nothing.

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 · MAN-6 · changed in spec 1.0