Engineering guide
Create a requirements summary people can review
A requirements summary should help a reader see the promises, their status, and the decisions still needed. It is a view of the repository's records, not a substitute for them.
Choose the reader's question
A product reviewer may need to see which stakeholder outcomes changed. An implementation reviewer may need the affected system and software requirements. A release reviewer needs current evidence, unresolved issues, and authority for the decision. A single count of approved requirements does not answer all three questions.
Illustrative summary scope. Import recovery requirements for the candidate release: accepted promises, parent and child relationships, changed requirements, evidence dates and revisions, open assumptions, and unresolved defect dispositions.
State the revision and scope before presenting totals. Make it clear whether a status describes approval, structural coverage, or a verification result.
Generate the recorded view
proof doc generate req-summary --format html \
--output docs/requirements.htmlThe command renders the requirement-summary template from project data and writes the requested file. Use the project's actual output location. The spec filter, when needed, accepts a configured spec name or prefix.
Document generation does not run the implementation, regenerate fixtures, or refresh every analysis. A new file timestamp can wrap old evidence. Review the source state and run the appropriate verification workflow before presenting the document as a current release input.
Make gaps visible rather than averaging them away
| Summary item | Useful interpretation |
|---|---|
| Approved requirement | Accepted intent under the recorded policy and review. |
| Linked test | A claimed verification relationship, not necessarily a recent passing run. |
| Passing result | An observation with specific inputs, code, and environment. |
| Open issue or assumption | A limitation that may affect acceptance or required follow-up. |
A high aggregate percentage can hide one important uncovered guarantee. Include the identities and consequences of remaining gaps so a reader can make a scoped decision.
Keep the summary reproducible
Retain the repository revision, generation command, and relevant evidence provenance with a shared document. Link readers back to detailed requirement and change records where they can inspect rationale and history.
When intent or implementation changes, regenerate the view after updating the records and relevant checks. Do not edit the rendered summary to show a more favorable status than the source. The summary is most useful when it faithfully exposes what is accepted, what is observed, and what remains unknown.
Continue from here
Build a structured specification view. Report verification evidence.
Bring a requirements set and the decision its summary needs to support. Bring a change to Proof.