FlowDrop Workflow Specification 1.0-draft

A site's lane configuration overlays the shipped one

A site may recolour, rename or add lanes. What it stores is a patch on the shipped vocabulary; serving it as a replacement freezes the vocabulary at the moment it was saved.

The rule

Normative: this is the rule
  1. A stored site-level lane configuration is an overlay on the shipped defaults, not a replacement.
  2. Stored entries win outright (a recoloured or renamed lane, a site-only lane, the site's own compatibility rules), and shipped entries the stored value never mentions fill the gaps: lanes are merged per id with unmentioned shipped ids appended after the stored ones, so the site's ordering survives; compatibility rules are unioned on the from/to pair; scalar keys are stored-wins.
  3. There is no negative form, so a site cannot suppress a shipped rule by omission, the safe direction, since a missing rule silently refuses a valid edge while an extra one only permits.
  4. Serving a stored overlay wholesale is a defect: every lane added after it was saved would go missing, and by SCH-10's coupling every port carrying such a lane would be compatible with nothing, not even with itself.

What it means

A site's stored lane configuration is read as a set of edits on top of the shipped vocabulary, never as the whole vocabulary. A lane the site never mentions is not missing from what gets served — it is carried over from the shipped defaults exactly as if the site had retyped it. The only exception is ordering: unmentioned shipped lanes are appended after the stored ones, so a site's own ordering choices still show first.

This matters most for a lane that did not exist yet when the site saved its configuration. Because there is no negative form — a site cannot suppress a shipped lane or a shipped compatibility rule by leaving it out — a lane shipped later still reaches every site that customised its lanes earlier, with the compatibility rules it needs to be wireable at all.

Example

A site recoloured string and added a lane of its own, before a messages lane existed in the shipped vocabulary:

A site's stored lane configurationstored
{
  "version": "0.9.0",
  "dataTypes": [
    { "id": "string", "name": "Text", "description": "Recoloured by the site.", "color": "rebeccapurple", "category": "basic", "enabled": true },
    { "id": "site_custom", "name": "Site Custom", "description": "A type only this site declares.", "color": "var(--fd-node-slate)", "category": "basic", "enabled": true }
  ],
  "compatibilityRules": [
    { "from": "site_custom", "to": "string" }
  ]
}

Serving this recolours string and keeps site_custom and its rule, exactly as stored. It also still serves messages — a lane the stored value never mentions — with the one-way compatibility rules that make it wireable into array and json ports, because those come from the shipped defaults the overlay leaves untouched.

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 · SCH-10.a · changed in spec 1.0