Compare · StrictDoc
Proof vs StrictDoc: requirements, source and evidence
StrictDoc and Proof both support requirements work near source code. Compare how authors maintain the requirements, how reviewers reach the evidence, and what happens when the implementation changes.
Both can put requirements close to source
StrictDoc stores structured requirements in SDoc files, provides a browser editor, and exports documentation. Its user guide describes requirement-to-source links, source annotations and test-report imports.
Proof manages repository requirement records, their lifecycle and links to code, tests, verification evidence and known issues. Configured checks help reviewers inspect specific gaps after a change. Its value in a trial should be demonstrated by the review work it makes easier, beyond producing a connected graph.
Compare the workflow your team would actually maintain. Authoring, readable review diffs, source support, evidence provenance and publication needs all matter. A requirement stored in either format still needs an authorized meaning and an adequate verification method.
Compare the work you need to do
Ask each workflow to preserve the same requirement and explain the same change.
| Evaluation question | StrictDoc | Proof |
|---|---|---|
| Where do authors work? | Structured SDoc files and a browser editor; multiple export formats support publishing. | Repository requirement records with CLI authoring and lifecycle operations. |
| How does source connect? | Links to source files and language-aware source elements, plus source annotations. | Source annotations and trace records connect supported code to requirements. Inspect actual language and symbol coverage. |
| Can results join the graph? | The guide documents JUnit and Robot report imports; both carry experimental notices in the checked guide. | Evidence records and linked tests support obligation review. A stored artifact does not necessarily represent an executed test. |
| What should the trial inspect? | Round-trip editing, source mapping, report import and useful exported views. | The changed obligation, its affected code, evidence gaps and configured review decision. |
Change a sensor rule without losing its boundary tests
Illustrative evaluation: a sensor service must mark a reading unavailable after three consecutive invalid samples. A patch adds a fallback path that may reset the counter too early.
Model the requirement, rationale and implementation links in the candidate workflow. Link tests for two invalid samples, three invalid samples and a valid sample that legitimately resets the counter. Inspect actual results for the candidate revision and verify that the assertions check availability as well as the counter value.
Then rename the helper and change the fallback path. Ask another engineer to find the affected requirement, inspect the boundary cases and identify evidence that needs refreshing. Record broken links and manual repair work. A successful documentation export or imported passing report alone does not establish that the fallback obeys the rule.
When each is a good choice
Choose StrictDoc when structured requirements authoring, source traceability and publishing fit your team's working process. Evaluate its formats and experimental features against your own maintenance and qualification requirements.
Evaluate Proof when you want repository requirements to support recurring change review, evidence checks and retained issue history. The trial should show which checks run, which inputs they consume and which gaps require human work. Formal analysis, where applicable, still depends on reviewed models and assumptions.
If you already use StrictDoc, begin with one mapped requirement rather than a wholesale conversion. This comparison does not claim a dedicated StrictDoc synchronization connector or a lossless SDoc import. Preserve IDs and authority while testing the handoff.
Sources and comparison scope
Official StrictDoc user guide checked October 3, 2026, including source traceability and section 23.6 on test reports. Experimental labels are reported as published, even where the guide contains an earlier expected stabilization date. No product trial or comparative performance measurement was performed for this page.
Try the workflow on one component
Bring one requirement, its source links and a recent test report. We can scope the checks and evidence Proof could support, then identify the mapping and maintenance work an evaluation would require.