Check reference
Read the actual result of a property proof
Declaring a property is different from proving it. z3_properties_verified reports results for supported authored variable properties and data constraints.
State which model the property belongs to
The property pipeline includes algebraic properties declared on variable models and supported data-domain obligations. It does not automatically translate every production function into those models. Before interpreting a result, identify the variable, operation, domain, assumptions and property that were checked. A successful solver result is bounded by that encoding. A skipped constraint needs separate attention even when the checked set succeeds.
Illustrative example: merging a set of recipients
Idempotence: merge(A, A) = A
Commutativity: merge(A, B) = merge(B, A)
Associativity: merge(merge(A, B), C) = merge(A, merge(B, C))
These properties are appropriate for a modeled set union. They are not necessarily appropriate for an ordered recipient list or a merge where the later source wins. Decide the intended semantics before selecting algebraic laws. A proof of commutativity for a set model does not establish order preservation in the implementation.
Investigate the named verdict
Run property verification for the relevant component, then inspect the failing property and any counterexample. Repair the actual requirement or model error before rerunning. A parse gap or an inconclusive solver outcome needs a different response from a counterexample. Check domain coverage too: a successful proof over a narrowed or empty domain can be weaker than intended.
proof verify-properties specs/system recipients
proof audit --check z3_properties_verified --verbose
Accepted debt remains a documented violation
The check can classify a violated property as accepted known-issue debt when its requirement binding, open issue, green reproducer tripwire and nonblocking release disposition meet the implementation's criteria. That is a policy disposition, not a proof that the violated property holds. Retain the issue identity in the result. Independently connect the model to production behavior through reviewed bindings and executed tests, and require the appropriate CI status if the audit is meant to block a merge.
Follow the evidence
Name the operation and domain before deciding whether the property is the right one.
Review one property verdict. Bring the operation, domain and solver result so we can assess whether the property matches intent and what its outcome establishes.