Your Approval Belongs to a Version

It proved something about the version and conditions the check examined. A passing result doesn't automatically describe the next edit, a different dependency or a newly approved requirement. If the factory carries that result forward without checking what changed, it can present yesterday's evidence as permission to ship today's work.

Bradley Gibbs's article on code generation and verification describes recording which candidate an independent evaluator examined, what checks ran and what remains unverified. That connection matters at handoff: the reviewer needs to know which work the evidence describes. The article presents a method to test in your own workflow, rather than measured savings.

Gunner Technology's position is that this connection must survive every later edit. A candidate is the particular version of a change being considered for release. Give it an identity the machinery can compare, such as a Git commit identifier, and keep the check results attached to that identity. A reassuring completion message cannot stand in for the record.

Run a check again when something it depends on changes, or when you cannot establish that its earlier result still applies. That includes the implementation, the expected behavior and the conditions used to build or exercise the software. The release machinery should make that decision from recorded inputs and policy.

Consider a hypothetical change to an order export. The candidate passes a test that excludes archived records. During review, the product owner decides archived records should appear. The old test result still records what happened, but it no longer establishes compliance with the request. Update the approved requirement and expected result, change the implementation, and check the new candidate.

A repair after review needs the same discipline. If an agent changes shared date handling to fix the export, earlier results for other date-sensitive behavior may no longer apply. As we argue in Build the Factory Backward From the Verdict, define the evidence needed to accept the work before treating the implementation as finished.

No, provided the factory can establish which checks the edit affects. Reusing evidence needs a reason the system can inspect. An agent saying that a change is harmless isn't enough, especially when the same agent made it.

Start with a conservative rule: changes invalidate the checks they could affect. Narrow that rule only when you can reliably trace the relevant dependencies. A spelling correction in isolated documentation may leave application tests applicable. A build configuration change can reach much farther than its small diff suggests. The amount of text changed doesn't determine the amount of evidence disturbed.

Keep the reason for reuse in the record. Show what changed, which earlier results remain applicable and which checks ran again. If the factory cannot justify the boundary, run the broader checks. Paying for verification is a better decision than quietly treating uncertainty as a pass.

Human approval needs reconsideration when the work or assumptions behind the decision change. Preserve the original decision as history, then identify what the person must judge again. Mechanical checks can establish behavior; they cannot silently expand what a person agreed to release.

Give the reviewer a short account of what changed since their decision. Include the current candidate, the affected requirement, fresh results and any remaining uncertainty. Ask the specific question that reopened. The distinction in Code Review Needs a Named Job applies here: the person should know which consequence they are accepting.

Keep the builder's authority separate. It can repair the candidate and request another evaluation. It shouldn't be able to preserve approval by editing the evidence record or declaring its own change exempt. People still decide what gets built and whether the returned work is right. The factory carries the repeatable comparison and checking.

Before release, compare the software being shipped with the software the evidence and approval describe. Record the built artifact too: the deployable package can depend on inputs beyond the source code. If those identities or required inputs don't match, stop and resolve the mismatch.

Start in a repository you own. Take an already checked candidate, alter behavior and confirm the release route refuses the old evidence. Then change an approved requirement and confirm the old approval cannot carry the new meaning. These exercises test whether your machinery enforces the connection it claims to preserve.

When an edit sends work back through checks, let the factory assemble the record and run the route. A person shouldn't have to remember which green result became stale. They should arrive at a decision with current evidence for the version in front of them.