OPEN-26
An absent member was not provided, a null was provided with no value, and empty is always a value.
What was open
The conventions said that an absent member and a null member are different, but not what either one means. The parameter tiers, edge delivery and workflow outputs agreed with each other: a missing key is not provided, and a null is a real value that wins over config. Other rules read the states another way. A null node-type default counted as no default, an extraction that matched a null counted as a miss, an absent edge handle became the empty string, an empty snapshot version skipped its check, and a blank tool call id was dropped. Unbound workflow outputs (OPEN-27) could not be specified until null had one meaning.
Decision
Every payload in the specification reads the states of a member one way. An absent member was not provided, and a fallback the rules give for it applies. A null member was provided with no value: it is a choice, it takes the place of any fallback, and in a partial update it clears the stored value, as in JSON Merge Patch (RFC 7396). An empty member ("", [], {}, false, 0) was provided with a value, and no rule reads it as absent or as null. There are no exceptions for empty values, because a value that one rule reads as absent changes meaning when it is serialized and read back by another implementation. An output that produced no value is absent from a run result, and null appears there only when a node produced null, so a null never overrides the next node's config by accident. The definition agrees with JSON Schema, which the contracts and port schemas are written in, with no exceptions, so an off-the-shelf validator in any language gives the specification's verdict. Node parameters follow it too: a parameter nothing supplies is absent from the resolved set rather than null (CFG-3, CFG-6, CFG-14, DYN-4), required is met by a present null (CFG-9), and a null is validated against the parameter's schema like any other value, at run time and at save (CFG-10, R6.i). A parameter that accepts "nothing chosen" says so with a type that admits null. CFG-13, CFG-15, CFG-18, CFG-21, EXPO-10, SCH-5, SCH-8 and SCH-27 follow from the same reading. CFG-3, LANG-24, EDGE-2, INT-8, MEM-16 and STORE-4 are rewritten to follow the definition, and R8.a, R8.b, R12 and R13 say "absent or empty" where they relied on EDGE-2 turning an absent edge end into the empty string. The rules that read an empty value as absent stop doing so: an empty active-branch list is a branch decision (BR-1, BR-2), an empty edge type is an unrecognised one (EDGE-5), and an empty flow id is refused while an absent one is minted (STORE-9). Path evaluation reports whether it matched, so a matched null is never taken for a miss (LANG-8, LANG-9, LANG-19). A snapshot of a run with no workflow leaves its version absent (INT-6), and R6.i calls a null config value present rather than unset. Author metadata on a manifest entry overlays an empty value and lets null remove the port's own (MAN-6), and an absent exposure name takes part in no uniqueness check (R4.a).