Explainer
How to track a revised source document in an industry story
The short answer
A stable URL can point to a changed document. Record the source’s version or date, the retrieval time and the specific passage used. When a source changes, compare the relevant claim before revising the article.
In this article
A reader follows a source link and finds a different number from the one quoted in an article. There are several possible explanations: the article misread the source, the source was revised, or the link now leads to another edition. A saved URL alone cannot distinguish them.
Keep three records separate
Illustrative example
| Record | What it identifies | What it does not prove |
|---|---|---|
| Source URL | The address consulted | That the contents will stay unchanged |
| Source version | The document or snapshot used | That every claim in it is correct |
| Article revision | The explanation published by the editorial desk | That the underlying source was updated on the same date |
At minimum, record the document title, publisher, stated date or version, retrieval time and the passage or table used. A page number or section identifier helps another reviewer find the evidence. If the source has no version label, say so rather than constructing one that looks official.
The W3C Data on the Web Best Practices recommends version indicators and version history. For editorial work, the useful principle is that readers and reviewers should be able to tell which version supports a statement and what changed between versions.
A hypothetical revision trail
Suppose a fictional annual report is released on March 4. An article cites Table 2 on March 6. On March 12, the publisher replaces the PDF at the same URL and adds a note correcting Table 2. The article’s March 6 publication date remains a historical fact; the source’s March 12 revision creates a new review task.
The reviewer compares the old and new versions of the relevant table, recalculates any derived statement and checks whether the conclusion changes. If the article needs a correction, the correction should identify the changed claim. Merely updating the article date would hide the substantive difference from a reader who saw the earlier version.
What a file digest adds
A recorded cryptographic digest can distinguish byte-identical copies from changed files. NIST’s Secure Hash Standard provides the technical background. A changed digest does not identify which sentence changed, and an unchanged digest does not establish that the source’s interpretation was sound.
A source-review record and the source file are also different objects. Hashing a note that contains a URL proves something about that note, not about the bytes of the page at the URL. Keep the hash’s scope explicit. Our checksum guide explains this boundary in more detail.
Close the loop in the published explanation
- Identify the source version or stated date beside the factual claim.
- Keep original and revised values distinguishable in the review record.
- Recalculate dependent tables, captions and summaries.
- Update related articles only where the changed evidence affects them.
- Add a concise correction note when a published factual statement changes.
This method is useful for gaming industry reports, technical standards and company documentation alike. It does not require pretending every source is a permanent archive. When an earlier version is unavailable, state that limitation and avoid claiming a comparison that could not be performed.
