Build a Source Freshness Ledger Before “Current” Becomes Stale

A citation proves that a source was consulted. It does not prove that the cited claim is still current. A product gains a feature, an agency revises a rule, a software page changes its requirements, a paper is corrected, a link begins redirecting, or a current officeholder leaves. The URL may survive all of those changes.

A source freshness ledger is a small record beside each change-sensitive claim. It captures the exact claim, the source and locator, the source version, when it was checked, how quickly the claim can change, what event would invalidate it and what happened during the latest review. The purpose is not to make every fact permanent. It is to make revalidation deliberate.

Freshness belongs to the claim, not the webpage

A ten-year-old page can accurately describe a stable mathematical definition. A page updated yesterday can repeat an obsolete compatibility table. “Published” and “updated” dates are evidence about the document, not automatic proof about every sentence.

Judge the claim's change surface. Physical constants, historical dates and definitions maintained by standards bodies may be relatively stable. Prices, availability, software requirements, safety recalls, public officials, service features, legal rules and travel access can change quickly. Even within one page, separate statements may deserve different clocks.

HTTP caching offers a useful analogy, not a rule for editorial work. RFC 9111 distinguishes a response's age from its freshness lifetime; a response becomes stale when age exceeds that lifetime. Human knowledge has no universal max-age header. You have to choose a review interval and revalidation trigger that fit the claim.

The nine-field freshness record

Keep the exact claim concise. “Works with phones” cannot be verified. “The manufacturer's support page listed AirPrint support for model X when checked on date Y” can. The narrower record prevents silent expansion from one supported fact into a family-wide promise.

Assign volatility before assigning a date

Use a simple tier only if the team understands what it means. A useful starting framework is:

• Low volatility: definitions, completed historical events and standards with explicit editions. Review when a new edition or correction appears, or during a long-cycle audit.
• Medium volatility: maintained guidance, product manuals for supported models, institutional procedures and research syntheses. Review on a scheduled cycle and when the owner announces a revision.
• High volatility: software features, compatibility, prices, availability, schedules, current officeholders, alerts, recalls and active rules. Check close to publication and again before a decision that depends on them.

Stakes modify the tier. A low-volatility claim used in a safety-critical decision may deserve formal verification. A high-volatility claim in an illustrative aside may be removed rather than maintained. The ledger should reduce risk and upkeep, not preserve trivia forever.

Prefer event triggers to calendar theater

A quarterly reminder catches some changes late and wastes time on others. Add observable triggers: a major software release, a new model year, an agency rulemaking, a product discontinuation, a court decision, a standards revision, a recall notice, a DOI correction or a support-page redirect.

Not every trigger can be automated. Subscription alerts and change monitors can surface events, but a changed page does not tell you whether the claim changed. Conversely, a claim can become misleading because the surrounding context changed while the sentence stayed identical. Automation should open a review task, not silently mark the fact current.

The notification escalation ladder helps separate routine review queues from urgent invalidation. A safety recall or revoked credential may require immediate action; a minor wording revision can wait for the next maintenance window.

Run a claim-level revalidation

1. Open the canonical record. Do not rely on a search snippet, cached preview or old screenshot.
2. Match identity. Confirm organization, document, jurisdiction, model, edition and date.
3. Read the locator in context. Check definitions, exceptions, footnotes and whether the cited section still exists.
4. Compare the published claim. Mark it confirmed, narrowed, expanded, contradicted or unsupported.
5. Inspect downstream use. Find summaries, tables and recommendations that inherited the claim.
6. Record the result. Update checked date, reviewer, evidence and next trigger; preserve the previous state where accountability matters.
7. Correct visibly when needed. Change the page, date and note in proportion to the significance of the correction.

The citation-verification protocol is useful during step three. The source-provenance map prevents several copied summaries from masquerading as independent confirmation.

Preserve source state without confusing an archive for truth

When a decision needs evidence of what a source said at a particular time, retain an allowed copy, archive link, DOI, version tag, checksum or screenshot with context. Respect copyright, access controls, privacy and records policies. A local copy proves what was captured; it does not prove the captured statement was correct.

W3C PROV models provenance through entities, activities, agents, derivation, generation and invalidation. A small editorial ledger does not need to implement the full standard, but the distinction is valuable: the claim record is an entity, the review is an activity, the reviewer is an accountable agent and a revision creates a new state rather than erasing history.

For a disappearing service or export path, connect this record to the personal digital exit plan. Provenance is only useful if the evidence remains readable when the original platform changes.

A compact working example

Suppose a guide says a device supports a wireless printing standard. The ledger records the exact model, official support page, specification row, page date, checked date and “high” volatility because firmware and support policy can change. The triggers are a major operating-system release, the model moving to an archived-support category or the manufacturer's page redirecting. During review, the editor verifies the model list and tests no hardware unless the publication has actually performed and documented that test.

If the official page disappears, the result is not automatically “false.” Mark the source unavailable, seek a current manual or certified-products list, narrow the wording and avoid implying current support without current evidence.

Failure modes the ledger should prevent

• Changing an “accessed” date without reopening the source.
• Using a homepage as evidence for a model-specific compatibility claim.
• Treating a current URL as proof that its contents have not changed.
• Refreshing the source but not the recommendations that depend on it.
• Assigning every claim the same ninety-day review cycle.
• Deleting an old state so nobody can reconstruct why a decision was made.
• Keeping a volatile fact merely because it is expensive to maintain.

Standards and authoritative references

• W3C PROV-DM: The PROV Data Model, for entities, activities, agents, generation, derivation and invalidation.
• RFC 9111: HTTP Caching, for the precise distinction between age, freshness lifetime and stale responses; used here as an analogy, not an editorial mandate.
• RFC 9205: Building Protocols with HTTP, which notes that content lifetime can differ from cache freshness and may need separate expression.
• NIST Information Quality Standards, for institutional responsibilities around quality, records and correction of disseminated information.