Start with one concrete diff

Consider an invented research rule. Version 1 says: include a current source for each operational claim; mark an unsupported claim unknown. Version 2 says: include a current source when available; otherwise use the latest saved source. Only a few words changed, but the handling of missing evidence changed substantially.

Before accepting Version 2, ask what current means, how old a saved source may be, whether the period must match, and whether the fallback must be labelled. A clean text diff identifies edits. A behavior diff explains why they matter.

Write a four-line change card

Attach a short change card to the proposed version. Its purpose is to make the next review concrete enough that another person can disagree with it.

  • Before: absent current evidence produces unknown.
  • After: absent current evidence may invoke a saved source, under an explicit age and period policy.
  • Affected case: the report is missing, but an older disclosure exists.
  • Unresolved decision: should an older disclosure support a current claim, or only a separately labelled historical statement?

Compare versions on fixed paper cases

Use the same invented source pack for both versions. Case A contains a matching current disclosure. Case B contains only an older disclosure. Case C contains two contradictory documents. State each version’s expected response before reviewing any proposed output.

If the intended difference is only the older-source fallback, Case A should not acquire a new conclusion because the wording was revised. Case B should expose the exact fallback condition. Case C needs a disagreement policy rather than an assumption that the most recent-looking number wins. This is a comparison plan, not a report of executed tests.

Define what acceptance covers

A useful acceptance note identifies the version, changed rule, permitted source basis, unresolved exclusions, and intended task. For the hypothetical example, a reviewer could accept a labelled historical fallback for a draft report while declining its use in a current-state conclusion.

OWASP’s agent guidance recommends binding approval for sensitive actions to the specific action and parameters, with independent validation before execution. A strategy review is an additional meaning check; it should not be confused with authorization to carry out an external action. This article describes a review practice, not a product control.

Preserve the earlier decision

Keep the earlier wording, reason for change, new acceptance note, and comparison cases together. When a later output is questioned, identify which version actually governed it. Replacing the old text without preserving that link makes the disagreement harder to diagnose.

Also specify a rollback decision: what finding would lead the reviewer to restore the earlier rule or pause use of the revised one? An explicit condition is more useful than an open-ended promise to monitor quality. A rollback preserves a prior choice; it does not prove that the prior choice was correct.

Method, sources, and limits

The two versions and change card are original hypothetical examples. OWASP guidance was checked on 26 October 2026. No performance experiment, customer outcome, or implementation assessment was performed. Reviewing a diff can clarify intended behavior without establishing financial merit or eliminating model uncertainty.

Sources & checking dates

Primary references and the product release used for this guide. A source supports the claim attributed to it; it does not endorse Thesis Lab or validate an example's investment outcome.

  1. OWASP: AI Agent Security Cheat Sheet ↗Checked 2026-10-26

Educational examples are hypothetical unless explicitly identified as a dated source observation. Product details can change after the update date.