Being wrong is not the failure this policy guards against. The failure is being wrong, quietly fixing the sentence, and leaving nothing behind to show that the earlier sentence existed — because the reader who already acted on it is the one person the fix cannot reach. Everything below exists so that reader can still find out what they read.
What a correction record is
A correction is a file, not a line appended to the bottom of an article. Each record
carries previousClaim, correctedClaim, reason, editorId, reviewerId, material
and dateModifiedChanged. It sits in the same repository as the article, is reviewed as a
change to that repository rather than through the article's own review lifecycle, and
renders on a corrections page that is never pruned.
reason is prose, and it is expected to be uncomfortable: which source was misread, which
jurisdiction was assumed rather than researched, which claim survived from a draft that
never had a defensible basis. "Updated for accuracy" is not a reason. It describes the
edit and hides the error, and an error nobody names is an error the next author repeats.
The previous claim is quoted, not described
previousClaim holds the words the article used, copied across. It is not a summary of
what the article was getting at.
A description of a past claim is written by the person who wishes that claim had been more defensible, and it is written after the correction has already been decided. Paraphrase softens by default: a flat instruction becomes "guidance", an unqualified statement about one country becomes "a general remark", a number becomes "an approximate figure". The reader who needs this record most is the one checking whether the thing they remember reading is the thing that was actually there. A paraphrase is the correction correcting itself.
Material and minor
A minor correction fixes something that could not have changed what a reader did: a misspelled name, a dead link, a transposed digit in a citation, a mangled sentence whose meaning survives intact.
A material correction changes what a reader would do, or what a reader would conclude
about their own situation. A changed eligibility rule, a changed jurisdiction, a changed
timescale, a changed statement about what a professional may be asked for, and any change
to an article carrying emergencyInformation: true or a contentRisk of HIGH or
CRITICAL, are material.
The editor proposes the classification. The reviewer named in reviewerId owns it. An
editor grading their own mistake is grading their own exposure, so the grade is not theirs
to keep. Where editor and reviewer disagree, the correction is material — there is no
route by which an argument about severity settles in favour of the lighter record.
What the build refuses
Two rules are mechanical rather than editorial.
A record with material: true and dateModifiedChanged: false is refused. A material
correction that leaves dateModified untouched serves new content under an old date to
every reader, feed and machine that trusts that date.
A material correction with no reviewerId is refused. The person who made the error is
not the person who confirms it has been fixed.
A correction also cannot rescue a claim by weakening it. If the corrected text is a
jurisdiction-specific claim resting on REASONED_INFERENCE,
COUNSEL_CONFIRMATION_REQUIRED or UNKNOWN, the same check that refuses to publish such
a claim refuses the corrected article. Downgrading the basis is not a fix; it is the
original problem, restated more carefully.
Neither of the two mechanical rules reads the article. Nothing verifies that material
was set honestly, and a material error graded minor passes both checks. The build tests
the paperwork, not the judgement.
Corrections are not removed
A correction is not deleted when it ages, when the article around it is rewritten, when
the article moves to ARCHIVED, or when a later correction supersedes it. Superseded
records stay and say so. A corrections page that only lists corrections still considered
embarrassing enough to matter is a marketing page.
A withdrawn article should keep a page
Only PUBLISHED and UPDATED reach a page, a sitemap, a feed or the search index, so a
WITHDRAWN article stops being readable and the route that served it stops being built.
Withdrawal is the largest correction this publication can make and the one it would be most
convenient to disappear, so the intention is that its canonicalPath still records that an
article was published there, that it was withdrawn, when, and why.
The build does not do that. No route is generated for a status outside PUBLISHED and
UPDATED, so a notice exists at that address only if somebody publishes one there, and no
check refuses a withdrawal that leaves nothing behind. The article's corrections survive on
the corrections page, which is where they are listed rather than beneath the article. The
gap is known and currently unclosed. This is honest, not clean.
A medical or legal conclusion is never changed silently
Where an article's clinical or legal conclusion changes, the change is material by
definition and cannot be handled as an edit. It produces a correction record quoting the
superseded conclusion in full, a reviewer qualified for the subject or the jurisdiction,
and a moved dateModified. There is no minor route to changing what an article concluded
about a medicine, a procedure, a legal obligation or a jurisdiction, and there is no
editorial circumstance that opens one.
What holds that rule is the reviewer reading the diff, not a check. The build requires that a material correction names a reviewer; it does not test whether that person was qualified for the subject or the jurisdiction, and it never compares an article against what it said before. A conclusion rewritten in place, with no correction file at all, passes everything the repository can test.
What makes the record append-only
The filesystem does not. A correction file can be edited or removed with one command, and nothing in the running site would notice.
Git is what makes the record append-only: every correction, and every later change to a
correction, exists as a commit with an author and a diff that another person reviews
before it merges. An edit to a correction is not a silent overwrite; it is a diff someone
has to approve, and its shape — a previousClaim quietly rewritten, a material flag
flipped down — is exactly what a reviewer is there to catch.
That control is procedural, and its limits should be stated plainly. Anyone with push rights and sufficient determination can rewrite history. The repository is private, so a reader cannot audit that history and is taking this section on trust. This publication also carries no comments and no accounts, so a reader who spots an error has no channel here — a report that never reaches an editor never becomes a correction.