Check reference
Keep formal components within a reviewable proof budget
A contract can be logically valid and still be too large to understand or verify comfortably. proof_complexity_clean flags component slices that exceed structural project budgets.
Count the scope being modeled
The default budgets are 100 formalized requirements, 100 variables and 75 guarantees per component, configurable under project.checks.proof_complexity_clean. The verify-stage check has warning severity. These are engineering budgets, not mathematical limits on what can be proved. A smaller model can still be solver-hostile, and a larger one may be manageable with appropriate evidence.
Illustrative example: unrelated responsibilities
A component named checkout accumulates inventory reservation, payment authorization, email delivery and reporting rules. Splitting source files does not reduce the formal contract if every guarantee still lives in the same model.
Potential boundaries to review:
Inventory: reserve or release stock
Payment: authorize or decline a charge
Notification: report a completed order
Shared contract: when one component may rely on another
This is a proposed decomposition for discussion. It is useful only if the architecture really has these responsibilities and the new interface assumptions are justified.
Simplify before raising the budget
Read which dimension crossed the configured limit. Remove duplicate or obsolete model content and simplify unnecessarily tangled formulas. If responsibilities are independent, give them explicit component boundaries and interface guarantees. Rerun analysis and compare both proof results and timing. Increasing the budget is a visible policy decision, not a repair to an unreviewable contract.
proof audit --check proof_complexity_clean --verbose
proof realize specs/system checkout --format json
Size says little about correctness
The check does not measure stakeholder completeness, assertion strength or production coverage. A compact model made of vague booleans can meet every structural budget while omitting important behavior. Keep domain, gap and source-evidence review alongside complexity checks. After decomposition, verify that the assumptions introduced at each boundary are established by another component or by a documented environmental constraint.
Follow the evidence
Use the over-budget dimension to identify duplication or a real responsibility boundary.
Review one over-budget model. Bring the component and its guarantees so we can assess whether simplification or a real architectural boundary would make the proof easier to maintain.