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

# SCH-38 — A loop-back input is a control sink, and `any` is retired

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

`any` and `trigger` differed in one way only (one had compatibility rules built into it from every other lane), and that is a property of being the sink, not of being `any`.

## The rule

> **Normative.** This is the rule.
>
> 1. A `loop_back` input declares the `trigger` lane.
>
> 2. `any` is no longer a lane a port may newly declare, and the rules that make the sink reachable from every other lane target `trigger` instead.
>
> 3. `any` is not removed from the served payload: it is served disabled, with compatibility rules in both directions and a description saying it is deprecated, because an editor builds its compatibility map from the served list alone and omitting a lane silently makes every edge on a port still declaring it incompatible.
>
> 4. A consequence of targeting `trigger` is that a data output may be drawn into an ordinary trigger input; the runtime discards the value rather than delivering it.
>
> 5. Compatibility is an authoring affordance only: no server path validates a connection against port lanes, so a wire an editor newly permits was already accepted by every server path if authored by hand.

## Related rules

- Names: SCH-32, SCH-37, SCH-38.a, SCH-39
- Referenced by: SCH-32, SCH-37, SCH-38.a, SCH-39

---

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.