Topic · ambiguous requirements

Ambiguous requirements

Gist

Ambiguous requirements are two shalls a reader can take two ways. Proof runs proof audit --check ambiguity_reviewed. The check does not rewrite the wording. Jama still authors.

proof audit --check ambiguity_reviewed

Keep Jama if you already walk the shall in a meeting. Keep a style guide if you already ban vague words. Neither one names the overlapping pair.

Request demo Last green pair vs this stamp

01 · The pair that looked independent

Two approved shalls can still share a variable.

Contradiction is UNSAT. Ambiguity is two readers taking the same pair two ways.

A pair can be SAT and still be a problem. SYS-REQ-010 names CLI rejection. SYS-REQ-011 names atomicity. Both constrain invalid_strategy_rejected. The meeting said both look fine. The next agent treated them as independent. They were not.

Inconsistent requirements fail when two guarantees cannot both hold. That hop is inconsistent requirements and proof check consistency. This hop is wording overlap: the pair is still satisfiable, and two readers still disagree about which shall owns the field.

The loop is two commands. The audit names the pair. The review writes a reason on the named requirement. When the overlap is accidental, rewrite one shall. When it is intentional, stamp it. Do not silence the warning by raising a threshold.

proof audit --check ambiguity_reviewed --verbose
proof gaps review --scope active --check ambiguity --req SYS-REQ-010 \
  --reason "CLI rejection and atomicity share invalid_strategy_rejected on purpose."

The first command is a warning, not a hard fail. Adopting it on an existing corpus surfaces pre-existing overlap as tracked debt. --all is only after you have read every current pair in the selected scope. A stamp does not change the text.

02 · The exhibit

Same pair. A green walkthrough, or a named overlap.

Both shalls are approved. Both constrain the same field. Click the tabs.

The run

Ask do both shalls look fine
Exit 0 if someone typed looks good
Why a walkthrough does not name the shared field

Stamp green

This hop

No overlap review. invalid_strategy_rejected is still claimed twice.

No pair named

The run

Keep the meeting. It still owns the walkthrough. That is not this hop.

Keep the walkthrough

Proof

Ask which pair still needs a human read
Out SYS-REQ-010 ↔ SYS-REQ-011 on invalid_strategy_rejected

A stamp is not a rewrite

Same pair. A green walkthrough, or a named overlap. Click the tabs.

Surface	What they do	What Proof does	What we lose
Walkthrough / looks good	A human stamp on each shall.	A named pair, then a reason on one of the IDs.	The check does not rewrite the wording. A reason is not a proof of the Go.
Style guide / INCOSE	Ban vague words. One shall, one meaning.	Flag the overlapping pair that already shipped.	Not INCOSE attributes. Quality fields stay on requirements quality.
Inconsistent requirements	Two guarantees that cannot both hold.	Wording overlap on a SAT pair. Different hop.	Not UNSAT. See inconsistent requirements.
Requirement review	A brief of traces and impact. It does not move status.	A different kind. `proof review req` is not this hop.	Not the walkthrough brief. See requirement review.
Jama	The authoring programme. Reviews if you put them there.	Warn the merge when an overlapping pair has no review stamp.	Not Jama's ambiguity score. Jama still authors. We have not run a frozen Jama pack.

The teaching graph is still two approved shalls next to one shared field. Run the audit. Read the pair. Rewrite if the overlap is accidental. Stamp if it is not. Do not write "looks fine" on each shall and call that a review of the pair.

proof audit --check ambiguity_reviewed --verbose
proof gaps review --scope active --check ambiguity --req SYS-REQ-010 \
  --reason "CLI rejection and atomicity share invalid_strategy_rejected on purpose."
proof audit --check ambiguity_reviewed

Contradiction stays on inconsistent requirements. Field presence stays on requirements quality. The walkthrough brief stays on requirement review. Jama still authors. Proof vs Jama.

03 · The honest loss

Proof names the pair. It does not decide which shall is right.

A review stamp is not a rewrite. Jama still authors.

The check is a warning. It does not fail the merge. It does not rewrite the shall. A long wrong reason still clears the warning. We have not scored this slice against a frozen Jama ambiguity pack or a second human's wording judgment. The loss is named, not scored.

UNSAT pairs stay on inconsistent requirements. INCOSE attributes stay on the INCOSE guide. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What are ambiguous requirements? Same question. Same URL.

What is requirements ambiguity? Same cluster. Same URL.

Is this inconsistent requirements? No. That hop is UNSAT. This hop is wording overlap on a SAT pair. See inconsistent requirements.

Is this requirements quality? Quality is fields present. This hop is the overlapping pair. See requirements quality.

Is this requirement review? No. That brief does not name the pair. See requirement review.

Is Proof a Jama alternative for spotting vague objects? No. Jama still authors. Proof vs Jama.