A workflow's launch inputs are declared, never inferred
The launch surface is the author's decision, written down. If it were derived from what the nodes happen to expose, adding a parameter to a node would widen what the outside world may send.
The rule
- The inputs a caller may supply when launching a workflow are a manifest the author declared on the workflow, and are never derived from port exposure.
- A declared entry is built into the workflow's contract even when the instance hides the port it names, and a port that is exposed but not declared never reaches the contract.
What it means
The launch-input manifest is a list the author wrote, not a computation over the workflow's nodes. That cuts both ways, and the second direction is the one that bites. A node's parameter can be hidden on the instance and still sit in the manifest — the entry still reaches the contract, because hiding a port is an instance setting, not an edit to what the author declared. And a node's parameter can be exposed, wired, fully visible in the editor, and never reach the contract at all, because nothing in the manifest names it.
The consequence: adding a parameter to a node type, or exposing one that used to be hidden, never by itself changes what a caller may send. Only an edit to the manifest itself does that (MAN-2, MAN-3).
Example
The node type declares two parameters, key and other. The instance hides
key and exposes other — the opposite of what the manifest entry below
declares.
{ "name": "lookup_key", "node_id": "n1", "port": "key" }{ "properties": { "lookup_key": { "type": "string", "x-data-type": "string" } } }other is exposed on the instance and never appears. lookup_key is hidden
on the instance and appears anyway, because the manifest named it.