Engineering guide

Review a requirement with its implementation evidence

A useful requirement review asks whether the promise is right, whether its implementation and evidence support it, and whether the decision is authorized. A complete-looking record is only the starting point.

Review the promise before the result

Read the requirement in its parent context. Identify the trigger, expected behavior, boundary cases, and environmental assumptions. Compare candidate wording with the accepted intent rather than accepting whichever interpretation makes the current implementation pass.

Illustrative review. “Resume an interrupted import without duplicates” needs evidence about crash timing, checkpoint durability, and replay. A test of successful uninterrupted import is relevant but cannot alone accept the recovery promise.

Agents can prepare and perform review within delegated policy. What matters is the authority for the decision and the evidence supporting it, not an assumption that all requirements must originate with a human.

Gather one inspectable brief

proof review req SYS-REQ-042

The command combines authored state, lineage, traces, witness coverage, impact, suspect links, and available persisted code-level MC/DC evidence. It assembles a review surface. By default it does not run every test or refresh all verification results.

Read missing and stale evidence as findings in their own right. A rendered brief can faithfully display an incomplete record; the act of gathering it does not close the gaps.

Plan, execute, then interpret the scoped gate

proof review req SYS-REQ-042 --gate
proof review req SYS-REQ-042 --gate --run
proof review req SYS-REQ-042 --gate --run --full

The first plans the requirement gate. The next executes affected tests and focused audit checks. The full option includes the project audit before treating the result as final checklist or pull-request evidence. Check the reported scope, skipped work, cache notes, command failures, and actual inputs as well as the verdict.

Write a decision that survives the task

State what is accepted, rejected, or still unresolved.
Identify the requirement, implementation revision, and evidence used.
Record any assumption or residual risk that limits the conclusion.
Use the applicable approval process and retain the reason for changes to intent.

A failing observation may require a code repair, a corrected model, or an authorized requirement change. Keep those outcomes distinct. If a defect is fixed, retain a reproducer and regression; a requirement review alone does not establish closure of every related failure mode.

When governing content changes, reopen the affected review and evidence instead of treating the old approval as permanently sufficient.

Continue from here

Validate the proposed intent. Review stale relationships.

Bring one requirement and the patch or evidence that should justify advancing it. Bring a change to Proof.