Release history should tell the truth

Release histories tend to become cleaner as they become less true. A scheduled date is retained even though the page was available earlier. A failed deployment disappears after the successful retry. A bulk correction makes many items look newly authored. A title change overwrites the name under which readers first encountered the work. The current site becomes orderly while the path that produced it becomes unintelligible.

A truthful ledger does not preserve every transient machine event. It preserves the transitions that change what the institution claims about the release. Planning, approval, public availability, announcement, correction, withdrawal, and republication are different events. They can occur at different times and be supported by different evidence.

The distinction matters because public history affects interpretation. A reader may want to know what was available when a policy debate occurred. An editor may need to distinguish a newly written essay from an older page whose metadata was repaired. An operator may need to know whether a campaign was intentionally replayed or accidentally duplicated. One mutable publication date cannot answer all of these questions.

Keep intention and event side by side

The planned release belongs in the ledger because it explains coordination: editorial calendars, embargoes, channel schedules, and review deadlines. The observed public release belongs because it describes reality. When they differ, the ledger should retain both and name the cause if known. Correcting the public date need not erase the original plan.

This is an append-oriented model. A correction adds a later event referencing the earlier one. The current site can project the best available public date, while auditors can reconstruct why it changed. The W3C PROV-O recommendation distinguishes entities, activities, and agents in a provenance model. A release ledger can use the same intellectual discipline without requiring a complex ontology: identify the artifact, the activity that changed its state, and the authority responsible.

Truthful history does not force one timestamp to impersonate the plan, the act, the discovery, and the correction.

Evidence should be proportional to the event. A build identifier and artifact hash may support a deployment. An HTTP observation may support earliest verified availability. A platform placement identifier may support scheduling. A version-control commit may support the authored change. No one item proves the entire release. The ledger connects them without claiming more than each can show.

The language of verification must remain careful. If no record establishes the exact first public moment, say “earliest verified” rather than inventing precision. If a platform accepted a schedule, record acceptance rather than future delivery. Honest uncertainty is more useful than a falsely exact history because it tells later investigators where the evidence ends.

A ledger should improve operations now

Provenance is often postponed as something needed only after a dispute. A good release ledger makes ordinary work easier. It prevents duplicate announcements by showing existing placements. It makes rollback safer by identifying coherent artifacts. It tells an editor which pages were corrected in bulk. It allows discovery surfaces to use actual release and modification facts rather than inferring them from filenames.

The ledger should use stable item identifiers and event identifiers. Titles and URLs can change; identity should not. Events should carry timestamps with explicit zones, the type of transition, the actor or system, relevant artifact revision, and references to supporting evidence. Free-text notes remain useful for unusual cases, but common transitions should use a small controlled vocabulary so they can be validated.

Privacy and security still apply. A public release ledger need not expose internal hostnames, account identifiers, draft notes, or credentials. The internal record can preserve operational evidence while the public page exposes only the history readers need. Provenance is not an excuse to disclose the machinery of the institution.

Corrections should be reversible at the data level. If an operator maps many planned dates to one actual release date, preserve the original values and the transformation rule. A later discovery can refine the history without scraping old backups. The ledger makes normalization an explicit act rather than a silent rewrite.

Time formats should be boring and exact. RFC 3339 defines a widely used Internet timestamp profile that includes offsets and a predictable ordering. Using a standard representation will not resolve every question about editorial meaning, but it prevents avoidable ambiguity about the instant an event claims to describe.

Validation can then enforce temporal integrity. No published event precedes the artifact it references. Scheduled events in the future do not appear as completed releases. A withdrawal follows a release. A republication references the withdrawn or corrected item. Machine checks will not settle every historical ambiguity, but they catch impossible stories.

Release history is part of the product’s credibility. Readers do not need a forensic dossier for every page, but the publisher should be able to produce an honest account when dates, versions, or announcements matter. The alternative is a polished present supported by an invented past.

A truthful ledger lets the institution say: this is what we intended, this is what happened, this is what we later learned, and this is how we corrected the public record. It also lets the next operator distinguish unfinished work from a completed release without relying on memory. That sequence is not an admission of operational weakness. It is what operational maturity looks like when systems and people inevitably diverge from plan. The durable achievement is not a perfect schedule; it is an honest, reconstructable account.

— Dispatches · Summit Cognitive