Check reference
Check what modeled predicates actually imply
Boolean names can conceal incompatible meanings. behavioral_implications_verified checks supported requirement implications over the concrete domains defined by their data constraints.
Connect the boolean rule to its data meaning
A temporal contract may be realizable when its boolean signals can take suitable values. That does not establish that the numeric or enum predicates behind those signals imply one another. The behavioral implication pipeline translates supported formulas and asks whether the implication holds for every input in the declared domain. The check has warning severity, distinct from the audit's failure threshold.
Illustrative example: an inclusive boundary
Predicate A: request_count >= limit
Predicate B: request_count > limit
Claim: A implies B
Counterexample by inspection: request_count = limit
At equality, A is true and B is false. This is an illustrative logical counterexample, not output from a product run. A system that should reject at equality needs a consistent inclusive boundary in its formal predicates and implementation. A system that allows equality needs a different requirement.
Route the finding by outcome
disproved means the solver returned a counterexample. Inspect it, then correct the requirement or data model. not-parsed means no proof was attempted for the formula. inconclusive means resource limits or solver uncertainty prevented a decision. unclassified preserves an unexpected result token for investigation. A counterexample is not the same problem as an unsupported translation.
proof verify-properties specs/system limits
proof audit --check behavioral_implications_verified --verbose
The concrete domain is still authored
Check parameter bounds, assumptions and the mapping from runtime values to predicates. Excluding equality from the domain would remove this counterexample without repairing the real boundary. The result is a statement about the encoded implication; it is not an observed execution of the limit checker. Preserve a boundary test against production code and rerun the relevant model analyses after a semantic change.
Follow the evidence
Turn the counterexample into a product decision and an executable boundary test.
Review one failed implication. Bring the concrete predicates and counterexample so we can assess which domain assumption or behavioral boundary needs correction.