FlowDrop Workflow Specification 1.0-draft

A tool's model-facing schema hides the parameters the workflow already fixed

The rule

Normative: this is the rule
  1. The tool schema offered to a model omits every parameter the workflow has already decided: one pinned in the tool node's configuration, and one fed by an edge.
  2. The model is asked only for the parameters that remain open.

What it means

The two ways a workflow can already decide a parameter are treated identically, and a reader might expect otherwise: a value the author typed into the tool node's own configuration and a value another node feeds it on a wire both drop out of the model-facing schema the same way. The model is never asked to guess at something the workflow has already committed to supply, however that value arrives — it makes no difference to what the model is offered.

Example

A tool node's parameter schema declares two connectable parameters, url and query; the workflow pins a value for url in the node's own configuration.

The tool node's declared parameter schemadeclared
{
  "type": "object",
  "properties": { "url": { "type": "string" }, "query": { "type": "string" } },
  "required": ["url"]
}

Only query survives into the model-facing properties, and required is left empty: the pinned url drops out of both.

An edge feeding url from another node instead of a pinned configuration value removes it the same way — the same properties, the same empty required.

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 · DATA-11 · changed in spec 1.0