---
id: SCH-10.a
family: GR-SCHEMA
level: extended
profiles: [storage-api, editor-client]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/gr-schema/sch-10-a
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# SCH-10.a — A site's lane configuration overlays the shipped one

*GR-SCHEMA (Part I) · level: extended · profiles: storage-api, editor-client · added in 1.0*

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.

## Related rules

- Names: SCH-10, SCH-41, SCH-44, SCH-46
- Referenced by: SCH-36, SCH-41, SCH-44, SCH-46, SCH-45

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.