Connecting software changes to approval evidence

A claim needs an object

Anthropic’s Claude Code guidance (accessed 2026) makes the requirement explicit. It asks for “evidence rather than asserting success: the test output, the command it ran and what it returned”. The distinction matters because a completion summary and an execution result perform different jobs. The summary explains what the agent believes it accomplished. The output records what a particular command observed under particular conditions.

We apply that guidance by attaching the observation to its source revision. A test result without that identity leaves the reviewer to reconstruct which patch was checked. An approval without a scope leaves the next person to infer what the reviewer accepted. Both omissions weaken the connection between the visible result and the underlying application described in what separates an AI-built demo from a working application.

OpenSSF’s SLSA v1.0 (2023) describes build provenance recording the platform, process and top-level inputs that produced an artifact. That record establishes origin. A review decision adds who accepted a particular change, on what evidence and with which qualifications. We connect these records through the same source revision so an artifact can be traced to the decision covering it.

The figure contrasts the agent’s completion claim with a retained decision record. Each check result identifies the source revision it tested. The command and output for revision X join the named approver’s rationale; the decision record links to build provenance identifying X. A later edit creates revision Y, which needs checks and a decision covering Y. The old evidence remains available as history without silently authorising the new work.

Capture the observed result

Friel’s OpenAI Cookbook guidance on execution plans (2025) describes a living record of progress, decisions, unexpected findings and acceptance outcomes. Completed work remains distinguishable from work still to be done. This makes the status of a requirement inspectable while a long task is underway. A final summary can then refer to observations collected during execution instead of reconstructing them from memory.

For software review, we recommend retaining the test command and its output alongside the source revision and environment. The environment includes dependencies and configuration that affect the result. These references let another reviewer locate the observation and determine what it covers. The record should also identify a check that was skipped, interrupted or unable to start, because those outcomes warrant different decisions from a pass.

Coverage needs its own explanation. A successful rendering test demonstrates the behaviour that test exercises. An access-control requirement needs evidence about whether disallowed actions are rejected. Naming the requirement beside its check lets the reviewer identify that distinction before accepting the feature. More output is useful only when it helps establish the behaviour under review.

When an edit follows testing, the retained evidence still identifies the earlier revision. The reviewer should compare the edit with the scope of those checks and request fresh evidence for affected behaviour. This preserves the value of earlier work while making the new decision explicit. An unchanged status label cannot make an old command result describe code it never ran against.

A known failure can also be part of an acceptance decision. We recommend retaining the failed result, the reason for accepting it and the person authorised to make that exception. Its scope should identify which requirement or environment is affected. The exception then remains visible beside the approval, so a later reader can distinguish an intentional decision from a missing check.

The decision record should lead directly to these observations. A long conversation may contain the relevant output, but finding it should not depend on remembering where the agent discussed a problem. Stable references to the command results and reviewed revision give the decision a usable basis. The agent’s explanation remains helpful context alongside those observations.

Preserve the decision's scope

NIST’s AI Risk Management Framework 1.0 (2023), GOVERN 2.1, calls for documented roles, responsibilities and communication for managing AI risk. We apply that principle to acceptance by naming the approver and the authority exercised. A build account identifies who ran a process; an approver identifies who accepted its result. Recording both keeps execution and responsibility distinguishable.

SLSA also distinguishes recording provenance from protecting its integrity. Higher build levels add protections against forgery and tampering. Approval evidence raises a parallel concern: the author of a change should not be able to silently replace the results after review. We recommend storing the retained observations where changes are controlled and visible, with access appropriate to the evidence they contain.

The release check can then compare the artifact’s provenance with the revision covered by the decision. A mismatch is a reason to inspect what changed before proceeding. A matching revision still needs the review’s qualifications to travel with it, including accepted exceptions and environmental limits. The identity link makes the decision traceable; the evidence and review determine its substance.

Teams can assess this practice by following one recently accepted change backwards. Start with the artifact, identify its source, find the corresponding command results and read the review decision. The route should reveal what was checked and why the reviewer accepted it. A missing revision, inaccessible output or unexplained exception identifies a specific repair to the recordkeeping process.

The confidence measurements make observation worth insisting on. Published provenance and work-record guidance supplies a way to retain it during development. Connecting that observation to a named decision and a fixed revision makes approval explainable after the conversation has ended. A later change should earn a decision that covers the work actually being delivered.