Start with the work that keeps returning
| Your team keeps asking | Capability to evaluate | Ask to inspect |
|---|---|---|
| What did we promise, and who can change it? | Requirements authoring, recovery, baselines, review and controlled amendments. | An approved requirement with its source, revision history and authority. |
| What is wrong with this patch? | Human or automated code review, contextual analysis and actionable findings. | A finding tied to the proposed revision, with rationale and a disposition. |
| What establishes that this behavior works now? | Verification planning, execution, evidence provenance and freshness. | A rerunnable check, observed result and relevant execution basis. |
| What may this change break? | Requirement dependencies, code relationships and change-impact analysis. | The recorded relationships behind the impact claim, plus acknowledged blind spots. |
| What will the next agent know? | Persistent intent, decisions, history and agent retrieval. | A second task finding an earlier obligation and recognizing what must be rechecked. |
This is a buying checklist, not an exclusive vendor classification. Requirements platforms can include test management and assurance workflows; reviewers can retrieve context or invoke checks. Compare the delivered behavior in your project rather than the category name.
Use the same change in every demonstration
Illustrative evaluation. Ask to reduce storage used by an API's retry-key cache. The existing requirement promises duplicate-free retries for 24 hours. A patch proposes deleting keys after 12 hours.
A requirements workflow should expose the existing promise and any proposed amendment. A code review may spot the behavioral conflict and examine the implementation. An assurance workflow should connect that conflict to the affected claim, the checks required at the new revision and the authority needed to proceed.
Input: one real change, its repository and an existing promise.
Observe:
1. Can the workflow retrieve the promise without being told its ID?
2. Does it distinguish a proposed amendment from an approved one?
3. Can a reviewer inspect the actual check and execution result?
4. What happens when relevant code or configuration changes?
5. Which gaps remain visible at acceptance?
6. Can a fresh agent recover the decision on a later task?
Record: manual steps, setup effort, reviewer time and missed issues.Do not accept a generated explanation as the demonstration of execution. Open the result artifact. Change a relevant input. Check whether the old conclusion still appears current.
Where Proof fits
Proof maintains requirements and their relationships to code, hazards, verification and Changes in the Software Intent Graph. Requirements can carry rationale, hierarchy and trace links; Change records retain the intent and context for an update. Agents can query requirements and traverse their recorded links through MCP.
That gives Proof a role throughout intent management: investigating existing sources, recording candidate requirements, reconciling them with retained obligations and maintaining approved revisions. Recovery and amendment require review under project policy. They are not an automatic conversion of code into authoritative requirements.
You can keep an existing requirements platform, issue tracker or CI system. Decide which record is authoritative for each obligation and how revisions will stay aligned. Proof's value should be assessed on the repeated investigation and evidence work it removes, including the maintenance effort it adds.
The broader goal is a continuous acceptance workflow across agents and changes. Treat end-to-end automation, operational feedback and organization-wide rollout as capabilities to demonstrate for your scope, not as consequences of installing an MCP server.
Check authority before delegating decisions
Who can propose, approve, verify and release is a separate question from whether the evidence passes. Inspect the saved policy and the repository's merge controls.
Currently, Proof initialization permits agent approval at every assurance level. The recommended general-development configuration requires humans at A/B and permits agents at C through E, with other delegation explicit. These are different settings; selecting a high assurance level does not by itself install the recommended approval policy. The installed proof help assurance-level topic explains the supported configuration.
A recorded approval does not run the tests, establish independent verification or authorize a release. Include the applicable project controls in the evaluation.
Choose a bounded pilot
If the missing piece is agreement, begin with a disputed or undocumented behavior. If the agreement is clear and defects escape in patches, evaluate review on representative changes. If reviewers keep rebuilding the evidence and history before acceptance, try an assurance workflow on one consequential change followed by a second related task.
Compare active human effort, material gaps found, later rework and what was safely delegated. Include setup and rejected or blocked changes. Faster approval alone is not a useful measure of assurance.