Check reference
Close gaps and overlaps in data partitions
A set of named cases should explain the intended data domain. data_constraints_complete checks whether authored constraint groups leave holes or assign the same input to competing cases.
The domain is part of the claim
The property pipeline asks whether the group's conditions cover the declared domain and are mutually exclusive where partition analysis applies. Parameter types and constraints define that domain. A proof over nonnegative integers says nothing about negative inputs. Restricting a parameter to values the implementation likes can accidentally remove the invalid inputs whose rejection the requirement was meant to establish.
Illustrative example: shipping bands
Suppose legal package weights range from 0 through 10,000 grams. The model contains a light band through 1,000 and a heavy band starting at 1,002. The legal value 1,001 belongs to neither.
Declared domain: 0 <= weight_g <= 10000
Light: 0 <= weight_g <= 1000
Heavy: 1002 <= weight_g <= 10000
Unassigned example: weight_g = 1001
Starting heavy at 1,000 would instead overlap at the boundary. Review whether the business rule includes the boundary on the lower or upper band before editing the condition.
Read the outcome before choosing a repair
A disproved result has a counterexample: inspect it and repair the gap, overlap or mistaken domain. not-parsed means the expression was not translated and no proof was attempted. inconclusive means the solver could not decide within its resources. An unclassified result needs investigation of the raw outcome. These are different problems; none should be silently converted to success.
proof verify-properties specs/system shipping
proof audit --check data_constraints_complete --verbose
Use the model to drive implementation tests
The check has warning severity; command failure still depends on the audit policy, whose default failure level is warning. A complete partition proves a fact about the authored formulas, not the shipping function. Turn 1,000, 1,001 and the domain edges into tests with explicit expected charges, then record which implementation revision ran them.
Follow the evidence
Take the counterexample to the requirement owner and settle its expected outcome before changing the model.
Review one partition counterexample. Bring the domain and failing conditions so we can assess which boundary or expected outcome needs correction.