Proof complexity clean

The check is proof_complexity_clean. It is VERIFY-stage. Default severity is warning. It counts active formalized requirements per component, the variables in that component's variable files, and the non-assumption guarantees. Informal rows and empty FRETish are skipped. Defaults are 100 formalized requirements, 100 variables, 75 guarantees. Override them in project.checks.proof_complexity_clean. The hop does not call Kind2. The hop does not call Z3. Wall-clock stays on solver latency clean.

A pass prints all formalized components fit proof budgets with the three numbers. A warning names each overrun as spec/component exceeded dimension (actual > budget), at most five details, then a remainder. An inspection error is fail: the hop cannot count. Raising the three integers in proof.yaml is a policy change, not a split.

The expensive miss is a review that treats one VALID as proof the slice is still the unit you meant, then CI that never counted the node. Adjacent search for proof complexity is a CS-theory SERP. That is not this hop.

This is not whether the last realize crossed one minute. That hop is solver latency clean. A small slice can still be slow. A large slice can still finish under the clock. The help file teaches the size budget first.

# proof.yaml
project:
  checks:
    proof_complexity_clean:
      max_formalized_requirements: 100
      max_variables: 100
      max_guarantees: 75

# ledger: 142 formalized reqs, 118 vars, 90 guarantees
# proof audit --check proof_complexity_clean
# 3 proof complexity budget overruns across 1 components
# specs/system/ledger exceeded formalized_requirements (142 > 100)
# specs/system/ledger exceeded variables (118 > 100)
# specs/system/ledger exceeded guarantees (90 > 75)
# warning: last VALID still sits on an oversized slice

Pick one resolution, not a stack of them: tighten the worst formulas, split the component on a real boundary, or add interface requirements if you create one. Do not raise the three integers and call that a split. Do not invent a sibling only to silence the checker. A quieter hop with the same 142-requirement node is the same cheat. Then re-run VERIFY.

proof audit --check proof_complexity_clean --verbose
proof help proof_complexity_clean
proof help proof-slices
proof realize specs/system ledger --format json

The teaching graph is still one output whose realize printed valid while ledger held 142 formalized requirements. Close it by tightening the worst formulas, or by splitting on a real boundary with interface requirements. Do not add a sibling only to silence the checker. With the three integers raised, the quiet hop still prints, and the node did not get smaller. It just left the budget.

# after a real split, ledger holds 48 reqs / 31 vars / 22 guarantees
# proof audit --check proof_complexity_clean
# all formalized components fit proof budgets (100 reqs, 100 vars, 75 guarantees)
#
# VERIFY is allowed to move on. a pass now sits on a slice

The clock hop stays on solver latency clean. The lemma hop stays on Z3/Kind2 on one function. The property hop stays on Z3 properties verified. Jama still authors. Proof vs Jama.

Warning when a component exceeds one of the three counts. Fail when the hop cannot inspect the project. Informal rows are skipped, not scored. Assumptions are not guarantees. The hop does not write the YAML. It does not add a shall. It does not prove the Go. It does not run Kind2. It does not time the realize. A quiet hop is not a proof that the authored merge is the one you meant, only that every formalized component still fits the three integers, or that none were in scope. The default warning does not block advancement. Raising 100 / 100 / 75 is a policy change, not a remediation. We have not scored this floor against a frozen Jama pack or a ReqIF export. The loss is named, not scored. Adjacent Ads volume on proof complexity is a CS-theory SERP, not this hop.

The clock hop stays on solver latency clean. The lemma hop stays on Z3/Kind2 on one function. The property hop stays on Z3 properties verified. The engagement stays on software correctness audit. Jama still authors.

What is proof complexity clean? Same question. Same URL.

Is this solver latency clean? No. That hop is wall-clock after the solver ran. This hop is req / var / guarantee counts before anyone times the slice. See solver latency clean.

Is this Z3 or Kind2 on one function? No. That hop runs the solver. This hop asks whether the component that holds the lemmas is still a slice. See Z3/Kind2 on one function.

Is this Z3 properties verified? No. That hop is whether the authored merge proved. This hop is whether the node that holds it still fits the budget. See Z3 properties verified.

Is this the CS-theory phrase proof complexity? No. That SERP is a complexity class. This hop is three integers on a formalized component.

Does a quiet hop prove the merge is the one you meant? No. The hop observes counts. It does not score the sentence.

Does a quiet hop prove the code matches the shall? No. The hop observes counts. It does not prove the Go.

Does an oversized node fail the merge? No. The check keeps warning severity unless you raise it in proof.yaml.

Is Proof a Jama alternative for the shall? No. Jama still authors. Proof vs Jama.