RFC 7950 - The YANG 1.1 Data Modeling Language

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

Negative

what Ze owes

The 8 shares marked as a part above are the whole of the 91 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: The YANG 1.1 Data Modeling Language (ze config validator). The extraction walk of 2026-09-21 read all 227 MUST sites and rewrote this ledger: it added 67 MUST rows the checklist did not carry, covering module and submodule structure, identifier and prefix scoping, typedef and leaf definition rules, list keys and unique constraints, choice, grouping, augment, identity, feature, deviation, status and when rules, the Section 8.1 validity conditions and the Section 8.3 enforcement windows, the built-in type restrictions of Section 9, the module update rules of Section 11 and the YANG 1/1.1 coexistence rules of Section 12. On 2026-09-21 twelve of the added rows gained positive and negative tags (seven at the loader boundary in internal/component/config/yang/rfc7950_loader_test.go, decimal64 and default validation in the validator and the schema builder), one is single-polarity, and the forty-eight left carry {gap} rows naming their specs. Of the nine rows that stood before the walk, four are met with positive+negative tags in internal/component/config: 8.3.1-1 (a value violating a range, length, or pattern restriction is an error), 9.6-1 (an enum value must be one of the defined enums), 9.12-1 (a union value must match at least one member type), and 7.6.5-1 (a missing mandatory node is an error). Five are {not-applicable}: 7.5.3-1 (ze uses no must XPath statements and enforces cross-field constraints with Go validators instead), 9.2.4-1 (derived-type narrowing is resolved by goyang at module-processing time with no runtime surface), 9.4.5-1 (no ze type carries multiple pattern statements), x-1 (ze's models declare no yang-version and default to YANG 1.0, using no 1.1-only construct), and x-2 (no cross-revision position-stability tooling; critical enum values are pinned with explicit value statements). The walk excluded 32 sites as the NETCONF protocol binding, the XML encoding and the YIN syntax, none of which ze uses: ze serves its YANG-modeled config over gNMI and its own CLI, and no Go file in internal/ references NETCONF except a port-name table. Three further sites delegate module-name and namespace assignment to the IANA procedure of the earlier YANG specification they cite.

What the public ledger says

Status: Partial

Coverage

Positive and negative tests (34): RFC7950-9.6-1, RFC7950-9.12-1, RFC7950-7.6.5-3, RFC7950-6.1.3-1, RFC7950-6.5-1, RFC7950-7.3.4-1, RFC7950-7.6.1-1, RFC7950-7.6.1-3, RFC7950-7.6.3-1, RFC7950-7.6.4-2, RFC7950-7.7.4-1, RFC7950-7.7.5-1, RFC7950-7.19-1, RFC7950-8.1-3, RFC7950-8.1-2, RFC7950-8.3-1, RFC7950-8.3.3-1, RFC7950-9.1-1, RFC7950-9.3.1-1, RFC7950-9.3.4-1, RFC7950-9.4.4-1, RFC7950-9.5.1-1, RFC7950-9.6.4-2, RFC7950-9.6.4.2-1, RFC7950-9.9-1, RFC7950-9.9.2-1, RFC7950-9.9.3-1, RFC7950-9.10.3-1, RFC7950-9.13-1, RFC7950-7.2.2-1, RFC7950-7.3.2-1, RFC7950-7.9.2-2, RFC7950-9.1-2, RFC7950-9.4.4-2

Annotated (including scoped evidence) (57): RFC7950-7.6.5-1, RFC7950-7.6.5-2, RFC7950-7.5.3-1, RFC7950-9.2.4-1, RFC7950-9.4.5-1, RFC7950-x-1, RFC7950-x-2, RFC7950-5.1-1, RFC7950-5.3-1, RFC7950-5.5-1, RFC7950-5.6.5-1, RFC7950-6.2-1, RFC7950-6.2.1-1, RFC7950-6.3.1-1, RFC7950-6.4-1, RFC7950-6.4-2, RFC7950-7.1.4-1, RFC7950-7.3-1, RFC7950-7.6.1-2, RFC7950-7.6.1-4, RFC7950-7.7-1, RFC7950-7.7.2-1, RFC7950-7.8.2-1, RFC7950-7.8.3-1, RFC7950-7.9.2-1, RFC7950-7.9.3-1, RFC7950-7.9.4-1, RFC7950-7.12-1, RFC7950-7.14.2-1, RFC7950-7.14.3-1, RFC7950-7.15-1, RFC7950-7.16-1, RFC7950-7.17-1, RFC7950-7.18.2-1, RFC7950-7.20.1-1, RFC7950-7.20.2-1, RFC7950-7.20.3-1, RFC7950-7.20.3.2-1, RFC7950-7.21.2-1, RFC7950-7.21.5-1, RFC7950-8.1-1, RFC7950-8.1-4, RFC7950-8.3.1-2, RFC7950-8.3.2-1, RFC7950-8.3.3-2, RFC7950-9.2.4-2, RFC7950-9.6.4-1, RFC7950-9.7-1, RFC7950-9.7.4-1, RFC7950-9.7.4.2-1, RFC7950-9.10.2-1, RFC7950-9.12-2, RFC7950-11-1, RFC7950-11-2, RFC7950-11-3, RFC7950-7.21.5-2, RFC7950-12-1

Partial proof; remaining gap (subset of annotated; zero whole-requirement credit) (3): RFC7950-7.6.5-1, RFC7950-7.9.4-1, RFC7950-9.10.2-1

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC7950-9.6-1

The enumeration built-in type represents values from a set of assigned names. (§9.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. SHIFTED only: the tagged units are byte-identical (gate-verified) and validateEnumeration is unchanged. Re-read: TestValidateTree_FamilyModeEnum and TestValidateTree_AddPathDirectionEnum supply router-id and session/asn/local, so no missing-mandatory error precedes errs[0]; the invalid name is refused ErrTypeEnum and every assigned name gives no error; radius auth-method and isis algorithm refuse an unassigned name with ErrTypeEnum and accept every defined one. Re-run green 2026-10-12. Verdict stands.

RFC7950-9.12-1

The union built-in type represents a value that corresponds to one of its member types. (§9.12)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. SHIFTED only: the tagged units are byte-identical (gate-verified) and validateUnion is unchanged. negative: "not-an-ip" matching no member refused with ErrTypeType; positive: values matching only the first, only the second and only the enum member each accepted, so a union check trying one member alone goes red. Records on validateUnion for all three units. Re-run green 2026-10-12. Verdict stands.

RFC7950-7.6.5-1

If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): o If no such ancestor exists in the schema tree, the leaf MUST exist. (§7.6.5)

Scoped tag-claim records only: tested "the leaf MUST exist"; gap "If no such ancestor exists in the schema tree"; internal/component/config/validate_sections.go::ValidateCustomSections is the boundary: Tested covers a mandatory leaf whose ancestors are all non-presence containers, required whenever its top-level section is present in the config (bgp/router-id, bgp/session/asn/local, once the bgp section holds a peer or a group); Gap is the same leaf when the whole top-level section is absent, which Ze does not require, because its top-level sections are non-presence containers that stand for an enabled feature and requiring their leaves would refuse every config that omits bgp; owner-approved deviation, OWNER RULING 6 of 2026-10-12 (Thomas, "Like FRR/libyang (Recommended)"): mandatory leaves are checked only in sections present in the config, as libyang's LYD_VALIDATE_PRESENT ("Validate only modules whose data actually exist") does when FRR sets it in nb_candidate_validate_yang (lib/northbound.c) and yang_parse_data (lib/yang.c); Gap also holds bgp/router-id and bgp/session/asn/local absent at the bgp level while every BGP session carries the value itself or from its group, which bgpMandatoryFailures counts as present through EverySessionCarries: a second owner-approved deviation, ruling of 2026-10-12 (Thomas, "yes enforce", spec AC-2); that ruling binds only once a session exists: a bgp section with no peer and no group is accepted and does nothing, so EverySessionCarries counts both leaves as present there (Thomas, 2026-10-16, spec AC-2 RULING 7); a deviation is never counted conformant; plan/pre-release/spec-config-yang-when-unique-choice.md; zero whole-requirement credit.

Audit verdict: partial (the tests enforce only the declared tested scope; the whole requirement remains unmet), fresh. Re-judged 2026-10-18 (independent auditor, after bccd1e7cf5). Read at rfc/full/rfc7950.txt Section 7.6.5: "If "mandatory" is "true", the behavior of the constraint depends on the type of the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): o If no such ancestor exists in the schema tree, the leaf MUST exist." The only change under this verdict is one appended line in ValidateCustomSections, found = append(found, referenceFailures(validator, tree)...), which adds require-instance failures after the mandatory ones and changes neither mandatoryFailures nor bgpMandatoryFailures nor walkTree; no tagged unit changed. Shipped modules hold one leafref (traffic default-class), so no tagged bgp config can gain a reference failure that would confound a mandatory assertion. ./le rfc discriminate id RFC7950-7.6.5-1 lists seven records, no stale and no unproven entry. Tested "the leaf MUST exist"; Gap "If no such ancestor exists in the schema tree"; Producer internal/component/config/validate_sections.go::ValidateCustomSections; the Tested/Gap/Producer text is unchanged. Gap stands as before: (a) an absent top-level section is not walked (owner ruling 6), (b) bgp/router-id and bgp/session/asn/local counted present through EverySessionCarries (owner rulings of 2026-10-12 and 2026-10-16). A deviation is never counted conformant; the whole requirement earns no credit.

RFC7950-7.6.5-2

Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists in the data tree. (§7.6.5)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. Section 7.6.5: "Otherwise, if this ancestor is a case node, the leaf MUST exist if any node from the case exists in the data tree." walkTree looks each data key up only in entry.Dir, so data under a choice's case is skipped as unknown, and requireMandatoryUnderAbsent stops at a choice; 975428e1b3 changed only the choice message. Live instances: interface/tunnel[x]/encapsulation/<kind>/remote/ip (tunnel-v4-endpoints, tunnel-v6-endpoints) and encapsulation/vxlan/vni in ze-iface-conf are mandatory leaves whose closest qualifying ancestor is a case node, so a gre tunnel with no remote ip passes the walk. Owner ruling 4; spec-config-yang-when-unique-choice.

No test carries RFC7950-7.6.5-2, so no unit is bound to it.

RFC7950-7.6.5-3

Otherwise, the leaf MUST exist if the ancestor node exists in the data tree. (§7.6.5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. Section 7.6.5: "Otherwise, the leaf MUST exist if the ancestor node exists in the data tree." The row's {partial} was removed in 60a74fc04b because the gap it declared (sections outside validatedSections) is closed: ValidateCustomSections now runs the full walk over validatedSections, mandatoryFailures over every other top-level section the compiled schema declares that is present in the config (Validator.Sections), and bgpMandatoryFailures over the bgp global level; LoadConfig, ze config validate, the web editor commit and the SSH editor commit (cli ConfigValidator.sectionErrors) all reach it. Negatives: TestRFC7950MandatoryOutsideValidatedSections has LoadConfig refuse a bfd profile whose auth presence container lacks type and secret, asserting ErrCustomValidation and both exact paths, in bfd, which the test asserts is outside validatedSections and inside Validator.Sections, so the refusal can only come from mandatoryFailures; TestRFC7950MandatoryRequiredWhenAncestorExists requires top/item[a]/inner/must and top/knob/sub/val when the list entry and presence container exist. Positives: the complete bfd profile loads; the leaves are not required when the ancestor is absent, and none is reported once supplied, so an over-eager walk goes red too. Records on mandatoryFailures, requireMandatoryUnderAbsent and walkTree. Population checked against today's schema: a scan of every conf module finds no mandatory node under bgp peer or group (bgpMandatoryFailures drops both lists before its walk) and no list or presence container inside a case holding one (walkTree does not descend into case data); every case-scoped mandatory leaf is RFC7950-7.6.5-2's population. Those two exclusions are latent and fail open for a future module (journal row, gate-excludes-part-of-its-population).

RFC7950-7.5.3-1

All such constraints MUST evaluate to "true" for the data to be valid. (§7.5.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.5.3-1, so no unit is bound to it.

RFC7950-9.2.4-1

If a range restriction is applied to a type that is already range-restricted, the new restriction MUST be equally limiting or more limiting, i.e., raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. (§9.2.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.2.4-1, so no unit is bound to it.

RFC7950-9.4.5-1

If the type has multiple "pattern" statements, the expressions are ANDed together, i.e., all such expressions have to match. (§9.4.5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.4.5-1, so no unit is bound to it.

RFC7950-x-1

The "yang-version" statement specifies which version of the YANG language was used in developing the module. The statement's argument is a string. It MUST contain the value "1.1" for YANG modules defined based on this specification. (§7.1.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-x-1, so no unit is bound to it.

RFC7950-x-2

An "enumeration" type may have new enums added, provided the old enums's values do not change. (§11)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-x-2, so no unit is bound to it.

RFC7950-5.1-1

Within a server, all module names MUST be unique. A module uses the "include" statement to list all its submodules. A module, or submodule belonging to that module, can reference definitions in the module and all submodules included by the module. A module or submodule uses the "import" statement to reference external modules. Statements in the module or submodule can reference definitions in the external module using the prefix specified in the "import" statement. For backward compatibility with YANG version 1, a submodule MAY use the "include" statement to reference other submodules within its module, but this is not necessary in YANG version 1.1. A submodule can reference any definition in the module it belongs to and in all submodules included by the module. A submodule MUST NOT include different revisions of other submodules than the revisions that its module includes. A module or submodule MUST NOT include submodules from other modules, and a submodule MUST NOT import its own module. The "import" and "include" statements are used to make definitions available from other modules: o For a module or submodule to reference definitions in an external module, the external module MUST be imported. o A module MUST include all its submodules. o A module, or submodule belonging to that module, MAY reference definitions in the module and all submodules included by the module. There MUST NOT be any circular chains of imports. For example, if module "a" imports module "b", "b" cannot import "a". When a definition in an external module is referenced, a locally defined prefix MUST be used, followed by a colon (":") and then the external identifier. (§5.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-5.1-1, so no unit is bound to it.

RFC7950-5.3-1

Namespace URIs MUST be chosen so they cannot collide with standard or other enterprise namespaces -- for example, by using the enterprise or organization name in the namespace. (Section 5.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-5.3-1, so no unit is bound to it.

RFC7950-5.5-1

Scoped definitions MUST NOT shadow definitions at a higher scope. (§5.5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-5.5-1, so no unit is bound to it.

RFC7950-5.6.5-1

A server MUST NOT implement more than one revision of a module. If a server implements a module A that imports a module B, and A uses any node from B in an "augment" or "path" statement that the server supports, then the server MUST implement a revision of module B that has these nodes defined. (§5.6.5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-5.6.5-1, so no unit is bound to it.

RFC7950-6.1.3-1

The backslash MUST NOT be followed by any other character. (§6.1.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): tagged units changed only in the 64-char tail of ModuleLoadAccepted (schema.GetEntry from the Resolved); cases unchanged, package green. RFC 6.1.3: 'The backslash MUST NOT be followed by any other character.' Prior judgement, still true: Re-judged 2026-10-09; the case edited in ModuleLoadRefused is another row's. Negative: case "bad escape" (description "bad \q escape", the only fault) requires an error containing "escape". Positive: case "valid escapes" loads \t \n \" \\ in a double-quoted string. Probe 2026-10-09: a single-quoted 'bad \q kept', where backslash is not special, loads, so the refusal is scoped to double quotes as Section 6.1.3 scopes it.

RFC7950-6.2-1

Implementations MUST support identifiers up to 64 characters in length and MAY support longer identifiers. (§6.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): the 64-character leaf is now read from schema.GetEntry of the returned Resolved, same assertions. RFC 6.2: 'Implementations MUST support identifiers up to 64 characters in length and MAY support longer identifiers.' Prior judgement, still true: {single-polarity} on the row. (a) forbidden: refusing or truncating a 64-character identifier. (b) TestRFC7950ModuleLoadAccepted loads a module whose leaf name is 64 characters (require.NoError on AddModuleFromText and Resolve) and assert.NotNil(entry.Dir[long]), which goes red if the name were refused or shortened.

RFC7950-6.2.1-1

All identifiers defined in a namespace MUST be unique. o All module and submodule names share the same global module identifier namespace. o All extension names defined in a module and its submodules share the same extension identifier namespace. o All feature names defined in a module and its submodules share the same feature identifier namespace. o All identity names defined in a module and its submodules share the same identity identifier namespace. o All derived type names defined within a parent node or at the top level of the module or its submodules share the same type identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendant node may use that typedef, and it MUST NOT define a typedef with the same name. o All grouping names defined within a parent node or at the top level of the module or its submodules share the same grouping identifier namespace. This namespace is scoped to all descendant nodes of the parent node or module. This means that any descendant node may use that grouping, and it MUST NOT define a grouping with the same name. (§6.2.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-6.2.1-1, so no unit is bound to it.

RFC7950-6.3.1-1

When an imported extension is used, the extension's keyword MUST be qualified using the prefix with which the extension's module was imported. If an extension is used in the module where it is defined, the extension's keyword MUST be qualified with the prefix of this module. The processing of extensions depends on whether support for those extensions is claimed for a given YANG parser or the tool set in which it is embedded. An unsupported extension appearing in a YANG module as an unknown-statement (see Section 14) MAY be ignored in its entirety. Any supported extension MUST be processed in accordance with the specification governing that extension. (§6.3.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-6.3.1-1, so no unit is bound to it.

RFC7950-6.4-1

An implementation is not required to implement an XPath interpreter but MUST ensure that the requirements encoded in the data model are enforced. (Section 6.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-6.4-1, so no unit is bound to it.

RFC7950-6.4-2

The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context (see Section 6.4.1). (§6.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-6.4-2, so no unit is bound to it.

RFC7950-6.5-1

References to identifiers defined in external modules MUST be qualified with appropriate prefixes, and references to identifiers defined in the current module and its submodules MAY use a prefix. (§6.5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): cases unchanged. RFC 6.5: 'References to identifiers defined in external modules MUST be qualified with appropriate prefixes'. Prior judgement, still true: Re-judged 2026-10-09; unchanged cases. Clause 1: ModuleLoadRefused case "external typedef without prefix" (type port with ext imported) requires "unknown type", against Accepted case "prefixed external and bare local" (ext:port and bare local l load). Clause 2 (MAY): Accepted case "extension with own and import prefix" loads m:e under the module's own prefix. The submodule half of the MAY clause is not driven; a MAY imposes no refusal.

RFC7950-7.1.4-1

If there is a conflict, i.e., two different modules that both have defined the same prefix are imported, at least one of them MUST be imported with a different prefix. All prefixes, including the prefix for the module itself, MUST be unique within the module or submodule. (§7.1.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.1.4-1, so no unit is bound to it.

RFC7950-7.3-1

The "typedef" statement's argument is an identifier that is the name of the type to be defined and MUST be followed by a block of substatements that holds detailed typedef information. The name of the type MUST NOT be one of the YANG built-in types. If the typedef is defined at the top level of a YANG module or submodule, the name of the type to be defined MUST be unique within the module. (§7.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.3-1, so no unit is bound to it.

RFC7950-7.3.4-1

The value of the "default" statement MUST be valid according to the type specified in the "type" statement. If the base type has a default value and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. If the type's default value is not valid according to the new restrictions specified in a derived type or leaf definition, the derived type or leaf definition MUST specify a new default value compatible with the restrictions. (§7.3.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. all three sentences, both polarities, isolated by one-statement twins: (1) typedef default in/out of its own range (old pair, records on validateLeafDefaults); (2) a leaf of the typedef with no default carries 5, a narrowing leaf or typedef giving a new default carries 7/8 with no error (record on yangToLeaf); (3) a leaf and a typedef narrowing 1..10 to 6..10 with no new default each refused naming "5" (record on validateTypedefDefault).

RFC7950-7.6.1-1

The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): o If no such ancestor exists in the schema tree, the default value MUST be used. (§7.6.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Both halves of the no-ancestor branch are now tagged: TestRFC7950LeafDefaultUsedWhenAbsent (top-level leaf gets its default) and TestApplyDefaults_NonPresenceContainer (a leaf whose only ancestor is a non-presence container absent from the data: ApplyDefaults creates the container and fills 90/120, both values asserted). Negative TestRFC7950LeafDefaultNotUsedWhenSet (a set value keeps its value) is valid. Observed-red records: applyChildDefault for both RFC units, applyContainerDefault for the non-presence unit.

RFC7950-7.6.1-2

Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree or the case node is the choice's default case, and if no nodes from any other case exist in the data tree. (§7.6.1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. flattenChoiceCases yields the data nodes of every case with no case node left in the schema, so ApplyDefaults fills the defaults of every case whether or not a node of that case exists or it is the default case. Owned by plan/pre-release/spec-config-yang-when-unique-choice.md.

No test carries RFC7950-7.6.1-2, so no unit is bound to it.

RFC7950-7.6.1-3

Otherwise, the default value MUST be used if the ancestor node exists in the data tree. (§7.6.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. §7.6.1 third branch, both polarities on one isolated unit (own schema build and map per subtest). Positive: an existing presence container and an existing list entry each receive their child leaf's default through ApplyDefaults. Negative: with both ancestors absent ApplyDefaults creates neither and the map stays empty. Records: positive on applyContainerDefault (revert); negative on the targeted mutant 'c.Presence' -> 'false' (a presence container treated as non-presence), observed red on the ancestor-absent subtest, so the negative discriminates the rule rather than a panic.

RFC7950-7.6.1-4

In these cases, the default value is said to be in use. Note that if the leaf or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default value is not in use. When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value. (§7.6.1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. ApplyDefaults evaluates no 'when' and no 'if-feature', so a default whose leaf or ancestor has a false 'when' stays in use. Owned by plan/pre-release/spec-config-yang-when-unique-choice.md.

No test carries RFC7950-7.6.1-4, so no unit is bound to it.

RFC7950-7.6.3-1

The "type" statement, which MUST be present, takes as an argument the name of an existing built-in or derived type. (Section 7.6.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): cases unchanged. RFC 7.6.3: 'The "type" statement, which MUST be present, takes as an argument the name of an existing built-in or derived type.' The revert records on Resolve and AddModuleFromText for this row no longer verify (producer/unit changed) and are owed a re-record. Prior judgement, still true: Re-judged 2026-10-09; unchanged cases. MUST be present: ModuleLoadRefused case "leaf without type" refused / Accepted "leaf with type" loads. Names an existing type: TestRFC7950LeafTypeMustNameAnExistingType refuses type nosuch as unknown type against local typedef and imported ext:port twins that differ in the type name alone, with revert records on Resolve.

RFC7950-7.6.4-2

The value of the "default" statement MUST be valid according to the type specified in the leaf's "type" statement. The "default" statement MUST NOT be present on nodes where "mandatory" is "true". The definition of the default value MUST NOT be marked with an "if-feature" statement. (§7.6.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. all three sentences, both polarities: (1) default valid for the type and (2) no default beside mandatory true, by TestRFC7950DefaultInvalidForType/ValidForType on validateLeafDefaults; (3) if-feature on the default's definition, for an enum named directly (TestRFC7950DefaultNotAnIfFeatureEnum) and through a union member enumeration, a bits type and a typedef chain (TestRFC7950DefaultNotAnIfFeatureMemberBitOrTypedef: x / 'b1 b2' / x refused naming the if-feature, y / 'b1' / y load). The union branch was a D-8 defect fixed here: validateDefaultNotIfFeature now follows the first member type that accepts the default (Section 9.12 order); red observed before the fix. Records on validateDefaultNotIfFeature and validateLeafDefaults.

RFC7950-7.7-1

In configuration data, the values in a leaf-list MUST be unique. The definitions of the default values MUST NOT be marked with an "if-feature" statement. Conceptually, the values in the data tree MUST be in the canonical form (see Section 9.1). (§7.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.7-1, so no unit is bound to it.

RFC7950-7.7.2-1

The usage of the default values depends on the leaf-list's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1): o If no such ancestor exists in the schema tree, the default values MUST be used. o Otherwise, if this ancestor is a case node, the default values MUST be used if any node from the case exists in the data tree or the case node is the choice's default case, and if no nodes from any other case exist in the data tree. o Otherwise, the default values MUST be used if the ancestor node exists in the data tree. In these cases, the default values are said to be in use. Note that if the leaf-list or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default values are not in use. When the default values are in use, the server MUST operationally behave as if the leaf-list was present in the data tree with the default values as its values. (§7.7.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.7.2-1, so no unit is bound to it.

RFC7950-7.7.4-1

The value of the "default" statement MUST be valid according to the type specified in the leaf-list's "type" statement. The "default" statement MUST NOT be present on nodes where "min-elements" has a value greater than or equal to one. (§7.7.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: a leaf-list default invalid for its type loading; a leaf-list default beside min-elements >= 1 loading. (b) TestRFC7950DefaultInvalidForType: leaf-list range 1..10 default 30 requires an error containing `default "30" is not valid for type uint8`, and leaf-list min-elements 1 default 1 requires "min-elements 1 is invalid"; positive TestRFC7950DefaultValidForType: leaf-list default 3 inside 1..10 with no min-elements, assert.NoError. min-elements above 1 is not cased separately; 1 is the boundary.

RFC7950-7.7.5-1

A valid leaf-list or list MUST have at least min-elements entries. (Section 7.7.5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: accepting a leaf-list or list with fewer entries than min-elements. (b) TestRFC7950MinElementsViolated: leaf-list with 1 of min 2, absent leaf-list with min 1, and list with 1 of min 2 each require.Len 1 and Contains "too few entries: N (minimum M)"; TestRFC7950MinElementsMet: leaf-list at exactly min 2 and list of 2 above min 1 assert.Empty.

RFC7950-7.8.2-1

The "key" statement, which MUST be present if the list represents configuration and MAY be present otherwise, takes as an argument a string that specifies a space-separated list of one or more leaf identifiers of this list. A leaf identifier MUST NOT appear more than once in the key. Each such leaf identifier MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list or in groupings used in the list. The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. Any "mandatory" statements in the key leafs are ignored. A leaf that is part of the key can be of any built-in or derived type. All key leafs in a list MUST have the same value for their "config" as the list itself. (§7.8.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.8.2-1, so no unit is bound to it.

RFC7950-7.8.3-1

The "unique" statement is used to put constraints on valid list entries. It takes as an argument a string that contains a space- separated list of schema node identifiers, which MUST be given in the descendant form (see the rule "descendant-schema-nodeid" in Section 14). Each such schema node identifier MUST refer to a leaf. If one of the referenced leafs represents configuration data, then all of the referenced leafs MUST represent configuration data. The "unique" constraint specifies that the combined values of all the leaf instances specified in the argument string, including leafs with default values, MUST be unique within all list entry instances in which all referenced leafs exist or have default values. (§7.8.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.8.3-1, so no unit is bound to it.

RFC7950-7.9.2-1

The identifiers of all these child nodes MUST be unique within all cases in a choice. (§7.9.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.9.2-1, so no unit is bound to it.

RFC7950-7.9.3-1

The "default" statement MUST NOT be present on choices where "mandatory" is "true". The default case is only important when considering the "default" statements of nodes under the cases (i.e., default values of leafs and leaf-lists, and default cases of nested choices). The default values and nested default cases under the default case are used if none of the nodes under any of the cases are present. There MUST NOT be any mandatory nodes (Section 3) directly under the default case. (§7.9.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.9.3-1, so no unit is bound to it.

RFC7950-7.9.4-1

If "mandatory" is "true", at least one node from exactly one of the choice's case branches MUST exist. (Section 7.9.4)

Scoped tag-claim records only: tested "at least one node from"; gap "exactly one of the choice's case branches"; internal/component/config/yang/validator_mandatory.go::mandatoryPresent is the boundary: Tested covers a mandatory choice reported missing when no data node of any of its cases exists, and satisfied by a node of one case, nested choices included; Gap is data holding nodes from two cases of one choice, which mandatoryPresent accepts at the first case node it finds, and no other check compares the cases; plan/pre-release/spec-config-yang-when-unique-choice.md; zero whole-requirement credit.

Audit verdict: partial (the tests enforce only the declared tested scope; the whole requirement remains unmet), fresh. Judged 2026-10-12 (independent auditor). Section 7.9.4: "If \"mandatory\" is \"true\", at least one node from exactly one of the choice's case branches MUST exist." Tested "at least one node from"; Gap "exactly one of the choice's case branches"; Producer internal/component/config/yang/validator_mandatory.go::mandatoryPresent. Tested holds: TestMandatoryChoiceSatisfiedByACaseNode reports wrap/kind missing for a container with no node of any case (exact path), and accepts a node of one case and a node of a nested choice's case, so a lookup by the choice name alone, or one that ignores nested choices, goes red; records on mandatoryPresent (positive) and missingMandatory (negative). Real entry: walkTree's mandatory loop reaches it from ValidateCustomSections, so the static route choice action and the iface tunnel encapsulation choice kind are refused when empty. Gap holds: data with nodes from two cases is accepted at the first case node found and no other check compares the cases, so the exactly-one half is unmet; the conditional enforcement under a case or list ancestor in the following paragraph is a separate sentence. Whole requirement earns no credit; spec-config-yang-when-unique-choice.

RFC7950-7.12-1

A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings. If the grouping is defined at the top level of a YANG module or submodule, the grouping's identifier MUST be unique within the module. (§7.12)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.12-1, so no unit is bound to it.

RFC7950-7.14.2-1

If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in an RPC invocation. If a leaf in the input tree has a default value, the server MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the server MUST operationally behave as if the leaf was present in the RPC invocation with the default value as its value. If a leaf-list in the input tree has one or more default values, the server MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the server MUST operationally behave as if the leaf-list was present in the RPC invocation with the default values as its values. Since the input tree is not part of any datastore, all "config" statements for nodes in the input tree are ignored. If any node has a "when" statement that would evaluate to "false", then this node MUST NOT be present in the input tree. (§7.14.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.14.2-1, so no unit is bound to it.

RFC7950-7.14.3-1

If a leaf in the output tree has a "mandatory" statement with the value "true", the leaf MUST be present in an RPC reply. If a leaf in the output tree has a default value, the client MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the RPC reply with the default value as its value. If a leaf-list in the output tree has one or more default values, the client MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the client MUST operationally behave as if the leaf-list was present in the RPC reply with the default values as its values. Since the output tree is not part of any datastore, all "config" statements for nodes in the output tree are ignored. If any node has a "when" statement that would evaluate to "false", then this node MUST NOT be present in the output tree. (§7.14.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.14.3-1, so no unit is bound to it.

RFC7950-7.15-1

An action MUST NOT be defined within an rpc, another action, or a notification, i.e., an action node MUST NOT have an rpc, action, or a notification node as one of its ancestors in the schema tree. For example, this means that it is an error if a grouping that contains an action somewhere in its node hierarchy is used in a notification definition. An action MUST NOT have any ancestor node that is a list node without a "key" statement. (§7.15)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.15-1, so no unit is bound to it.

RFC7950-7.16-1

A notification MUST NOT be defined within an rpc, action, or another notification, i.e., a notification node MUST NOT have an rpc, action, or a notification node as one of its ancestors in the schema tree. For example, this means that it is an error if a grouping that contains a notification somewhere in its node hierarchy is used in an rpc definition. A notification MUST NOT have any ancestor node that is a list node without a "key" statement. Since a notification cannot be defined in a "case" statement, it is an error if a grouping that contains a notification at the top of its node hierarchy is used in a case definition. If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a notification instance. If a leaf in the notification tree has a default value, the client MUST use this value in the same cases as those described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the notification instance with the default value as its value. If a leaf-list in the notification tree has one or more default values, the client MUST use these values in the same cases as those described in Section 7.7.2. In these cases, the client MUST operationally behave as if the leaf-list was present in the notification instance with the default values as its values. (§7.16)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.16-1, so no unit is bound to it.

RFC7950-7.17-1

The target node MUST be either a container, list, choice, case, input, output, or notification node. It is augmented with the nodes defined in the substatements that follow the "augment" statement. The argument string is a schema node identifier (see Section 6.5). If the "augment" statement is on the top level in a module or submodule, the absolute form (defined by the rule "absolute-schema-nodeid" in Section 14) of a schema node identifier MUST be used. If the "augment" statement is a substatement to the "uses" statement, the descendant form (defined by the rule "descendant-schema-nodeid" in Section 14) MUST be used. If the target node is a container, list, case, input, output, or notification node, the "container", "leaf", "list", "leaf-list", "uses", and "choice" statements can be used within the "augment" statement. If the target node is a container or list node, the "action" and "notification" statements can be used within the "augment" statement. If the target node is a choice node, the "case" statement or a shorthand "case" statement (see Section 7.9.2) can be used within the "augment" statement. The "augment" statement MUST NOT add multiple nodes with the same name from the same module to the target node. If the augmentation adds mandatory nodes (see Section 3) that represent configuration to a target node in another module, the augmentation MUST be made conditional with a "when" statement. (§7.17)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.17-1, so no unit is bound to it.

RFC7950-7.18.2-1

If a prefix is present on the base name, it refers to an identity defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule. An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities. (§7.18.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.18.2-1, so no unit is bound to it.

RFC7950-7.19-1

Syntactically, the substatements MUST be YANG statements, including extensions defined using "extension" statements. YANG statements in extensions MUST follow the syntactical rules in Section 14. (§7.19)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): only the ModuleLoadAccepted tail changed. RFC 7.19: 'the substatements MUST be YANG statements, including extensions defined using "extension" statements.' The earlier finding that sources was keyed by file name no longer holds at HEAD: sourcedModules.texts is keyed by *yang.Module (Parse binds each module added by a parse to its text). Revert records on AddModuleFromText for the ModuleLoadAccepted/Refused tags are owed a re-record. Prior judgement, still true: Re-judged 2026-10-09 after 6c06cb43af/037cc25e29. Sentence 1: TestRFC7950ExtensionUsageSubstatementsAreYANGStatements refuses m:e "x" { bogus "y"; } against description and nested m:e twins. Sentence 2 (Section 14 rules) now whole: substatements are resolved against the embedded RFC ABNF (resolveProduction) and checked for argument grammar (config maybe, namespace not a URI, path a / ../a[), cardinality (two type, two description; one type + two must loads), required substatements and blocks (leaf without type, list without data-def, refine with no block) and context forms (deviate add/not-supported mixing, type-body alternatives, augment absolute vs descendant), each tagged test with a revert record on its producer. Independent probe 2026-10-09 of ~70 valid unusual forms under a usage (quoted/unquoted/single-quoted args, + concatenation, nested usages at depth, leafref require-instance, multiple leaf-list defaults, deviate add/replace/delete in full, if-feature expressions with extra whitespace, path predicates with WSP, IPv6/percent URIs, refine across comments/newlines/tabs/UTF-8/CRLF, nested module/submodule) all load; config TRUE, max-elements 0/007, fraction-digits 19, deref() path, refine x; via comment or concatenation, empty input/augment are refused. The ModuleLoadRefused/Accepted tags drive the extension DEFINITION (extension e { bogus }), governed by the Section 14 extension-stmt rule, a neighbouring rule; their claims state what the body checks but do not bear on this sentence.

RFC7950-7.20.1-1

A feature MUST NOT reference itself, neither directly nor indirectly through a chain of other features. In order for a server to support a feature that is dependent on any other features (i.e., the feature has one or more "if-feature" substatements), the server MUST also support all the dependent features. (§7.20.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.20.1-1, so no unit is bound to it.

RFC7950-7.20.2-1

If a prefix is present on a feature name in the boolean expression, the prefixed name refers to a feature defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, a feature with the matching name MUST be defined in the current module or an included submodule. A leaf that is a list key MUST NOT have any "if-feature" statements. (§7.20.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.20.2-1, so no unit is bound to it.

RFC7950-7.20.3-1

This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards. Server deviations are strongly discouraged and MUST only be used as a last resort. Telling the application how a server fails to follow a standard is no substitute for implementing the standard correctly. A server that deviates from a module is not fully compliant with the module. However, in some cases, a particular device may not have the hardware or software ability to support parts of a standard module. When this occurs, the server makes a choice to either treat attempts to configure unsupported parts of the module as an error that is reported back to the unsuspecting application or ignore those incoming requests. Neither choice is acceptable. Instead, YANG allows servers to document portions of a base module that are not supported, or that are supported but with different syntax, by using the "deviation" statement. After applying all deviations announced by a server, in any order, the resulting data model MUST still be valid. (§7.20.3)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.20.3-1, so no unit is bound to it.

RFC7950-7.20.3.2-1

The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node. The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node. (§7.20.3.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.20.3.2-1, so no unit is bound to it.

RFC7950-7.21.2-1

If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module. (§7.21.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.21.2-1, so no unit is bound to it.

RFC7950-7.21.5-1

A leaf that is a list key MUST NOT have a "when" statement. If a key leaf is defined in a grouping that is used in a list, the "uses" statement MUST NOT have a "when" statement. (§7.21.5)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-7.21.5-1, so no unit is bound to it.

RFC7950-8.1-1

These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a valid state data tree. o If the constraint is defined on notification content, it MUST be true in any notification data tree. o If the constraint is defined on RPC or action input parameters, it MUST be true in an invocation of the RPC or action operation. o If the constraint is defined on RPC or action output parameters, it MUST be true in the RPC or action reply. (§8.1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. Section 8.1: "If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree." ValidateCustomSections now runs the full walk over validatedSections, mandatoryFailures over every other top-level section the compiled schema declares that is present in the config (Validator.Sections), and bgpMandatoryFailures over the bgp global level; LoadConfig, ze config validate, the web editor commit and the SSH editor commit (cli ConfigValidator.sectionErrors) all reach it. The walk now covers every present section for mandatory, but walkTree still evaluates no unique (ze-iface-conf declares unique "mac/address" and "mac/match"), no choice exclusivity and no when, and skips data under a case, so a configuration violating those constraints is accepted. Owned by spec-config-yang-when-unique-choice.

No test carries RFC7950-8.1-1, so no unit is bound to it.

RFC7950-8.1-3

All leaf data values MUST match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties. (§8.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. SHIFTED only: the tagged units are byte-identical (gate-verified). range: receive-hold-time 2 and port 0 refused ErrTypeRange, 1 and 2 refused and 0, 3, 180, 65535 accepted; pattern: router-id not-an-ip refused ErrTypePattern at errs[0] with session/asn/local supplied so no missing-mandatory error comes first, 192.0.2.1 accepted; length: a 256-char isis hostname refused ErrTypeLength and a within-length one raises no length error. The validateString record on TestValidateTree_PatternViolation is current again (no stale record). Base-type conformance is carried by the Section 9 rows. Re-run green 2026-10-12. Verdict stands.

RFC7950-8.1-4

All key leafs MUST be present for all list entries. o Nodes MUST be present for at most one case branch in all choices. o There MUST be no nodes tagged with "if-feature" present if the "if-feature" expression evaluates to "false" in the server. o There MUST be no nodes tagged with "when" present if the "when" condition evaluates to "false" in the data tree. The following properties are true in a valid data tree: o All "must" constraints MUST evaluate to "true". o All referential integrity constraints defined via the "path" statement MUST be satisfied. o All "unique" constraints on lists MUST be satisfied. o The "mandatory" constraint is enforced for leafs and choices, unless the node or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false". (§8.1)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. Section 8.1 bullets: "Nodes MUST be present for at most one case branch in all choices." and "All \"unique\" constraints on lists MUST be satisfied." walkTree still evaluates neither: mandatoryPresent accepts a choice at the first case node and nothing compares cases, and the unique statements ze-iface-conf declares are read by no check. Ze modules carry no when or if-feature today, so those bullets have no live instance, and walkTree evaluates neither. Owned by spec-config-yang-when-unique-choice.

No test carries RFC7950-8.1-4, so no unit is bound to it.

RFC7950-8.1-2

The running configuration datastore MUST always be valid. (Section 8.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 9d4a5e79e2). Section 8.1: "The running configuration datastore MUST always be valid." The earlier finding (only config.LoadConfig was driven; no install route) is answered for the reload route: TestRFC7950ReloadInstallsAValidConfig and TestRFC7950ReloadRefusesAConstraintViolation write the file and drive diskConfigLoaders and doReload, the path every SIGHUP and editor reload notifier reaches, and assert the refused reload returns ErrCustomValidation naming the value while the reactor keeps system/host reload-valid-host. TestRFC7950WebCommitRefusesAConstraintViolation shows the web editor commit writes nothing for the same violation. Startup stays covered by the LoadConfig units. Residual: the SSH session editor (session_editor.go) sets no pre-commit validator, so its commit relies on the reload refusal the reload units prove; no tagged unit drives that editor, and none drives the gNMI/API configValidationHook route.

RFC7950-8.3-1

For configuration data, there are three windows when constraints MUST be enforced: o during parsing of RPC payloads o during processing of the <edit-config> operation o during validation (§8.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 9d4a5e79e2). Section 8.3: "For configuration data, there are three windows when constraints MUST be enforced": parsing, processing of <edit-config>, and validation. Parse and whole-tree validation stay proven through LoadConfig (TestRFC7950RunningDatastoreRefusesAViolationAtParse, ...AfterParse). The earlier finding (edit-processing window untested) is answered for the web editor: TestRFC7950WebCommitWritesAValidEdit (SetValue, CommitNow, file carries the edit) and TestRFC7950WebCommitRefusesAConstraintViolation (a value the YANG type accepts and the internal-plugin ze:validate rule refuses: CommitNow errors naming the value and the file is byte-identical), driven through newEditorFactory(ValidateContent), the factory service_web.go installs. Residual: the SSH CLI editor commit, which carries no pre-commit validator and is refused only at reload, and the gNMI/API session commit are not driven by a tagged unit.

RFC7950-8.3.1-2

If data for more than one case branch of a choice is present, the server MUST reply with a "bad-element" <error-tag> in the <rpc-error>. o If data for a node tagged with "if-feature" is present and the "if-feature" expression evaluates to "false" in the server, the server MUST reply with an "unknown-element" <error-tag> in the <rpc-error>. o If data for a node tagged with "when" is present and the "when" condition evaluates to "false", the server MUST reply with an "unknown-element" <error-tag> in the <rpc-error>. (§8.3.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-8.3.1-2, so no unit is bound to it.

RFC7950-8.3.2-1

During this processing, the following errors MUST be detected: o Delete requests for non-existent data. o Create requests for existent data. o Insert requests with "before" or "after" parameters that do not exist. o Modification requests for nodes tagged with "when", and the "when" condition evaluates to "false". In this case, the server MUST reply with an "unknown-element" <error-tag> in the <rpc-error>. (§8.3.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-8.3.2-1, so no unit is bound to it.

RFC7950-8.3.3-1

When datastore processing is complete, the final contents MUST obey all validation constraints. (§8.3.3)

Audit verdict: weak (the tests pass over code that does not enforce the requirement), fresh. Row narrowed 2026-09-30 to the first sentence. The tags prove LoadConfig refuses a ze:validate violation with ErrCustomValidation and no partial tree, and accepts a valid config. "All validation constraints" is not met by the stack: a missing mandatory leaf is only a warning (SectionValidationError.Blocking), and when, unique and choice are evaluated nowhere, so a final datastore content violating those is accepted. Owner ruling 4: carried by spec-config-yang-when-unique-choice AC-2.

RFC7950-8.3.3-2

If the datastore is "running" or "startup", these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation. (§8.3.3)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-18 (independent auditor, after 2e4be94ae3). Read at rfc/full/rfc7950.txt Section 8.3.3: "If the datastore is "running" or "startup", these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation." The constraints are the Section 8.1 list, which includes "Nodes MUST be present for at most one case branch in all choices." 2e4be94ae3 closes the SSH editor hole the prior judgement named: sectionErrors now keeps a bgp failure whose type is ErrTypeReference (editorReportsSectionFailure, unit-tested by TestEditorReportsSectionFailure only, as no bgp module declares a leafref yet), and referenceFailures walks tree.ToPluginMap() so a positional instance-identifier counts in list order. Still unmet at every surface (LoadConfig, ze config validate, web and SSH editor commits through ValidateCustomSections): no evaluation of when, unique (declared in ze-iface-conf, ze-bgp-conf and ze-healthcheck-conf; config.ListNode.Unique is read only by the web fragment for display) or choice exclusivity. An overlay probe shows the missing exclusivity check leaking into the reference walk: with nodes in two cases of one choice, a leafref to the default of one case was accepted in 174 of 200 runs and refused in 26 (activeBranch ranges over choice.Dir, a map). The row's {gap} still names the plan spec-config-yang-when-unique-choice.md, which exists.

No test carries RFC7950-8.3.3-2, so no unit is bound to it.

RFC7950-9.1-1

Implementations MUST support all lexical representations specified in this document. (§9.1)

Audit verdict: enforced (the tests do what the requirement demands), stale-unit: internal/component/config/yang/validator_instance.go::instanceExists, internal/component/config/yang/validator_reference.go::readEqualsQuoted, internal/component/config/yang/validator_reference.go::readInstancePredicates moved. Re-judged 2026-10-18 (independent auditor, after 8a404499d5). Read at rfc/full/rfc7950.txt Section 9.1: "Implementations MUST support all lexical representations specified in this document." The prior weak verdict's only reason was the unproven instance-identifier leaf-list-predicate form (Section 14: "leaf-list-predicate-expr = \".\" *WSP \"=\" *WSP quoted-string"; Section 9.13.4 example "/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']"). TestRFC7950InstanceIdentifierLeafListPredicate now asserts [.='blue'] and the spaced double-quoted [ . = "blue" ] are accepted by validateLeafValue and by ValidateReferences (the call validate_sections.go makes on every config validate/commit), and TestRFC7950InstanceIdentifierLeafListPredicateAbsent asserts [.='green'] parses yet is refused as absent; both claims state exactly what the bodies assert. Targeted overlay mutants (tags ze_core ze_bgp), beyond the recorded whole-body halts: disabling the '.' branch of readInstancePredicates reddened both tests; dropping the *WSP skip in readEqualsQuoted reddened the positive (spaced form); making instanceExists answer true for any leaf-list predicate value reddened the negative. All 14 tagged units pass at HEAD in both packages. The units carried from the prior judgement (hex/octal and signed integers, decimal64, binary, bits, leafref lexical, union default via leafref member) still stand. Observed, not denying this row: a present leaf-list or list key is matched against the predicate value as raw text (instanceExists slices.Contains, instanceKeysMatch), while an absent default is matched canonically (absentLeafInUse canonicalValue), so for uint8 [.='+17'] matches a default 17 but not a configured 17 (overlay probe); one of the two paths is wrong and they should agree.

RFC7950-9.2.4-2

If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a range restriction is applied to a type that is already range-restricted, the new restriction MUST be equally limiting or more limiting, i.e., raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. Each explicit value and range boundary value given in the range expression MUST match the type being restricted or be one of the special values "min" or "max". (§9.2.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.2.4-2, so no unit is bound to it.

RFC7950-9.3.1-1

A decimal64 value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits. (§9.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 2e4be94ae3). Read at rfc/full/rfc7950.txt Section 9.3.1: "A decimal64 value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits." The units changed only from validateYangType to ValidateType, which is the same producer path (validateLeafValue with no leaf). validateDecimal64 tests ^[+-]?\d+(\.\d+)?$ (ASCII digits in Go RE2) before the fraction-digits parse. Positive accepts +1.5, -1.5, -10.5, 1, 0.25, 0.0, 10.50; negative refuses .5, 1., +, -, 1.2.3, abc and the empty string with ErrTypeType and 'expected decimal64', with fraction-digits and range refusals asserted as distinct kinds. Each clause of the sentence has a value that would flip if the regexp lost it; records on validateDecimal64 replay.

RFC7950-9.3.4-1

The "fraction-digits" statement, which is a substatement to the "type" statement, MUST be present if the type is "decimal64". (Section 9.3.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): cases unchanged. RFC 9.3.4: 'The "fraction-digits" statement, which is a substatement to the "type" statement, MUST be present if the type is "decimal64".' Prior judgement, still true: Re-judged 2026-10-09; unchanged cases. Negative: ModuleLoadRefused case "decimal64 without fraction-digits" (type decimal64; only fault) requires an error containing "[1..18]". Positive: case "decimal64 with fraction-digits" (2) loads. The twins differ in the fraction-digits statement alone.

RFC7950-9.4.4-1

Length-restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. (§9.4.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): cases unchanged. RFC 9.4.4: 'If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order.' Prior judgement, still true: Re-judged 2026-10-09; the earlier weak (min/max read as 0 and 2^64-1, and a one-part 5..1 tagged as parts out of order) is fixed. Non-negative: "-1..5" refused. Ascending: ModuleLoadRefused now drives "10..20 | 1..5", and TestRFC7950LengthPartsDisjointAndAscending refuses it and overlapping "1..5 | 3..8" (goyang coalesces both, so the refusal is checkStructure) against "0..5 | 10..20". min/max: TestRFC7950LengthMinMaxAreTheRestrictedTypeBounds refuses "min | 2" and "10 | max" over typedef length 2..10 against "min..4 | 6..max" and "min..max"; revert records on both structural tests. Probe 2026-10-09: touching "1..5 | 5..10" and "max | max" refused, adjacent "1..5 | 6..10" and "min | max" load; min/max follow a two-level typedef chain and a typedef with no length of its own; a union member's length is checked.

RFC7950-9.5.1-1

The lexical representation of a boolean value is a string with a value of "true" or "false". These values MUST be in lowercase. (§9.5.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 2e4be94ae3). Read at rfc/full/rfc7950.txt Section 9.5.1: "The lexical representation of a boolean value is a string with a value of "true" or "false". These values MUST be in lowercase." The units changed only from validateYangType to ValidateType, the same producer path. validateBoolean accepts exactly "true" and "false"; the negative requires ErrTypeType 'expected boolean' for True, FALSE, TRUE, yes and 1, so a case-folding comparison would turn it red. Ze's config spelling enable/disable is rewritten by NormalizeBool (case-sensitive) before the validator, and TestBooleanConfigSpellingRefused pins that the validator itself refuses them.

RFC7950-9.6.4-1

The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string that is the assigned name. The string MUST NOT be zero-length and MUST NOT have any leading or trailing whitespace characters (any Unicode character with the "White_Space" property). The use of Unicode control codes SHOULD be avoided. The statement is optionally followed by a block of substatements that holds detailed enum information. All assigned names in an enumeration MUST be unique. (§9.6.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.6.4-1, so no unit is bound to it.

RFC7950-9.6.4-2

When an existing enumeration type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The value of such an assigned name MUST NOT be changed. (§9.6.4)

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.6.4.2-1

This integer value MUST be in the range -2147483648 to 2147483647, and it MUST be unique within the enumeration type. If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value (i.e., the highest enum value, implicit or explicit, prior to the current "enum" substatement in the parent "type" statement). Note that the presence of an "if-feature" statement in an "enum" statement does not affect the automatically assigned value. If the current highest value is equal to 2147483647, then an enum value MUST be specified for "enum" substatements following the one with the current highest value. When an existing enumeration type is restricted, the "value" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type. (§9.6.4.2)

Audit verdict: weak (the tests pass over code that does not enforce the requirement), fresh. Re-judged 2026-10-09 after 180df07922 (only the ModuleLoadAccepted tail changed; cases unchanged) over the goyang fork, now committed in 66e87707f5 (go.mod replace github.com/ze-software/goyang v1.6.4-0.20261009101552-a3cf525c4f98, upstream PR openconfig/goyang#317). The STACK now meets the sentence 'otherwise, the assigned value is one greater than the current highest enum value': vendored EnumType.Set sets last on the first assignment or any higher value (len(e.ToInt) == 0 || value > e.last), so SetNext after an explicit -5 yields -4, and Loader.Resolve (goyang Modules.Process) no longer refuses enumeration { enum p { value -5; } enum q; enum r { value 0; } }. Ze's own producer (assignEnumValues) is unchanged and its tags still discriminate: TestRFC7950EnumImplicitValueFollowsTheHighest pins -4 after -5, 11 after 10 then 3, if-feature counted (2), two typedef levels down, each refused twin differing only in the value; TestRFC7950EnumValueRangeAndUniqueness refuses with ErrEnumValue an implicit value past 2147483647 and an explicit repeat of the implicit -4. Both tags' claims state only what their bodies assert, and the edited comments now say only true things (goyang v1.6.3 history, Ze's own refusals). Still weak: the module that proves the stack fix is exercised only by TestGoyangNumbersAnEnumAfterANegativeValue, which carries no RFC requirement tag, and every tagged positive sidesteps the defect (uniqueness positive uses r value -3; the implicit positives restate q -4 in a restriction goyang builds afresh). Under goyang v1.6.3 every tagged unit stays green (TestGoyangNumbersAnEnumAfterANegativeValue still carries no tag and the uniqueness positive still uses r value -3), so dropping the replace at the next goyang bump (which the go.mod comment plans) reddens no tagged test. Owed to reach enforced: tag that module as a positive of this requirement (or change the uniqueness positive's r to value 0) and record its discrimination against the reverted Set.

RFC7950-9.7-1

When an existing bits type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The bit position of such an assigned name MUST NOT be changed. (§9.7)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.7-1, so no unit is bound to it.

RFC7950-9.7.4-1

The "bit" statement, which is a substatement to the "type" statement, MUST be present if the type is "bits". It is repeatedly used to specify each assigned named bit of a bits type. It takes as an argument a string that is the assigned name of the bit. It is followed by a block of substatements that holds detailed bit information. The assigned name follows the same syntax rules as an identifier (see Section 6.2). All assigned names in a bits type MUST be unique. (§9.7.4)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.7.4-1, so no unit is bound to it.

RFC7950-9.7.4.2-1

The position value MUST be in the range 0 to 4294967295, and it MUST be unique within the bits type. If a bit position is not specified, then one will be automatically assigned. If the "bit" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest bit position (i.e., the highest bit position, implicit or explicit, prior to the current "bit" substatement in the parent "type" statement). Note that the presence of an "if-feature" statement in a "bit" statement does not affect the automatically assigned position. If the current highest bit position value is equal to 4294967295, then a position value MUST be specified for "bit" substatements following the one with the current highest position value. When an existing bits type is restricted, the "position" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type. (§9.7.4.2)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.7.4.2-1, so no unit is bound to it.

RFC7950-9.9-1

If the "require-instance" property (Section 9.9.3) is "true", there MUST exist a node in the data tree, or a node with a default value in use (see Sections 7.6.1 and 7.7.2), of the referred schema tree leaf or leaf-list node with the same value as the leafref value in a valid data tree. If the referring node represents configuration data and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration. There MUST NOT be any circular chains of leafrefs. If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.20.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features. (§9.9)

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.9.2-1

The "path" statement, which is a substatement to the "type" statement, MUST be present if the type is "leafref". It takes as an argument a string that MUST refer to a leaf or leaf-list node. The syntax for a path argument is a subset of the XPath abbreviated syntax. Predicates are used only for constraining the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 14. The predicates are only used when more than one key reference is needed to uniquely identify a leaf instance. This occurs if a list has multiple keys or a reference to a leaf other than the key in a list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together. The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the "require-instance" property is "true", this node set MUST be non-empty. (§9.9.2)

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.9.3-1

If "require-instance" is "true", it means that the instance being referred to MUST exist for the data to be valid. (Section 9.9.3)

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.10.2-1

The "base" statement, which is a substatement to the "type" statement, MUST be present at least once if the type is "identityref". The argument is the name of an identity, as defined by an "identity" statement. If a prefix is present on the identity name, it refers to an identity defined in the module that was imported with that prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule. (§9.10.2)

Scoped tag-claim records only: tested "If a prefix is present on the identity name, it refers to an identity defined in the module that was imported with that prefix"; gap "MUST be present at least once"; internal/component/config/yang/validator_reference.go::validateIdentityref is the boundary: Tested covers an identityref with one base, prefixed by an imported module's prefix or local, resolved by goyang (which refuses an identityref with no base or a base it cannot resolve), whose value must name an identity derived from it; Gap is a type naming the base statement more than once, because goyang keeps one base statement per identityref type (Type.IdentityBase holds one value), so the values derived from every base are not computed; plan/spec-config-yang-reference-types.md; zero whole-requirement credit.

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.10.3-1

Otherwise, an identity with the matching name MUST be defined in the current module or one of its submodules. (Section 9.10.3)

Audit verdict: not audited: no reader has judged these tests

RFC7950-9.12-2

When the type is "union", the "type" statement (Section 7.4) MUST be present. (Section 9.12)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-9.12-2, so no unit is bound to it.

RFC7950-9.13-1

For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. If a key is of type "empty", it is represented as a zero-length string (""). If the leaf with the instance-identifier type represents configuration data and the "require-instance" property (Section 9.9.3) is "true", the node it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All such leaf nodes MUST reference existing nodes or leaf or leaf-list nodes with their default value in use (see Sections 7.6.1 and 7.7.2) for the data to be valid. (§9.13)

Audit verdict: not audited: no reader has judged these tests

RFC7950-11-1

For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. If there are no existing "revision" statements, then one MUST be added to identify the new revision. Furthermore, any necessary changes MUST be applied to any metadata statements, including the "organization" and "contact" statements (Sections 7.1.7 and 7.1.8). Note that definitions contained in a module are available to be imported by any other module and are referenced in "import" statements via the module name. Thus, a module name MUST NOT be changed. Furthermore, the "namespace" statement MUST NOT be changed, since all XML elements are qualified by the namespace. Obsolete definitions MUST NOT be removed from published modules, since their identifiers may still be referenced by other modules. (§11)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-11-1, so no unit is bound to it.

RFC7950-11-2

Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. (§11)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-11-2, so no unit is bound to it.

RFC7950-11-3

In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered. (§11)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. {gap} stands, re-judged 2026-10-09 after 180df07922: LoadEmbedded only gained the refuseLoad guard and still parses ze-extensions.yang and ze-types.yang with no comparison against a previous revision, so a reordering of data definition substatements passes. RFC 11: 'In statements that have any data definition statements as substatements, those data definition substatements MUST NOT be reordered.' Recorded under OWNER RULING 4 (2026-09-30), not closed.

No test carries RFC7950-11-3, so no unit is bound to it.

RFC7950-7.2.2-1

A submodule MUST only be included by either the module to which it belongs or another submodule that belongs to that module. (§7.2.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after bb173975ea). Read at rfc/full/rfc7950.txt Section 7.2.2: "A submodule MUST only be included by either the module to which it belongs or another submodule that belongs to that module." Producer: checkStructure (joined by Resolve) runs moduleIncludeErrors over every loaded module and submodule (sourceModules); it resolves the including unit's owner (its own name, or its belongs-to) and refuses an include whose submodule belongs to another module with ErrIncludeBelongsTo. TestRFC7950SubmoduleIncludedOnlyByItsModule covers both clauses in both polarities: negatives refuse module a including s (belongs-to b) and submodule a-s of a including s, each requiring the text "belongs to module b"; positives load module a including a-t and a-s including sibling a-t. Module b is loaded and includes s in the negatives, so only the belongs-to differs. Independent overlay mutants (tags ze_core ze_bgp), each red on an assertion: owner ignores belongs-to (submodule-sibling positive red), modules skipped (submodule negative red), submodules skipped (module negative red), comparison always passes (both negatives red), comparison always fails (both positives red). Two equivalent-in-test mutants survive: dropping either lookup in includedSubmodule (include.Module, or the SubModules map fallback) leaves the test green because the other still finds the submodule; the redundancy changes no verdict but no test proves the fallback is needed. The recorded revert tuples (panic in moduleIncludeErrors) prove reach only. {gap} removed from the row in bb173975ea; Ze ships no submodule of its own, so the check guards loaded module sets.

RFC7950-7.3.2-1

The "type" statement, which MUST be present, defines the base type from which this type is derived. (§7.3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-09 after 180df07922 (Resolve returns *yang.Resolved, one Resolve per Loader; process, checkExtensions, checkPatterns, checkStructure still all run and join, refusals unchanged): the positive now reads the leaf from schema.GetEntry of the returned Resolved, same assertion (Yuint8). RFC 7.3.2: 'The "type" statement, which MUST be present, defines the base type from which this type is derived.' negative: a typedef with only a description refused; positive: the same typedef with type uint8 loads and the leaf using it resolves to Yuint8 (proves the type defines the base type). Twins differ by the type statement alone, so the loose "type" substring cannot be met by another fault. Records on Resolve. Those Resolve revert records no longer verify (unit-changed) and are owed a re-record.

RFC7950-7.9.2-2

The case identifier MUST be unique within a choice. (§7.9.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. negative: two cases named x in one choice refused as duplicate; positive: cases x and y load, and case x in two different choices loads, which pins the scope to one choice. Records on Resolve. (2026-10-09: tagged units byte-identical, re-stamped for a file shift; the Resolve revert records no longer verify since 180df07922 changed Resolve, re-record owed.)

RFC7950-7.21.5-2

If the XPath expression references any node that also has associated "when" statements, those "when" expressions MUST be evaluated first. There MUST NOT be any circular dependencies among "when" expressions. (§7.21.5)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-12, second pass (independent auditor) after 60a74fc04b, 600996fb77, 975428e1b3, 3f1bec74f0 and 84382339ce. Section 7.21.5: "There MUST NOT be any circular dependencies among \"when\" expressions." walkTree's changes (mandatory descent, choice message) add no when evaluation, so neither the evaluation order nor the cycle rule is applied; Ze's modules declare no when today. {gap} under owner ruling 4, recorded, not closed.

No test carries RFC7950-7.21.5-2, so no unit is bound to it.

RFC7950-9.1-2

If the data type does not have a canonical form, the format of the value MUST match the data type's lexical representation, but the exact format is implementation dependent. (§9.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 2e4be94ae3). Read at rfc/full/rfc7950.txt Section 9.1: "If the data type does not have a canonical form, the format of the value MUST match the data type's lexical representation, but the exact format is implementation dependent." The types are identityref (Section 9.10.4) and instance-identifier (Section 9.13.3). Both prior findings are fixed. (1) Section 9.13.2 "All node names in an instance-identifier value MUST be qualified with explicit namespace prefixes": checkInstanceKeyPrefix now refuses an unprefixed or foreign key prefix; TestRFC7950InstanceIdentifierKeyPrefix (negative) asserts both messages and the accepted rf:name form, and overlay mutants dropping the empty-prefix branch and the entryPrefixed branch each turned it red. (2) Cascade confounding: TestRFC7950IdentityrefFormat now asserts the format check's own message, and TestRFC7950InstanceIdentifierLexical asserts 'not an instance-identifier' for rf:sys and the unprefixed-node message for /sys/mgmt; overlay mutants removing the identifierRefLength check and the leading-slash check turned each red. A probe of further malformed values (rf:1aes, rf:, :aes, trailing space, //rf:sys, an unquoted key value, [0], mismatched and embedded quotes, a space between steps) found each refused with ErrTypeType.

RFC7950-9.4.4-2

If a length restriction is applied to a type that is already length-restricted, the new restriction MUST be equally limiting or more limiting, i.e., raising the lower bounds, reducing the upper bounds, removing explicit length values or ranges, or splitting ranges into multiple ranges with intermediate gaps. (§9.4.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. negative: widening a typedef's length 2..5 to 1..10 refused naming length; positive: equal 2..5, narrowed 3..4, and split 2..3 | 5..5 load, covering the allowed restriction kinds. Records on Resolve. (2026-10-09: tagged units byte-identical, re-stamped for a file shift; the Resolve revert records no longer verify since 180df07922 changed Resolve, re-record owed.)

RFC7950-12-1

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule, and a YANG version 1 module MUST NOT include a YANG version 1.1 submodule. A YANG version 1 module or submodule MUST NOT import a YANG version 1.1 module by revision. (§12)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC7950-12-1, so no unit is bound to it.

Extraction sign-off

Sections

Excluded sentences