One name per concept for a node's type

A node has a type it is an instance of and a type it is drawn as. They are different things, and a payload that spells both the same way cannot be read without knowing who wrote it.

What it means

A node has two identities that a payload can be forgiven for confusing: the type it is an instance of, and the type it is drawn as in an editor. The first is node_type_id; the second is visual_type. A bare node_type key could carry either meaning, and a reader would have no way to tell which without already knowing which producer wrote it. The rule gives each concept its own name and forbids the shared one everywhere: job metadata, node metadata, a serialised node execution result, a node-status broadcast, a persisted session message, and a per-node snapshot all name the concept they mean, not the spelling that happens to be shortest.

A node's own identifier, node_id, is a third thing again and unaffected by any of this: it names which node, not what kind.

Example

A per-node snapshot spells the node's drawn type visual_type; a node execution result, carried on the same kind of event, spells the same node's type-it-is-an-instance-of node_type_id — two different concepts, on two different payloads, never the bare key.

{"nodeStates": {"chat.1": {"metadata": {"visual_type": "terminal", "label": "Chat"}}}}

{"nodeId": "chat.1", "output": { … }, "node_type_id": "chat_output"}