When AI evidence changes, the prior support relationship should not survive silently.

Reverification is different from continuous monitoring.

Continuous monitoring can produce operational signals. Reverification addresses a narrower assurance question: does a previously accepted evidence relationship remain supportable after a material change?

The answer should not be inferred from a new file appearing in a repository. The package should compare versions, identify affected relationships, suspend prior reliance where necessary, and require a reviewer to examine the changed record.

Six events that should trigger renewed examination

The evidence relationship is the unit of reliance

A document does not support every claim merely because it exists. Support is a relationship between a defined artifact, a requirement or reviewer question, a system boundary, an acceptance rationale, a reviewer, and stated limitations.

When one of those elements changes, the package should identify which accepted relationships are affected rather than invalidating everything indiscriminately or allowing everything to remain accepted.

A reviewer-readable package change record

1. Prior package: package identifier, version, issuance state, and evidence manifest.
2. Current package: the new evidence manifest and system boundary.
3. Artifact comparison: unchanged, modified, added, removed, or expired records.
4. Relationship impact: accepted mappings affected by each material change.
5. Reliance state: continued, conditional, not established, or reverification required.
6. Reviewer action: new rationale, authority, limitations, acceptance, or rejection.

What should happen when a supporting artifact changes

The prior accepted relationship should move into a state that clearly prevents silent reuse. The package can retain the historical record while showing that equivalent reliance is suspended until a reviewer examines the replacement artifact.

This preserves two truths at once: the earlier package accurately records what was accepted at that time, and the current package does not misrepresent that historical acceptance as current support.

Why procurement reviewers care

AI products can change through model updates, prompt changes, retrieval-source changes, new data processing, configuration changes, or revised operational responsibilities. A reviewer needs to know whether the evidence package describes the system being purchased now, not a prior version that looked similar.

Explicit reverification reduces the risk of stale questionnaires, outdated testing results, or superseded policies continuing to circulate as if they remain current.

How this fits into an ATO Readiness Baseline

The Baseline establishes a point-in-time evidence position. It can record current accepted support, open gaps, reviewer limitations, and the chain-of-custody properties of the package. Where multiple package versions exist, a change record can identify evidence relationships that require renewed examination.