revx optional reqx add-on
Reviews tied to the versions that matter.
revx turns the version history reqx already keeps into a structured, independent review process. Plan the reviews, see what needs review, record findings and fixes, and hand auditors a package that identifies exactly what was reviewed.
Part of the reqx hub, not another system
revx runs in the same reqx server and appears as a revx mode in the same browser application, enabled per licensed deployment. It reads requirements and history from reqx; it never changes requirements, labels, or tags.
Plan the reviews
Review plans, roles, and forms under version control
A plan names the documents and source repositories to review, each from a start label to an end label, and which role reviews which items with which form.
Scoped reviews
Select items by kind, derived flag, attribute values, or file paths. Transition criteria hold a review until the reviews it depends on are complete.
Versioned forms
Review roles and checklist forms are managed centrally. Plans and forms are versioned, so past reviews keep the form they used.
Form templates included
DO-178C requirements, design, code, test, and coverage reviews; DO-254 requirements, conceptual and detailed design, HDL code, and verification reviews.
Know what needs review
Queues computed from version history
Needs Review lists new, changed, moved, and deleted items, and items whose traces changed. Group by section, folder, or change, and review the latest revision or each revision separately.
- Stale: reviewed items that changed afterwards are flagged automatically
- Upstream changed: reviewed items are reopened when a requirement they trace to changes
Independent, traceable reviews
Findings that close the loop
Where the plan requires independence, a reviewer cannot review changes they made. Reviewers compare each item between the reviewed versions, answer the checklist, and comment.
- Reviewers comment and authors reply; both stay drafts until submitted
- Commits that address a review are tied to it
- Findings close once fixed, or return to the original reviewer for re-review
Evidence for audits
Review packages that identify every reviewed version
Download one package per plan, optionally at a project baseline. Packages are deterministic.
In each package
- Records of exactly which version of every item was reviewed: item, version, fingerprint, and commit
- The reviewed requirement files and a printable report
- SHA-256 checksums
Source file contents are intentionally excluded from review packages.
On every requirement
Each reqx requirement page lists the reviews that covered it, the version covered, the outcome, and the comments, so review history is visible where engineers work.
Editions
reqx, or reqx with revx
| Capability | reqx | reqx + revx |
|---|---|---|
| Requirements as plain files in your Git repositories | ✓ | ✓ |
| Multi-user web editing with locking, merge, and commit | ✓ | ✓ |
| Traceability, suspect links, derived requirements | ✓ | ✓ |
| Traceability matrices and reports | ✓ | ✓ |
| Document labels and project baselines | ✓ | ✓ |
| Import from ReqIF, CSV, and Word; export to HTML, PDF, and Word | ✓ | ✓ |
| Issue tracker checks, webhooks, API tokens, command-line tool | ✓ | ✓ |
| Review plans, roles, and versioned review forms | – | ✓ |
| Needs Review queues from version history | – | ✓ |
| Reviewer independence checks | – | ✓ |
| Comments, replies, re-review, and closure | – | ✓ |
| Re-review triggered by upstream and trace changes | – | ✓ |
| Review evidence packages | – | ✓ |
If a revx license ends, existing review records stay readable and downloadable.
See a review from plan to evidence package
We'll walk through the synthetic brake controller example: closed reviews, a finding waiting for re-review, and requirements reopened by upstream changes. Pricing is available on request.