New independent field guide, published 17 October 2026. Examples are illustrative. The historical directory records linked below are separate source context, not current recommendations or earlier versions of this essay.
A date becomes useful only when the event it describes is clear. Published, captured, retrieved, reviewed and revised can all appear beside one directory entry, yet they refer to different actions and sometimes different objects. Replacing them with one generic updated label can make a record look simpler while making its history impossible to interpret. This guide develops a lightweight provenance model for a resource collection, with invented examples and practical fields. It explains how to preserve uncertainty without guessing a historical publication date and how to document new editorial work without borrowing the age of the material it discusses.
Identify the object that each date belongs to
A publisher's original document, a saved capture of that document and a directory's description of it are separate objects. They can have different creation and revision events. If a fictional map was published decades ago, captured last year and described by a new directory today, today's description is not itself decades old. The date beside it should not imply that it is. Begin the record by naming the objects and their relationships, even if the internal system uses only simple identifiers rather than a formal provenance vocabulary.
This distinction also applies when the same URL serves changing content. An address can remain stable while the representation changes. A date obtained from one saved version should not automatically be assigned to every later version at that address. Store enough version context to understand the claim: capture identifier, source address and the relevant observed content. A label such as historical page reviewed today combines at least two events, so the record should retain them separately. The public interface can present them compactly without erasing which object and action each timestamp belongs to.
Do not infer issuance from a capture timestamp
A capture timestamp records a saved state at a particular time. It does not by itself establish when the source was first published. The material could have existed earlier, been revised or displayed a date with another meaning. Dublin Core's metadata terms distinguish formal issuance from modification and other date properties, illustrating why event labels matter. A directory should preserve a visible printed date when relevant, but avoid silently assigning it a publication meaning that the source does not establish. Unknown is a legitimate metadata state; a guessed date is a new unsupported claim.
Consider an invented page saved in June whose body announces a meeting in September without giving a year. The capture provides context, but not enough to assert the meeting year with certainty. An editor can record the exact announcement wording and the capture date separately. A later independent source might resolve the ambiguity, in which case the evidence and revision can be added. Until then, do not manufacture precision through calendar arithmetic or an assumed relationship between the capture month and the event. The record should show what is supported, not merely what seems likely to fit.
Treat review as an event with a scope
A review date is incomplete without saying what was reviewed. An automated response check, an inspection of a download and a substantive assessment of a resource's coverage are different activities. A generic checked today label can imply all three when only one occurred. Use a concise scope note internally and expose the relevant distinction publicly. In a fictional collection, address response observed on a date is narrower than document contents reviewed on that date. Both can be useful, but one must not be used to imply the other.
A scheduled review is not a completed event. Keep planned dates in a queue separate from actual observations and decisions. If a check could not be completed, record the attempt and its limitation rather than updating the record as if verification succeeded. This matters when a site rejects automated requests or requires a workflow the checker cannot perform. The log can state the response observed and leave the content judgement unresolved. That preserves useful evidence while preventing a maintenance dashboard from inflating completed work simply because a job ran or a request was attempted.
Preserve the chain from source to new description
W3C's PROV model provides a vocabulary for entities, activities and their relationships. A small directory can borrow the underlying idea without implementing a complex graph. Record which source an editor used, what action transformed it and which new description resulted. For an invented archive note, the source might be a capture, the activity an annotation written after review and the result a new catalogue record. A reader can then distinguish the historical source's claims from the modern editor's explanation of what the source establishes and what it leaves uncertain.
A digest can help verify that a locally preserved file has not changed, but it does not establish the truth of its contents or the identity of its author. Record that limited role clearly. The same applies to a screenshot: it can preserve a visual state without preserving every linked file or interactive function. Provenance is strongest when it describes the actual artefacts and transformations rather than collecting impressive technical fields with unclear meaning. A small, accurate chain is more reusable than a large metadata object that quietly confuses file integrity, publication history and factual verification.
Document revision without rewriting the past
When a description changes, preserve the previous version or enough change history to explain the difference. Correcting a mistaken URL is different from expanding subject coverage or reclassifying a resource. A useful event note identifies what changed, why and on what evidence. Do not retroactively edit a capture date to match a later correction. Likewise, do not assign an old source date to newly written commentary merely because the commentary concerns that period. New editorial work has its own publication history, even when every example and source it discusses is historical.
An invented correction might replace an inferred event year with an explicit uncertainty note after the editor discovers that the source never stated the year. The new record should acknowledge that change rather than silently maintaining the false impression that the date was always known. For a current directory, some small copyedits may not need a prominent public correction notice, but substantive changes to meaning deserve an understandable history. The practical standard is whether a later reader can reconstruct which claim was supported at which point, not whether every punctuation adjustment has been turned into a ceremonial event.
Show readers the dates they need to interpret the record
A compact public record can display source address, capture date, printed date label if established, annotation publication date and review scope. Not every internal event needs equal prominence. Choose the fields that prevent likely misunderstandings for this collection. A historical catalogue particularly needs to distinguish source time from new editorial time. A maintained recommendation may need a recent content-review date and its scope. Do not use a fresh sitewide footer year as evidence that every entry has been inspected recently. The age of the interface and the age of the evidence are separate matters.
This edition follows that separation: its new guides and annotations carry their actual publication dates, while old directory records retain capture provenance without invented first-publication dates. Five historical homepage versions are separate saved states, not evidence of a currently operating submission service. The general habit is simple: name the object, name the event and preserve the evidence connecting them. Dates then become useful coordinates in a record's history instead of decorative signals of freshness. A reader can tell what was old, what is new and what has actually been checked without having to guess which meaning the word updated was intended to conceal.
References & further reading
- Dublin Core Metadata Initiative — Metadata terms: issued, modified and provenance ↗
- W3C — PROV Model Primer ↗
- IETF — RFC 7089: Memento ↗
From the recovered archive
- Directory homepage — 2010-11-17 · captured 17 November 2010
- Submission rules — historical policy · captured 28 November 2010