Run a system requirements review with a clear decision

Define what the review is accepting

For an import service, the review might accept the normal, rejection, and restart behavior for a specified deployment and input format. State which interfaces, quality limits, and environmental assumptions are included. Identify excluded behavior so absence of evidence is not mistaken for acceptance.

Include the authority for accepting the scope and changing prior promises. A meeting, an agent report, or a command result alone does not confer that authority.

Inspect the relationships and the actual content

Check that stakeholder criteria are represented, system requirements have meaningful parent relationships, and component responsibilities and interfaces are allocated. Read the guarantees for compatible outputs, complete domains, and justified assumptions.

A record can be structurally complete while specifying the wrong outcome. A satisfies entry can be present while naming an unrelated parent. Review a few concrete normal, failure, and recovery scenarios across the whole chain, not only each file in isolation.

Use the implemented SRR gate as an evidence index

proof validate
proof gate srr

The SRR gate combines specification checks with criteria for stakeholder acceptance, system links, gaps, quality, level structure, progress beyond draft, and blocking accepted risks. Its formal-analysis criterion reads recorded realizability, consistency, and non-vacuity state for applicable requirements. Missing or unknown required formal results fail that criterion.

The gate assesses the available project state; it is not a command that independently reruns every solver and implementation test. A corpus with all active requirements still in draft fails the review-progress criterion. A partially reviewed corpus is reported with observations rather than being described as fully reviewed.

Record the decision and remaining obligations

1. Identify the accepted requirement revision and supporting evidence.
2. Resolve or explicitly retain contradictions, assumptions, and incomplete allocations.
3. Name blocking risks and the authority for any permitted residual risk.
4. Assign concrete follow-up for unresolved work and define what will reopen review.

Do not change status fields merely to make the gate ready. An accepted review establishes a governed starting point; later implementation, configuration, or requirement changes can invalidate parts of its evidence. Keep that history available for the next review.

Continue from here

Separate structural and intent validation. Review individual requirements in depth.

Bring a requirement set and the specific decision your next system review needs to make. Bring a change to Proof.