---
id: SCH-46
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-46
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# SCH-46 — A shape's schema is served on the lane, not on every port

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

One copy of each shape's schema, on the lane entry, keeps it fresh when a site edits a shape and leaves the per-port slot free for the narrower thing that actually needs it.

## The rule

> **Normative.** This is the rule.
>
> 1. A shape's JSON Schema is served on the lane entry, once.
>
> 2. It is absent rather than empty where the lane has no shape, so a client can tell "promises nothing" from "promises an object with no properties".
>
> 3. It is not stamped onto each port declaring the lane: a per-port copy repeats on every node type wearing the lane, and it would go stale when a site edited a shape, because the lane payload's invalidation tracks shape edits while a per-node-type payload does not.
>
> 4. The per-port schema slot stays free for the one refinement that needs it: a narrower schema observed on a run, which is per-instance information and could never live in a payload cached per node type.
>
> 5. Such an observed schema is authoring information only: it is a sample, not a contract, and must never become what enforcement checks.
>
> 6. A stored overlay entry for the same lane id replaces the composed entry whole, its schema included.

## Related rules

- Names: SCH-10.a, SCH-42
- Referenced by: SCH-10.a, SCH-42, 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.