Check reference

Review semantic catalog suggestions

Semantic similarity can suggest an overlooked obligation, but a score cannot decide whether it belongs in a requirement. This check makes the disposition of recorded suggestions visible.

What the check observes

The check reads proof/catalog/semantic-scan.json and the current requirement records. Each flagged requirement/class pair must be bound in the live obligation checklist or have a semantic rejection with decision rejected and a trimmed reason of at least 16 characters. The scan's saved declaration snapshot is provenance, not a substitute for current state. The check itself computes no embeddings.

Example: a binding was removed after the scan

Illustrative case. A scan once found a rate-limit obligation already bound to SYS-REQ-042. Later that checklist entry was removed. The old scan snapshot cannot keep the suggestion resolved; the live requirement needs a valid disposition.

# Requirement excerpt, only if the class truly does not apply
semantic_rejections:
  - class_id: rate_limit_respected
    decision: rejected
    reason: "This offline importer accepts no network requests; its batch resource bound is tracked separately."

Resolve the finding

  1. Read the requirement and the catalog definition rather than accepting a match solely because its score is high.
  2. Bind an applicable obligation, or record the actual reason for rejecting the match. A different owning requirement may call for an explicit delegation rather than a vague dismissal.
  3. Review staleness information and refresh the semantic-scan artifact when the corpus or pinned model changes. Recheck the live dispositions after the refresh.

Run and interpret

proof audit --check catalog_semantic_bindings_reviewed --verbose

Unresolved recorded pairs produce warnings. The scan is opt-in: with no artifact there are no matching pairs to review, and the check reports that absence rather than running a new scan.

The check enforces disposition of the suggestions in the artifact, not semantic completeness of the entire specification. A rejected suggestion can be wrong even when its reason passes the length rule. Audit's warning threshold is configurable and defaults to warn.

Continue from here

Understand deterministic baseline matching. Check catalog integrity.

Bring a disputed catalog suggestion together with the requirement and its proposed rationale. Bring a change to Proof.