Checked Date Citation Checklist

Checked Date Citation Checklist helps a curator decide what to record when a note depends on an external source that may change.

Start with the checked date. Publication date and checked date are different. Publication date says when the source was created. Checked date says when the curator verified that the source still supported the claim. For product documentation, pricing pages, API references, travel rules, legal guidance, and platform policies, checked date is often more useful than publication date because the page can change silently.

Next record source granularity. A homepage link is usually too broad. Point to the exact section, heading, release note, table, API endpoint, paragraph, report page, or archived snapshot when possible. If the source has no stable anchor, describe the path: document title, section name, and visible heading. A future reader should not need to search an entire site to recover the evidence.

Then write the supported claim. Keep it narrow. A source that says “feature available in selected regions” does not support “feature available everywhere.” A source that describes a pilot program does not support a permanent rollout. The supported claim should preserve conditions, limits, dates, versions, and uncertainty.

Add change risk. Stable concepts, historical events, and fixed definitions can be marked low risk. Product specs, prices, API behavior, search rankings, regulations, and platform policies are higher risk. If the claim is high risk, the note should either include a re-check reminder or avoid making a strong evergreen statement.

Finally note what was not verified. If the curator checked only the public docs but not a live API response, say so. If the note relies on one source and lacks independent confirmation, say so. A strong citation trail is not only about proving a claim; it is also about showing the limits of the check.

Checked Date Citation Checklist

// COMMENTS

ON THIS PAGE