Snapshot the Source Before You Ask AI to Cite It

A link is not always stable evidence. A product page can be revised after you retrieve it. A policy page can silently replace its old terms. A documentation URL can keep working while its examples, version, or caveats change. If an AI drafts from the page you fetched this morning and a reviewer opens the live URL next week, they may be looking at different material while both sides think they are discussing the same source.

The practical move is to snapshot a source before you ask AI to make claims from it. Keep the original URL, but also save the retrieved representation in a controlled evidence store and write a small receipt describing exactly what was fetched. Draft from that snapshot. Later, a reviewer can check the same bytes—or at least the same saved text—rather than reconstructing the answer from a moving target.

HTTP already recognizes that one resource can have multiple representations over time. RFC 9110 defines an ETag as a validator that differentiates representations of the same resource, including those created by state changes over time.^[1] It also notes that an entity tag can be a more reliable validator than a modification date when dates are inadequate or inconsistently maintained.^[1] The broader preservation problem is real enough to have a web protocol: RFC 7089’s Memento framework provides access to prior resource states through datetime negotiation and TimeMaps.^[2]

Save the evidence, not just the address

For each source that may support a consequential claim, collect two things:

• An evidence artifact: the response body as retrieved, in a durable location with restricted access where appropriate.
• A retrieval receipt: the original URL, final resolved URL, retrieval time, content type, response status, validator headers when supplied, a content hash you compute, and the path or object ID of the saved artifact.

The artifact answers “what did we read?” The receipt answers “where did it come from, when did we obtain it, and how can we detect change?” Neither replaces the other. A hash without a preserved body cannot show a reviewer the evidence. A saved file without the source URL and retrieval metadata cannot show its provenance.

Do this before an AI summarizes, extracts, or cites the material. Once a draft has mixed several live pages into fluent prose, it is difficult to tell which revision supported which sentence. A snapshot makes the boundary explicit: the model may use this retrieved representation, not an imagined current page.

Copy this source-snapshot contract

Use this in a retrieval wrapper, research checklist, or evidence table. It is deliberately provider-neutral.

BEFORE DRAFTING FROM A WEB SOURCE

1. FETCH ONCE
   requested_url: [the URL selected for evidence]
   retrieved_at: [UTC ISO-8601 timestamp]
   final_url: [after redirects]
   http_status: [status]
   content_type: [response type]
   etag: [response ETag or null]
   last_modified: [response Last-Modified or null]

2. PRESERVE THE REPRESENTATION
   artifact_id: [stable evidence-store ID]
   artifact_path: [controlled path or object URI]
   body_sha256: [hash of saved response bytes]
   extraction_version: [parser/text-extractor version, if used]

3. WRITE A RETRIEVAL RECEIPT
   source_id: [stable local ID]
   title_as_retrieved: [page title or document title]
   claim_scope: [what this source may support]
   locator: [heading, paragraph, page, or character range]
   archive_url: [Memento/archive URI if available, else null]
   access_notes: [login, locale, paywall, or rendering limits]

4. DRAFT WITH BOUNDARIES
   - Cite the original URL for reader-facing provenance.
   - Link the source_id to the saved artifact for internal review.
   - Quote or paraphrase only passages present in the artifact.
   - If the live page now differs, say which retrieval timestamp the claim uses.

5. BEFORE A HIGH-IMPACT DECISION
   - Re-fetch the live source.
   - Compare ETag when meaningful and compare a new content hash.
   - If material changed, re-review the affected claims; do not assume the
     old statement still governs.

An ETag is useful only as a server-provided change signal. Treat it as opaque: record it, compare it for the same resource, but do not infer a publication date or semantic version from its characters. It can be absent, weak, or based on a representation that varies by locale or content negotiation. Your own hash identifies the exact bytes you preserved; it does not prove who authored them or make an untrusted page authoritative.

Keep citations readable while preserving reviewability

Reader-facing prose should normally cite the canonical or original URL. An internal artifact path is not a public citation, and it may expose private research material. Instead, give each source a local ID that joins the article’s claim ledger to the saved snapshot. A reviewer should be able to start at a cited claim, open the receipt, inspect the exact saved passage, and then compare it with the live source if freshness matters.

This also helps with sources that legitimately have versions. If a vendor’s release notes change, do not silently overwrite yesterday’s evidence file. Save a new artifact and receipt. Link the two records with supersedes or checked_against so the research trail shows whether a claim was updated, narrowed, or retired. Memento’s model makes the same distinction explicit: an archival response can carry a Memento-Datetime while linking back to the original resource.^[2]

Failure mode: treating a snapshot as permission to keep using stale facts

A preserved page proves what you retrieved, not that it remains applicable. For time-sensitive policy, pricing, security, legal, or product behavior, re-check before acting. A snapshot can also create privacy, licensing, and retention obligations; do not automatically archive personal data, restricted documents, or pages you are not authorized to store. Set access controls and a retention rule before building an evidence bucket.