Engineering guide

Review requirement quality beyond a score

A requirement is useful when another engineer can understand its purpose, implement the intended behavior, and judge the result. A quality score can expose record problems, but it cannot make those decisions.

Check whether the statement supports a decision

“The importer handles invalid records correctly” names a concern without defining correct behavior. Review what counts as invalid, whether processing continues, what is persisted, and what the caller sees. Distinguish a product decision from a convenient property of the current implementation.

Illustrative candidate. “When a record lacks its required ID, the importer rejects that record, reports its input position, and continues with the next record without persisting the rejected record.”

The revised statement still needs an accepted source, domain definitions, and review of whether continuing is safe. More precise wording makes the decision inspectable; it does not authorize it.

Use Proof's quality analysis for its actual predicates

proof gaps specs/system --check quality

The implementation looks for specific record conditions: missing rationale when there is no parent trace, formal text without a human-readable description, missing formalization where the strategy expects it, draft/version signals, and high churn. High churn is informational rather than an actionable failure on its own.

The score combines these heuristics. It is not a measured probability that the requirements are correct, an INCOSE conformance certificate, or a guarantee that every ambiguity has been found. A parent's presence can satisfy a rationale predicate while the actual relationship still deserves review.

Review the questions a record check cannot answer

Is the behavior necessary for an accepted stakeholder outcome or constraint?
Are its trigger, domain, units, bounds, and failure response explicit?
Can the requirement be satisfied under the stated operating assumptions?
Does it conflict with another applicable requirement?
What observation would distinguish a correct implementation from a plausible wrong one?

Apply those questions to the set, not only each sentence. A collection of clear requirements can still omit recovery behavior or require incompatible outputs in the same state.

Keep the reason for revisions

When quality review changes meaning, record the intent decision and revisit affected formalization, code, tests, and evidence. A prose clarification that leaves meaning unchanged should say why the existing formal expression still applies.

Do not add placeholder rationale or switch to an informal strategy solely to improve the score. Resolve the actual gap, or preserve the unfinished work and its scope. Good quality review makes uncertainty easier to see rather than giving every row the same reassuring status.

Continue from here

Resolve competing interpretations. Use writing guidance in review.

Bring a requirement that passes structural checks but remains difficult to implement or verify. Bring a change to Proof.