Define the freeze
One tempting assumption is that a trustworthy baseline requires discussion to stop. A baseline identifies an exact approved artifact, its scope, and its acceptance conditions. Think of a bookmark in a book: it preserves a position while reading continues. The useful distinction is between changing the artifact and learning something about it. These examples are illustrative, not reported test results.
A late comment can expose a mismatch
Suppose an approved API specification says an omitted page size returns 100 records. A reviewer then notices that a client expects every record when that parameter is absent. Closing discussion preserves the approval label but leaves the incompatibility unresolved. The comment itself does not alter the saved specification. It supplies a reason to test the client and decide whether to revise the contract, change the client, or explicitly accept the limitation.
Check the separation in practice
Save the approved version with a stable identifier and a reproducible export. Attach each later comment to that identifier. Record a disposition: clarification, deferred proposal, or proposed correction. Then run a simple check: can another person retrieve the same artifact and distinguish approval from unresolved discussion? For the API example, request a collection containing more than 100 records without a page size and compare the response with the client's expectation. A change to agreed behavior requires a newly approved version.
Hypothetical boundary: a moving policy
Imagine a frozen specification delegates access decisions to a vendor policy that can change without notice. The local file stays identical while permitted behavior changes. Decision rule: if an external change can invalidate an acceptance condition, pause decisions that depend on it until the policy is captured and the condition is rechecked. Renew approval for any changed contract. Otherwise, keep the baseline and log the observation. Unchanged bytes alone cannot guarantee unchanged meaning.