Resolve proposed catalog classes

What the check reads

The opt-in verify-stage check reads proposes_class on discovered signals and compares proposed IDs with the shipped catalog and project overlay. Missing from both produces a warning. An overlay or shipped match produces information directing the rule toward an ordinary obligation binding. Suggestions use deterministic name distance and shared framework references; they are not semantic equivalence judgments.

proof audit --check code_signal_unbindable

An illustrative case

Illustrative case: a custom rule proposes retry_budget_bounded. If neither catalog defines that class, the finding needs a catalog decision. If the project overlay already contains it, continuing to call it a proposal hides an available binding. The author should inspect the existing meaning before replacing proposes_class with an obligations entry.

Resolve the finding

1. Inspect the signal, proposed class description and nearest catalog candidates.
2. Reuse an existing class only if its obligation matches the behavior. Otherwise draft and review a new class with an explicit scope.
3. Update the signal rule to bind an available class, rerun the scanner as needed and rerun this check.

What a clear result means

Resolving an ID does not establish a requirement, execute a test or prove that a signal is a defect. Scanner-language coverage belongs to the obligations review check. Keep the catalog decision separate from the later work that satisfies the selected obligation.

Continue with one real issue

Code signal obligations reviewed · High severity obligation without vector

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.