Verification is not permanent. A mirror claim should be reviewed again when the facts supporting the previous result change.
Reverify after a destination change
If the final hostname or redirect path changes, the old result no longer covers the full journey. Treat the new destination as a separate object of review.
Document both the previous and current path so the change remains visible.
Reverify after infrastructure changes
Nameserver, hosting and certificate changes can be normal, but they alter technical context. A material shift should trigger a fresh observation.
Infrastructure evidence alone does not decide legitimacy; it identifies when older evidence may be stale.
Reverify after source corrections
When the publisher retracts, edits or replaces a claim, update the mirror status and preserve the correction date.
Do not keep an active label based on wording the source no longer supports.
Reverify after unexplained downtime
Temporary unavailability is not automatically malicious, but a long or repeated outage can invalidate an operational label.
Use maintenance, offline or pending states according to documented criteria.
Set both scheduled and event-based reviews
A calendar interval catches quiet changes, while event triggers catch important updates immediately. Use both methods for a resilient status process.
Each new review should produce a dated record rather than overwriting history without explanation.