Cross spec consistency clean

The check is cross_spec_consistency_clean. It is VERIFY-stage. It warns. It does not fail the merge. You can still advance. It looks at active requirements of the same req_type and asks a narrow question: do two of them share an antecedent set, drive different single-atom positive consequents, and sit in a mutex declared somewhere in the corpus. The mutex source is a !!A | !!B | !!C one-hot idle clause, or a domain.mutex group authored with proof var mutex add. If both hold, the joint behaviour is X -> A AND B, which is unsatisfiable. The finding names both requirement IDs, the shared antecedent, both atoms, and the mutex source. It does not write the YAML. It does not prove the Go.

The pairwise Kind2 hop stays on inconsistent requirements. That hop is SAT or UNSAT on a pair the solver actually saw, plus a count of examined pairs. This hop is a joint consequent that pairwise Kind2 never carried, because the mutex lives on another component. The assume/guarantee hop stays on design by contract. Mixed assume/guarantee pairs are different sides of a contract, not this warning. Compound consequents (X -> A | B) are ignored by design.

Each neighbor can look fine on its own. Kind2 SAT-checks the adapter. Kind2 SAT-checks the trace component. Reviewers signed both English objects in another tool. The expensive miss is two shalls that share an input and demand two atoms a third shall already declared exclusive.

# SYS-REQ-210  adapter. always: trace_requested -> link_requested
# SYS-REQ-211  adapter. always: trace_requested -> query_requested
# SYS-REQ-90   trace.   one-hot: !!link_requested | !!query_requested
# Kind2 SAT on the adapter. Kind2 SAT on trace.
# pass. each component is locally fine
# proof audit --check cross_spec_consistency_clean
# [VERIFY] cross_spec_consistency_clean
# SYS-REQ-210 + SYS-REQ-211 share trace_requested
# joint consequent link_requested AND query_requested
# mutex SYS-REQ-90
# WARNING
# proof help cross_spec_consistency_clean

Close it before you reach for a stamp. Retire the broad side if a narrower peer already covers it. Merge the pair into one disjunctive consequent. Split the antecedents so they no longer fire on the same input. Or fix the mutex if it was declared wrong. An explicit satisfies link between the pair suppresses the warning: decomposition refines, it does not contradict.

proof var mutex add --help
proof req supersede SYS-REQ-210 --replacement SYS-REQ-212
proof audit --check cross_spec_consistency_clean --verbose
proof help cross_spec_consistency_clean

The teaching graph is still two adapter shalls that share trace_requested and one trace shall that forbids both response atoms. Close it by retiring a side, merging to a disjunction, splitting the antecedents, or fixing a wrong mutex. Declared domain.mutex groups feed the same analysis as the legacy !! marker. Analysis paths with no variable files keep the legacy marker only. Zero in-scope contradiction candidates is a pass, not a proved graph.

# SYS-REQ-211 superseded. 210 kept with a split antecedent
# proof audit --check cross_spec_consistency_clean
# 0 contradiction candidates
# VERIFY may move on. pass sits on a current mutex read

The pairwise hop stays on inconsistent requirements. The rewrite hop stays on characterization testing and mirrors. Jama still authors. Proof vs Jama.

Warning when two active requirements of the same req_type share an antecedent, drive different single-atom positive consequents, and those atoms sit in a declared mutex. Default severity does not fail the merge. You can still advance. Zero in-scope findings is a pass, not a proved graph. Compound response alternatives are ignored by design. Mixed assume/guarantee pairs are out of scope. No mutex evidence means no flag, even when the pair looks exclusive to a reader. An explicit satisfies link suppresses the warning. The hop does not write a supersede. It does not add a shall. It does not invent a mutex group. It does not prove the Go. A quiet hop is not a proof that Jama's shalls match the Go, only that every in-scope pair currently lacks this joint-consequent pattern. We have not scored this floor against a frozen Jama pack or a VectorCAST corpus. The loss is named, not scored.

The pairwise hop stays on inconsistent requirements. The rewrite hop stays on characterization testing and mirrors. The engagement stays on software correctness audit. Jama still authors.

What is cross spec consistency clean? Same question. Same URL.

Is this inconsistent requirements? No. That hop is pairwise Kind2 SAT or UNSAT, plus a count of examined pairs. This hop is a joint consequent that pairwise Kind2 never carried. See inconsistent requirements.

Is this design by contract? No. Mixed assume/guarantee pairs are out of scope here. See design by contract.

Is this decision tables? No. That hop is a complete sheet. See decision tables.

Does a compound consequent X -> A | B flag? No. Single-atom positive consequents only.

Does this finding fail the merge? No by default. The check keeps warning severity. You can still advance.

What if no mutex is declared? The pair is not flagged, even when it looks exclusive to a reader. Author a domain.mutex group or a one-hot idle clause first.

Does a quiet hop prove the Go matches the shall? No. The hop observes joint consequents against declared mutexes. It does not prove the Go.

Is this characterization testing? No. That page is rewrite-with-a-ledger. This hop is a mutex pair. See characterization testing and mirrors.

Is Proof an LDRA alternative for the instrument? No. LDRA still owns the avionics toolchain. Proof vs LDRA.

Is Proof a Jama alternative for the shall? No. Jama still authors. Proof vs Jama.