Engineering guide
Keep a requirement's meaning through its lifecycle
A requirement's lifecycle records decisions about its authority and continued applicability. Its verification state records evidence about satisfaction. Changing one does not automatically establish the other.
Keep draft, review, and approval distinct
A draft is candidate intent. It can be recovered from existing code, contracts, tests, or stakeholder discussion, but those sources may conflict. Review resolves the intended promise, assumptions, ownership, and evidence expectations. Approval establishes the accepted requirement under the applicable policy.
proof req status SYS-REQ-042 --to review \
--by CR-104 --reason "Candidate recovery behavior is ready for review"This records a lifecycle transition with its reason and change reference. It does not execute tests or approve the requirement merely because it is now in review. Actors and delegated authority must be interpreted through project policy.
Do not confuse approved with verified
Illustrative state. A requirement is approved, its implementation changed yesterday, and its last passing evidence predates that edit. The promise remains authoritative, but confidence in the implementation needs renewal.
The reverse is also possible: tests pass for a draft interpretation that no authorized decision has accepted. A passing run cannot silently promote that interpretation into the product contract.
Review requirement and evidence fingerprints together. A status field alone cannot answer whether the code satisfies the current promise.
Choose an honest end-of-life decision
| Decision | Meaning to preserve |
|---|---|
| Deprecate | The requirement is being phased out; it may still apply during transition. |
| Retire | The obligation is no longer active, with a recorded reason. |
| Supersede | A replacement requirement takes over, with explicit lineage. |
| Reject | The candidate was not accepted as an active requirement. |
These choices affect children, implementation links, tests, and release assumptions. A replacement is not necessarily semantically identical; review what was preserved, changed, or intentionally withdrawn.
Preserve the record instead of deleting it
proof req retire --help
proof req supersede --help
proof audit --scope baseline --check deletion_without_retirement --verboseThe lifecycle commands retain the decision trail. Baseline deletion checking can expose IDs that disappear from the current corpus, but only relative to the available baseline. It cannot supply the missing rationale or retroactively authorize the removal.
Keep the requirement history with the change record so future agents and reviewers know which promises still govern their work and who had authority to change them.
Continue from here
Detect disappearing requirement IDs. Review evidence before a decision.
Bring a requirement that should change status and the reason for that transition. Bring a change to Proof.