A passing test belongs to a particular version

A document passes its checks. Someone fixes a sentence, changes a heading, and exports it again. The old test report still says the document passed, but it now describes a version that is no longer being delivered. Even a small edit can matter when it changes pagination, references, or the condition the test actually inspected.

The integration specification for Boris, a native agent interface, makes this relationship explicit. Its completion evidence records the artifact revision that was checked, and later edits invalidate affected receipts. A receipt is the retained record of an executed check, including its inputs and result. The specification establishes that requirement; it does not establish a completed implementation of the entire verification system.

The practical question is which claims remain supported after a change. A test result need not be discarded merely because an unrelated file changed. It does need a defensible relationship to the delivered artifact and to every dependency that could alter its result.

An illustrative revision sequence

Consider a generated handbook whose acceptance criterion requires a readable table, wherever that table appears. In revision A, the table appears on page twelve and passes visual review. An editor then lengthens the preceding section, moving the table to the next page and reducing its available space. Revision B retains the same filename, but the earlier inspection cannot establish that its table remains readable.

Record a content hash for the exact document and a separate hash for its rendered output, linking the visual receipt to both so that, after the edit, a reviewer can identify revision B’s new render and inspect the affected pages wherever the pagination change propagates. Keep the earlier receipt as history, while marking the current criterion as awaiting verification.

The same principle applies to code. A unit test runs against one source revision, dependency set, and configuration. If an agent subsequently edits the function it tested, the prior passing result remains an accurate historical statement. It no longer supplies current evidence for the edited function.

A filename is therefore insufficient identity. Because a branch name can move and a working tree can contain uncommitted changes, record enough information to reconstruct the tested state, including local edits and generated artifacts that may have changed without receiving a new release number in the surrounding project.

Record the check’s execution conditions

A useful receipt names the command or review method, the artifact revision, environment identity, start and finish, result, and retained log. Include output truncation and skipped coverage. If a test runner found no matching tests, its successful exit should not silently become evidence that the expected suite passed.

For manual or visual review, record the actual object inspected and the criterion applied. “Looks good” cannot explain which pages or conditions were examined. A reviewer can be concise while still identifying the render, page range, and observed defect or acceptance result.

The environment can be part of the result. A document rendered with different fonts may wrap differently. Code tested against a different library version may take a different path. Preserve those conditions when they can affect the criterion, and rerun when a relevant environmental change makes the earlier result inapplicable.

Invalidate by dependency, then verify

Create an explicit mapping from acceptance criteria to their inputs. A layout criterion depends on the generated document, renderer, and required fonts, while a data-total criterion depends on source data and transformation logic, so an edit to the title may require another rendered review without invalidating a calculation whose inputs remain unchanged.

This mapping supports selective verification, but selective verification itself needs testing. Introduce a change known to affect each criterion and confirm that the system marks its receipt stale. Also change an unrelated input and confirm that the system preserves still-valid evidence. Excessively broad invalidation wastes time; overly narrow invalidation can certify an untested result.

Before delivery, compare the current artifact identities with the identities in the completion report. Any mismatch should produce a visible decision to rerun, inspect, or explicitly narrow the claim. Do this after final edits and export, since those steps can change the object the user receives.

For the handbook example, the final package should contain revision B and the render inspected for revision B, with the unchanged readability criterion supported by a receipt identifying the table’s current location. The earlier passing receipt remains available for investigation, but the delivery report points to the review of the document being delivered.

Source notes

Based on the September 2026 Boris specification’s revision-bound completion evidence. Handbook and code examples are illustrative.