Skip to content
Reliable Context
Read the paperRequest access

Methods

Detecting source drift

Compare current source content with the retained cited version and reassess changed support.

Problem

A source can continue to load at the same address while the passage used for a claim changes or disappears. An HTTP success says little about whether an old citation still supports its value. Drift can reflect correction, formatting, a new reporting period or replacement of a file. Detection requires a retained baseline and a claim-level comparison. The task is to decide whether the asserted value remains supported, not merely whether bytes or page layout changed.

Steps

  1. Fix the baseline

    For each assertion, retain the source version, passage, locator, reading date and content digest used when the claim was recorded. State any effective period or qualifications in the passage. Without this baseline, a reviewer cannot distinguish a source change from an earlier citation mistake. Keep it even after the live source is revised.

  2. Observe a new version

    Retrieve the current source under appropriate access rights and record observation date, URL, version and digest. Check redirects, substituted files and changes in publication metadata. Compare old and new representations at the cited passage and nearby context; a global byte difference may come from navigation or formatting while the assertion remains intact.

  3. Classify the effect

    Label whether the passage is unchanged, moved with the same meaning, qualified, contradicted, removed or inaccessible. If the source now reports a different period, avoid treating that as a correction to the earlier period. If meaning is uncertain, retain the conflict and seek review. Cite both versions so another reader can inspect the difference.

  4. Revise the claim state

    Where support changed, mark the assertion for review and record a new decision with its own date and grounds. Preserve the earlier assertion and baseline for historical replay. Do not silently update a value to match a revised page; downstream conclusions may have relied on the prior state, and changed wording does not itself establish a new operational answer.

Checks

  • Old and new versions are independently inspectable.
  • Comparison assesses meaning at the cited passage.
  • Affected assertions and downstream uses are identifiable.
  • Historical support survives revision.

Pitfalls

  • Using HTTP success as proof of continued support.
  • Treating every byte change as factual correction.
  • Replacing the earlier source copy.

A worked example

A fictional record cites a regulator's page for a fee schedule. At the time of reading, the page listed a fee for a service. The baseline is stored: the passage, the locator, the date, the digest of the page and a note that the page states an effective period.

A monthly check retrieves the page and compares the passage. In one month the digest changes but the fee passage is unchanged: the navigation menu was redesigned. In the next month the fee has a new figure and a new effective date. The check classifies the first as no effect and the second as qualified, since the old fee applies to the old period and a new fee to the new one. The affected assertion is marked for review, both versions are linked, and nothing downstream is silently updated. A report built on the old fee remains reproducible, and a report built next month can use the new one with its date.

Variations and edge cases

Servers say a little about change. HTTP defines validators such as entity tags and modification times that let a client ask whether a resource has changed, but servers vary in how faithfully they set them, and a page can change while its headers do not. They are useful as a cheap first filter and a poor basis for a conclusion. A final conclusion should rest on comparing the cited passage.

Sources disappear, redirect to unrelated pages, or start returning an error page with a success code. Research on reference rot has measured how often links in scholarly articles no longer lead to the content that was cited. The check should therefore test that the retrieved page is about the same thing, for example by looking for the cited passage or a stable heading, and should classify inaccessible and replaced as distinct outcomes.

Deciding what to monitor

Monitoring everything is expensive and noisy. Prioritize citations that support consequential values, sources with a history of revision, and values with expiry dates. Match the frequency to the source: a legislative database that changes in defined releases can be checked after each release; a news page may need no check at all once retained. Record each check and its outcome, including no change, so that the absence of alerts can be interpreted.

How the method is checked

Seed tests: change a retained copy by hand in ways that should and should not matter, such as a reformatted footer versus an altered figure, and confirm that the classification is right. Review a sample of no-effect classifications by reading both versions. Confirm that a changed source never overwrites the baseline and that the alert reaches someone who can act.

Related terms

See also

Further reading in the articles

References

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Test this method on one entity.

Name an entity where "Detecting source drift" would be checked in practice, with its sources and its readers. We reply with what a first record would cover and what it would need from you.

Open a structured enquiryContact and what happens next

Or write to [email protected] in your own words.