01
proof workflow
Starts, checks, advances, and resets stage-aware work. Good for real change sessions where a team wants the system to say what comes next.
Git-native requirements operations
Requirements that can fail before your code does.
ReqProof is for teams that want something stronger than a folder full of documents and weaker than a heavyweight process machine. It gives you a repo-native requirements model, workflow gates, formal checks where the model exists, traceability across code and docs, and generated evidence that stays tied to the work you actually shipped.
For engineering teams
Use it when requirements, code, tests, and docs need to move as one system.
For human and AI work
Exploration stays lightweight. Change-making sessions can become gated and reviewable.
For release evidence
Run audit, trace, verification, and document generation from the same repository state.
What ReqProof actually does
This is not a documentation skin and it is not a generic policy engine. The product is a working requirements system that treats specification, implementation, verification, and documentation as linked operational surfaces.
- Model requirements in the repo. Keep stakeholder, system, software, integration, variables, and interfaces in versioned artifacts instead of scattered spreadsheets and side documents.
- Run workflow and audit gates. Move from planning to implementation with explicit stage checks instead of relying on team memory and convention drift.
- Trace across code, tests, and docs. Use autolink and review flows to keep evidence attached to the actual implementation and generated output.
- Use formal analysis where the model supports it. ReqProof can drive solver-backed checks, proof budgets, vacuity checks, and coverage work without pretending every artifact is a theorem.
Plain language, no fake promises
It is built for teams that need rigor without surrendering developer flow.
ReqProof fits best when a team wants traceability and reviewability, but still works in Git, still writes code first-class, and still lets people ask questions before starting a gated session.
proof workflow init
creates session state when you are actually changing the system
proof trace autolink
refreshes derived implementation, test, and documentation links
proof help <check-id>
explains what a failing audit check means and how to rerun it
Core surfaces
Three command families drive most of the product.
The website should make the product legible immediately. These are the surfaces most teams interact with first: workflow, audit, and trace.
02
proof audit
Aggregates specification, implementation, verification, and documentation findings into one output with examples and next commands.
03
proof trace
Builds and reviews the graph that connects requirements to code, tests, and documents, instead of leaving that relationship implicit.
04
proof verify
Runs the verification pipeline, reuses caches where safe, and gives solver-backed evidence when a component is formalized deeply enough.
How teams actually use it
The process is flexible at the start and strict when the work becomes real.
ReqProof should not force ceremony onto pure exploration. It should become opinionated when a team starts changing specs, code, tests, or release evidence.
Exploration
Questions and planning
For code reading, initial design discussion, or AI-assisted planning, you can stay outside the workflow and keep the session lightweight.
- Ask questions about the repo.
- Sketch design changes.
- Inspect requirements and code without declaring a work session.
Execution
Specs and implementation
Once the work starts mutating the system, workflow state becomes useful: you get a baseline, stage-aware checks, and a shared story for humans and agents.
- Initialize the workflow when changes become intentional.
- Run stage checks instead of guessing what is now required.
- Advance only when the output is actually reviewable.
Evidence
Verification and delivery
Audit, trace, generated docs, and release artifacts can all come out of the same repo state. That matters when someone asks what exactly shipped.
- Refresh traces and review suspect links.
- Generate system documentation and evidence artifacts.
- Ship versioned binaries and install surface updates from main.
Install and distribution
Customer install should be simple. The source repo is not the product entry point.
ReqProof now publishes a real binary distribution surface. Use Homebrew if you want a quick install path. Use direct release archives if you need a controlled customer or enterprise deployment path.
Homebrew
Best default for macOS and developer-friendly environments once the tap is the install source you want.
brew tap probelabs/proof
brew install proof
Release automation updates the formula from the same pipeline that publishes the versioned artifacts.
Direct archives
Use downloads.reqproof.com for versioned customer artifacts
and controlled distribution. The release pipeline publishes macOS and Linux
builds for both amd64 and arm64.
For exact-version installs, use the versioned release path under
/releases/<version>/.
Source install
Still supported for internal developers and advanced users, but no longer the only serious path.
GOPRIVATE=github.com/probelabs/*
go install github.com/probelabs/proof/cmd/proof@latest
Contact
Tell us what you are trying to control, not just what you want to buy.
The best conversation usually starts with one of three things: a change process that feels too informal, a traceability/evidence problem, or an AI-assisted workflow that needs stronger controls. This site does not store your message. The form below opens an email draft.