FR: validation severity levels + suppressions — so a check can be an error without convicting the innocent

[dmealing]

Gap

Validation findings are errors or warnings, with no severity grading and no suppression mechanism.

That gap has already forced at least two design compromises:

1. Requirement object-coverage shipped as a WARNING deliberately — because on a real repo carrying one requirement it reports ~93 unclaimed entities, so promoting it to an error would fail a project's first verify. With suppressions it could be an error with recorded, reviewable opt-outs, which is strictly more useful than a warning everyone learns to ignore.
2. @verifiedBy convention detection (0.23.1) hit the same shape — an unrecognised test convention had to WARN rather than convict, because there was no way for a project to say "this is fine, here's why."

The pattern: when a check cannot be suppressed, the only way to avoid false convictions is to weaken it for everyone.

Prior art (open source)

Smithy grades validation events NOTE / WARNING / DANGER / ERROR and supports per-finding suppressions. https://smithy.io/2.0/guides/smithy-build-json.html

Notes

• Suppressions should carry a reason, so they are reviewable rather than a silencer.
• Cross-port: severity and suppression semantics must be identical in all five ports, so this needs conformance fixtures.
• Related: Config-driven metadata validation — checks as data, one engine per port (write-once across 5 languages) #51 (config-driven metadata validation — checks as data). These are complementary — Config-driven metadata validation — checks as data, one engine per port (write-once across 5 languages) #51 is about declaring checks, this is about grading and suppressing their findings.