Engineering guide

Investigate inconsistent requirements

Requirements are inconsistent when their applicable promises cannot all be honored together. The repair starts by locating the conflict and its assumptions, not by weakening whichever rule is easiest to change.

Make the conflict concrete

One requirement says an emergency stop must immediately disable an actuator. Another says the actuator must remain enabled whenever a control command is active. If both conditions can hold together, the required outputs conflict. If an approved operating assumption makes that combination impossible, the model must represent and justify it.

Illustrative analysis. Input state: emergency_stop=true and control_active=true. Required output from rule A: enabled=false. Required output from rule B: enabled=true. The review must decide priority, condition refinement, or whether the assumed environment is wrong.

Separate intent conflicts from model defects

A solver may expose a real contradiction in the accepted requirements. It may also expose a modeling error: an input constrained as an output, a missing bound, or two distinct domain concepts mapped to one variable. Check the encoding against the governing prose and acceptance decisions before editing the product contract.

proof validate --preflight specs/system control
proof check consistency specs/system control --persist=false

These examples require the project's actual spec and component. The consistency command can inspect modeled pairs; the no-persist option avoids saving that run's result into requirement state.

Read what was actually analyzed

Pairwise consistency is not whole-set consistency: three constraints can conflict collectively even when each pair is satisfiable. Realizability asks another question about whether a system can meet the modeled guarantees under its assumptions over the analyzed behavior. Inspect which pairs were checked, which were skipped, and why.

Disjoint variables or outputs can exclude pairs from an analysis. A report that examined zero pairs provides no cross-requirement consistency assurance. A solver timeout or unknown result is not a clean result.

Resolve the contradiction through authority

Record the conflicting requirements, the triggering state, and the considered interpretations. An authorized decision may establish precedence, revise a requirement, or correct the model. An assumption must describe a justified environment boundary; adding one only to rule out an inconvenient counterexample hides the problem.

If the conflict predicts a code failure, reproduce it against the implementation. Keep the model finding, confirmed defect, regression repair, and any class-wide conclusion distinct. Each has different evidence and scope.

Continue from here

Review environmental assumptions. Interpret model analysis.

Bring two requirements that seem individually reasonable but cannot both hold in one scenario. Bring a change to Proof.