proving-the-regressionlisted

# Proving the regression **A check you have not seen fail is not a check.** Coverage says a line ran. Only a failing negative control says the scenario is checked. Everything here follows from that one sentence. This skill owns whether a check can fail. It does not choose which checks to run for a given change. This matters most where it is least convenient: a new rule feels done when the valid case passes. But a rule that never rejected anything is indistinguishable from a rule that cannot reject anything, and the two stay indistinguishable until the day it was supposed to save you. ## The negative control Before trusting a guard, make the case it exists to reject, watch it fail, then revert. - Observe an ordinary regression fail **before** the fix when practical. - For a new static, schema, or corpus guard, temporarily introduce the rejected case and observe the intended failure. Confirm it fails **for the intended reason** — a guard that rejects your fixture because of a syntax error has not been proven. - A strong promise needs both a focused valid fixture **and** an invalid one that proves the check can fail. - Where a check is meant to reject a candidate before publication, verify it rejects at that point, not merely somewhere downstream. [references/false-guardrail-forms.md](references/false-guardrail-forms.md) is the recognition catalog: twelve shapes a guard takes when it cannot reject, the question that exposes each, the six checks to run over an assertion yo