Check reference

Review obligation catalog upgrades

A new Proof binary can ship new obligation definitions. A catalog pin makes that change visible so the project can review new applicability and evidence expectations.

What the check observes

The check compares the configured catalog version with the version shipped in the binary under the selected upgrade policy. The default manual policy requires an exact version match. Auto-patch permits patch changes within a major/minor pair; auto-minor permits minor and patch changes within a major version. Missing numeric components read as zero, so a pin of 1 under manual means 1.0.0, not every 1.x release.

Example: a binary upgrade exceeds a manual pin

Illustrative case. A project pins 1.0.0 with manual upgrades. A binary carrying 1.2.0 produces a mismatch. Inspect which classes changed and which requirements gain obligations before deciding whether to move the project baseline.

proof catalog version
proof catalog upgrade --check
proof catalog upgrade --diff
proof catalog upgrade --dry-run

Resolve the finding

  1. Inspect the shipped version, proposed transition, definition changes, and newly activated obligations.
  2. Choose the catalog policy and version the project actually intends to accept. Resolve or explicitly track the resulting requirement work before treating the new baseline as reviewed.
  3. Apply an accepted transition with the catalog upgrade command and commit the pin together with its reviewed changes. Keep a policy change separate from an attempt to silence one finding.

Run and interpret

proof audit --check catalog_version_pinned --verbose

A configured pin outside its policy produces a specification-stage warning. An absent pin passes with information that no pin is configured. The check does not require every project to pin a catalog.

A pin controls the version relationship; it does not prove that catalog definitions are correct, that every applicable class was adopted, or that required evidence exists. Audit defaults to a warning failure threshold unless project configuration overrides it.

Continue from here

Review newly applicable obligations. Check catalog references.

Bring a catalog upgrade and one requirement whose verification obligations would change. Bring a change to Proof.