Check reference
Find requirements that demand incompatible outcomes
Two requirements can each look reasonable while demanding mutually exclusive outcomes for the same trigger. This check searches for that specific conflict across the requirement corpus.
A narrow, explainable contradiction
cross_spec_consistency_clean recognizes supported always satisfy shapes that share an antecedent but require different positive consequent atoms. It combines those patterns with mutual-exclusion evidence from declared domain.mutex groups or supported legacy one-hot clauses. The finding names the requirements, trigger, outcomes and mutex source. It is a warning about a contradiction candidate, rather than a universal analysis of arbitrary prose.
Illustrative example: a routing decision
An adapter has two rules for the same event. One requires routing to the archive; the other requires routing to the live index. The domain says those routes cannot both be selected.
Trigger: export_requested
Rule A: export_requested implies archive_selected
Rule B: export_requested implies live_index_selected
Domain: at most one of archive_selected, live_index_selected
With the trigger true, the rules require both outcomes. The domain forbids that combination. Checking each rule separately would miss the disagreement between them.
Resolve the product decision
Find out whether the event should choose a route, require both routes, or distinguish two kinds of request. Split the antecedent if the requests differ. Retire a superseded rule if it no longer expresses intent. Change the mutex only if simultaneous outcomes are actually allowed. Replacing both requirements with a disjunction is valid only when either outcome is acceptable; otherwise it weakens the contract.
proof audit --check cross_spec_consistency_clean --verbose
A clean pattern scan has limits
The detector depends on recognized formula shapes and explicit mutex facts. It does not discover every semantic contradiction across components, nor establish that the declared mutex matches the physical or software environment. Run the relevant component consistency analysis and review assumptions separately. Preserve the conflicting examples when changing the contract so future edits can be checked against the chosen behavior.
Follow the evidence
Use the named trigger and outcomes as a concrete review question for the requirement owner.
Review one conflicting requirement pair. Bring the shared trigger and mutex declaration so we can identify the decision that needs to be resolved before changing either rule.