When a dependency changes, which approvals go stale?

When a dependency changes, which approvals go stale? Every approval whose evidence was produced from the old contents of that dependency, whether or not anyone recorded the link. A code review, a passing test run or a sign-off is a statement about specific file contents at a specific time. Change a file those contents rely on, and the statement no longer covers what is in the repository now. In practice, tools can only flag the stale approvals they know about: evidence tied to the changed file by a recorded hash or link. Approvals that depended on the file indirectly, through an import nobody recorded, go stale silently. And a stale flag says only that the bytes changed, not that anything broke. This page explains how to tie evidence to source, what staleness does and does not tell you, and a re-approval policy that fits AI-paced change. Test results specifically are covered in stale test results.

An approval is a claim about specific bytes

Most teams record approvals as if they were about tasks: checkout truncation, approved. What a reviewer actually checked was narrower: these files, with these contents, with these checks run against them. The approval is true about that snapshot and silent about any other.

Tying evidence to source makes this explicit. Record, next to each approval or check result, the files it relied on and a content hash or commit for each. Then staleness becomes a comparison rather than a judgment: if the current hash of any supporting file differs from the recorded one, the evidence no longer describes the code.

The hard part is the list of supporting files. The direct ones are easy: the files in the diff, the test file that ran. The indirect ones are where approvals quietly lose coverage. A review of an export feature relied on the shared rounding helper just as much as on the export module, even if nobody listed the helper as reviewed. If the helper is not in the evidence record, a change to it cannot mark the export's approval stale.

So staleness detection is only as complete as the dependency record, the same limit described in declared vs inferred dependencies.

What goes stale when shared code changes

Picture a change to a shared helper with three kinds of approval downstream.

Evidence about the helper itself: its tests, its review, a note saying it rounds to the nearest cent. This goes stale directly, and any hash-based record will flag it. In the October 30 regression probe on a BRAIN FLUID development build, evidence for the changed source flipped from current to stale in exactly this way [C6].

Approvals of features that declare a dependency on the helper. Treat these as stale too, because their evidence assumed the old behavior. A query that follows recorded links can list them [D6].

Approvals of features that use the helper without a recorded link. These are just as stale in reality and invisible on paper. In the same probe, the CSV export imported the helper without a declared link, so the query over declared relationships did not list it, even though its check now failed [D6]. The full sequence is in the blast radius of AI code changes.

A sensible default is to reopen review for the first two groups by rule, and to run a reference search for the third before accepting the change.

What a stale flag tells you, and what it does not

A stale flag tells you one thing: the bytes a piece of evidence was based on are not the bytes in the repository now. That is valuable because it is mechanical and hard to argue with.

It does not tell you the change broke anything. Most stale evidence is still true; a comment edit or a behavior-preserving refactor flags it just the same. Read stale as unverified again, not as failed.

It does not tell you the evidence was any good. A current flag means the files are unchanged since the check ran. If the check was too narrow, it is still too narrow. Matching hashes establish unchanged bytes, not factual truth or adequate checks.

It does not cover anything outside the recorded file list, as the export example shows.

It matters most at the moment of completion. If source changes after verification but before the work is accepted, the verification describes code that no longer exists. In a test on a later development build, changing the source after verification and before publication caused completion to be refused [D3]. Whatever tooling you use, compare hashes at acceptance time, not only when checks run.

A re-approval policy for AI-paced change

Agents change shared code often, so blanket re-review of everything downstream does not scale. A tiered policy does.

Tier 1, the changed files: always rerun their checks and re-review the diff. This is ordinary review.

Tier 2, declared dependents: rerun their checks. Re-review only if the shared code's behavior changed, not for a pure refactor with identical outputs. The reviewer writes one line saying which.

Tier 3, undeclared dependents found by search: rerun their checks, then add the missing link so they move to tier 2 next time.

Record the outcome against the new hashes, so the fresh approval is again tied to specific bytes. Keep the stale record rather than deleting it; a history of what was approved when helps when a regression surfaces weeks later.

Finally, decide who may clear a stale flag. If an agent can mark its own evidence current by rerunning a check it chose, the flag means little. Clearing should require the configured checks, run by something other than the agent's own report, which is the point of self-reported vs independent checks.

QUESTIONS

Does a code change invalidate earlier code reviews?

It invalidates the parts of a review that relied on the changed code. A review is a statement about specific file contents, so if a file it covered or depended on changes, the review no longer describes the code. Whether the old conclusion still holds needs a fresh check, which is often quick for small or behavior-preserving changes.

What does stale evidence mean in software verification?

It means a recorded result, such as a test pass or a review, was produced against files that have since changed. The result may still be true, but it no longer proves anything about the current code. Stale is a reason to verify again, not a sign of failure, and a current result only means the files are unchanged.

How do I track which files an approval depended on?

Record a commit or content hash for each file the approval relied on, including shared modules and test files, at the moment of approval. Compare those hashes when the work is accepted and whenever someone asks whether it is still approved. Add indirect dependencies found by reference searches, since anything left off the list cannot be flagged.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance
• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Stale test results Stale test results describe code that has since changed. Bind each result to a revision and rerun checks on every completion attempt.
• Self-reported vs independently run checks for AI agent work Self-reported vs independently run checks for AI agent work: why an agent's own "tests pass" is weaker than a check the system runs itself.
• The blast radius of AI code changes The blast radius of AI code changes: what one agent edit can break elsewhere, a worked rounding example, and how a reviewer finds affected features.
• Reopening work an AI agent already closed Reopening work an AI agent already closed: when new evidence shows a DONE task is wrong, reopen it with the evidence instead of fixing it quietly.