Turn the guidance into a record someone can review
The AI4SDLC requirements play recommends versioned, traceable requirements with human validation of AI-generated content. The testing play carries that intent into test design and warns against tests that simply repeat the implementation. Together, they give a useful starting point for an evidence record.
| Practice | Artifact to retain |
|---|---|
| Validate the intended behavior | Source reference, requirement revision, reviewer and decision. |
| Derive checks from the requirement | Inputs, expected outcomes and an explanation of what each check covers. |
| Run and inspect the checks | Execution command, code revision, environment, raw result and limitations. |
| Keep the record usable | Links between the requirement, change and evidence, with unresolved work assigned. |
These are implementation choices for applying the guidance. Your program still decides which obligations apply, which tools and environments are permitted, and who may accept the change.
Work through one retry change
Illustrative example. A logistics API receives a request to retry a shipment reservation after a timeout. The examples below are teaching artifacts, with invented IDs and results. They are not a customer deployment or an executed Proof run.
The request says “retry failed reservations.” That leaves a consequential question: what if the service committed the reservation but its response was lost? Retrying with a new identifier could reserve the same stock twice.
Source: interface agreement v3, section 4 (illustrative)
Stakeholder outcome: a retry must not reserve stock twice.
Requirement SW-REQ-241, revision 2:
Repeating the same reservation key and payload within 24 hours
returns the original reservation ID and creates no new reservation.
Conflict case:
The same key with a different payload is rejected without a write.
Risk: duplicate allocation after a lost response.
Authority: API owner approves this scope before implementation.
Change: retry client and reservation endpoint.
Evidence plan: execute retry, conflict and normal-request checks;
inspect reservation rows as well as the HTTP response.Record observations, including the missing one
| Check | Example recorded observation | What it supports |
|---|---|---|
| Commit succeeds; response is dropped; client retries | Both responses identify reservation R17; database contains one row for the key. | Sequential retry after this injected timeout. |
| Repeat key with a changed quantity | Request rejected; row count and stored quantity unchanged. | Conflicting payload causes no additional write. |
| Submit a new key | New reservation created with the requested quantity. | Normal creation still works in this scenario. |
| Send concurrent requests to two replicas | Not executed. | No conclusion about concurrent duplicates. |
Bind those observations to the exact implementation and test revisions. Retain the database version, retry configuration, fixture data and fault-injection method with the logs. A green client test that checks only the returned status would miss the duplicate write.
The open concurrency check matters to the stated promise. Keep the change pending until it is satisfied, or obtain an authorized, explicit scope amendment or exception. List every material gap in the verification report.
Apply the workflow to your own change
- Choose a bounded behavior. Start with a request, integration boundary and accountable owner.
- Recover and reconcile intent. Compare the request with existing requirements and source material. Resolve conflicting promises before treating a draft as authoritative.
- Review the evidence plan. Include preserved behavior, relevant failure cases and any required independent review.
- Execute at the reviewed revision. Preserve artifacts from the run. A generated test or a link to a test is not an observed result.
- Record the decision and carry it forward. Retain the approved obligation, all material gaps and the basis for acceptance. Reassess affected evidence when that basis changes.
Proof provides requirement, traceability, verification and Change records for this work. A complete automated AI4SDLC workflow or program approval does not follow merely from using those primitives. Start with an inspectable record and make manual steps explicit.
Guidance and scope
Sources checked 2 October 2026: Requirements Engineering, GA, updated 31 December 2025; AI-Augmented Testing, GA, updated 26 December 2025; and the guidance lifecycle. The lifecycle describes GA material as stable recommended guidance. This walkthrough does not establish compliance, certification or authorization to operate.