Content retention policy

A publication that quietly deletes what it got wrong reads as more reliable than one that keeps it. That is the failure this policy prevents. Retention here is not a storage question — it decides what a reader can still find on the days the journal would rather they found nothing.

Two dates making two different claims

validityAsOf is backward-looking evidence: the date on which the article's claims were last checked against the sources in sourceIds. It records that somebody read those sources on that date. It does not record that the article was edited.

nextReviewAt is a forward-looking commitment: the date by which somebody must look again. It is set per article rather than by a global interval, because a CRITICAL article resting on regulator guidance ages differently from a LOW explainer of how booking works.

Neither field moves on its own, and neither is a publication date. Fixing a typographical error moves dateModified and nothing else, because nothing was re-checked. Re-reading every source and finding all of them unchanged moves validityAsOf forward while the prose stays identical. Re-reading is work even when it changes nothing.

Staleness is graduated on purpose

An article is stale once nextReviewAt is in the past. What the freshness check does then depends on the article:

Stale article	Result
contentRisk of HIGH or CRITICAL	build fails
emergencyInformation: true, at any risk level	build fails
contentRisk of LOW or MODERATE	warning and an editorial-queue item

The graduation is behavioural, not technical. A uniform hard failure stops an unrelated branch because an explainer went a week past its review date. The engineer looking at that red build has a one-character fix available: move the date. The cheapest route past the gate becomes editing a field rather than reading the article, and the check ends up enforcing a number instead of the review the number stands for. A gate people learn to satisfy dishonestly is worse than no gate.

HIGH, CRITICAL and emergencyInformation: true articles fail the build because there the cost of an unreviewed page is high enough to justify blocking everybody's work, and high enough that the pressure to push the date is meant to be uncomfortable rather than routine.

What does not exist is the second half of that last row. Nothing moves a stale LOW or MODERATE article into an editorial queue: the freshness gate raises no error for it, no item is opened, nobody is assigned, no reminder escalates, and staleness ignored for six months produces the same green build as staleness addressed the same afternoon. The editorial-queue item in the table above is a human obligation described in a policy, not a mechanism that exists in the repository. This is honest, not clean.

ARCHIVED and WITHDRAWN end circulation, and today they end the address with it

Only PUBLISHED and UPDATED reach a page, a sitemap, a feed or the search index, so both terminal statuses take an article out of circulation. What they admit differs, and the distinction matters to a reader deciding what to do with something they have already read.

• ARCHIVED says the article is no longer maintained. Nothing in it was found to be wrong. It has been superseded, or its subject has moved outside what this journal covers. Archiving ends the review obligation, and with it the freshness claim the article was making by carrying a nextReviewAt at all.
• WITHDRAWN says the article should not be relied on. A claim could not be supported, a source was misread, or a basis did not hold. Withdrawal is an admission and is recorded as one, with the reason stated rather than described as an update.

Neither status currently leaves anything at the address. Only PUBLISHED and UPDATED are readable, and the article routes are generated from exactly that set with dynamic params disabled, so a withdrawn article has no route at all rather than a page that explains itself. A reader arriving from an old link finds nothing and cannot tell whether the article never existed, moved, or was found to be wrong — which is the failure a withdrawal notice is meant to prevent. A notice standing at the canonicalPath, recording that an article was published there, that it was withdrawn, when, and why, is the intended behaviour and is not built. Until it is, the only public trace of a withdrawal is the corrections register, and only where a correction was filed alongside it.

Nothing is removed to improve the record

Content does not leave circulation because it aged awkwardly, because it makes an earlier position look less certain than it now reads, or because it sits badly beside something published later. That is a commitment by the people holding push rights rather than something the build enforces: nothing refuses a commit that deletes an article, except the internal-link check, which notices only if another published article happened to link to it.

Two structural facts reduce the pressure against holding to it. The journal runs no analytics, so no traffic figure exists to argue that a page underperforms and should go. And it carries no advertising and no sponsorship today, so no commercial relationship is inconvenienced by a page staying up — if an advertising surface were ever introduced that would be a new decision, and this policy would need rewriting to account for the pressure it creates.

If content ever has to come down for a reason this policy does not describe, it comes down as a commit with an author, a date and a stated reason, like every other change. Silent removal is the thing being refused.

The repository history is the retention record

There is no database, no admin interface and no delete button. Every article, every frontmatter field, every correction file and every status transition is a commit. Moving validityAsOf is a diff a reviewer reads. Moving an article to WITHDRAWN is a diff a reviewer reads. translatedFromRevision pins each translation to the revision it was made from, so a translation stranded by an update to its source can be identified rather than guessed at.

The limits of that record should be stated rather than implied. The repository is private, so a reader cannot audit it and is taking this section on trust. History can be rewritten by anyone holding push rights. Commits are not signed, no timestamp is anchored outside the hosting provider, and there is no independent copy. Nothing here would prove to a third party that a date was not moved after the fact. The retention record is evidence to people who already have access, and to everyone else it is an assurance.