SWV-44 says 'rivet validate mechanically enforces' the traceability backlinks — no workflow runs it, and it warns rather than fails

[avrabe]

This is the requirement that underwrites the traceability argument itself, and it is the fourth instance this month of a gate that exists and cannot fail.

The claim

SWV-44:

Verifies SR-44 by static analysis: rivet validate mechanically enforces that every sw-req carries a typed sw-verification backlink (the ASPICE SWE tier, ADR-5). The passing gate is itself the verification measure.

Three ways it does not hold

1. No workflow runs rivet validate.

$ grep -rn "rivet" .github/workflows/
release-readiness.yml:  ... rivet release status "$TARGET"
compliance.yml:         ... (on: release: types: [published])

release-readiness.yml runs rivet release status, a different command. compliance.yml is a post-publish report generator, not a gate. There is no passing gate to be the verification measure.

2. It would not fail if it did run. The auditor performed a negative control — copied the project to a scratch dir, deleted the SWV-32 block, re-ran:

WARN: [SR-32] Every SW requirement should be verified by at least one verification measure …
exit 0        Result: PASS

The missing backlink is a warning. --fail-on warning exists and is used nowhere.

3. SR-44's own acceptance criterion is unmet. It reads: "Done when rivet validate is error-free and rivet coverage reports requirement-coverage > 0% with every SR linked by verifies to a test artifact." Current: 5 of 89 (5.6%) — only SR-64, SR-68, SR-72, SR-73, SR-74 carry in-code markers.

Why I take this one personally

I have filed three variants of this in three weeks: the #304 INVARIANT comment that asserted a guard nothing enforced (#390), the MANDATORY release-readiness query no machine ran (#395), and MC/DC pointed at the wrong artifact (#397). Each time the fix was to make the check mechanical.

This is the one that says it already is mechanical — and that claim is doing the work of the enforcement it describes.

Suggested fix

1. Run it. A rivet validate --fail-on warning step in CI. Cheap, and it is what SWV-44 already claims exists.
2. Expect it to go red immediately — Several SRs are 'verified' on evidence weaker than the requirement — placeholder proofs and existence-only tests #410 and Evidence citations name four nonexistent tests — three of them name invariants the code now asserts the opposite of #411 are exactly the class it would catch, and the 12 self-contradictory SWVs below are mechanically detectable.
3. Fix the claim either way. If --fail-on warning is too strict to adopt today, SWV-44 must stop saying "mechanically enforces" and say what is actually true: that the backlinks are maintained by convention and checked by hand.

Related record hygiene, mechanically detectable

• 12 SWVs contradict themselves. SWV-54 through SWV-65 each say "status closed implemented -> verified" in prose while status: implemented. (grep -c → 12.)
• traceability.yaml claims to be "the authoritative record of traceability" and covers SR-1..SR-41 only; SR-42..SR-74 are absent — 33 requirements, 32 of them verified, spanning v0.37.0 to v0.55.0. Last updated 2026-06-11.
• Six verified, released SRs (SR-58, 60, 61, 62, 63, 64) still open their verification-description with PROPOSED. in future tense. The evidence does exist — in the paired SWV — so this is stale text, not missing work. One residual: SR-58's future-tense fail-loud guard is implemented (fact.rs:6925-6938) but no test pins it.
• SR-40 is verified on a Kani run performed locally on one date by one person, with no gate reproducing it. Self-disclosed in the text, invisible in the status field.
• No sw-verification carries a release: field (0 vs 31 on SRs), so rivet release status — the gate that is required — never scopes a verification measure into its check.

Each of these is a grep. That is the point: a validator that ran would find them.