FlowDrop Workflow Specification 1.0-draft

A trigger's condition set is a closed vocabulary

A connector with its own data to carry has one place to put it, so a reader can tell a declared condition from a connector's private key.

The rule

Normative: this is the rule
  1. A trigger's conditions are a closed vocabulary: the condition keys this specification declares, and no others alongside them.
  2. Event-type-specific data a connector needs to carry is written under the designated extension key, whose contents this specification does not constrain.
  3. A connector writing its own keys beside the declared ones is writing an invalid condition set.

What it means

A reader inspecting a trigger's conditions has to be able to tell a declared condition from whatever a connector decided to carry alongside it, without knowing which connector wrote the record. That is only possible if every connector's own data lands in the same one place rather than each writing its own top-level keys, which is why the vocabulary is closed: the declared condition keys, one designated key for everything else, and nothing beside them.

Example

An event type's own condition data, carried entirely under the one designated key:

A trigger's conditionsvalid
{
  "custom": {
    "payload_schema": {
      "type": "object",
      "additionalProperties": true,
      "properties": { "title": { "type": "string", "title": "Title" } }
    },
    "required_fields": ["title"]
  }
}

Nothing here is declared beside custom: payload_schema and required_fields are the connector's own data, and both sit inside it rather than alongside it.

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 · OCX-5 · changed in spec 1.0