How do academic and scientific publishing systems handle post-publication…

Research Question

How do established academic and scientific publishing systems (journal publishers, preprint servers, living review platforms) handle post-publication corrections, amendments, retractions, and formal commentary, and what is the minimal viable analogue for a versioned, git-based private research corpus where completed items should be treated as immutable records with narrow, explicitly defined exceptions?

Findings

Executive Summary

• The strongest minimal analogue for this repository is an immutable completed item plus a separate amendment file, with the original item carrying only reader-signal metadata such as status, originating commit, and linked notices.

• Journal publishers consistently treat substantive post-publication change as a formal notice problem rather than a silent editing problem, because they preserve the original record and publish linked notices for correction, concern, or retraction.

• Formal challenge and reply are separate objects from correction, which means the repository should support commentary without forcing every dispute into either overwrite or invalidation.

• Living-update behavior should be opt-in rather than default, because mature systems keep one evolving record only while the question and method remain stable and the version history remains visible.

• A pure in-place version chain remains a plausible later design, but it would stop being "minimal" here because it also needs reader-facing version-history surfaces comparable to arXiv submission history or BMJ previous-version notices.

Key Findings

1. Major publishers preserve the published record and attach a separately published notice when interpretation, metadata, or trustworthiness changes, which means substantive amendment is modeled as linked record-keeping rather than as silent overwrite. Confidence: high
2. The practical threshold for a formal correction is effect on understanding, indexing, or scientific integrity, while typographical cleanup and other low-impact issues are usually rejected or diverted into lightweight comment channels. Confidence: high
3. Retraction systems are designed to preserve discoverability while clearly marking unreliability, because readers need both the reason for invalidation and access to the prior record for auditability and scholarly traceability. Confidence: high
4. Post-publication commentary is a distinct mechanism from correction or retraction, because challenge and reply preserve debate and clarification without rewriting the original or declaring it invalid. Confidence: high
5. Living-review systems only keep updating the same record while the question remains stable, decision-relevant, and operationally funded, and they switch to a new protocol or leave living mode when scope or method drift becomes material. Confidence: high
6. Preprint platforms treat revision as a stable-identifier, visible-version-history problem, which shows that history-preserving updates can work without replacing the original public object or fragmenting it into unrelated records. Confidence: high
7. For this repository, the minimum frontmatter on the original completed item is record_status, version_of_record, meaning the canonical published instance that later notices amend, and amendments, because those three fields are enough to tell readers the current interpretive state, the commit being amended, and where to find the notices. Confidence: medium
8. The only silent post-completion edits that fit the publisher evidence are broken-URL repair, tag updates, and citation-URL normalization, because each can improve access or classification without changing the interpretive content of the record. Confidence: medium

Assumptions

• Assumption: a git commit hash can stand in for a canonical version-of-record identifier. Justification: this repository already treats git history as the authoritative provenance layer, so the missing mechanism is reader-facing notice and linkage rather than immutable storage.
• Assumption: updating a completed item's frontmatter to expose record_status and amendments is acceptable if the same commit also adds the amendment file. Justification: publisher systems update reader-facing status on the original record while preserving the original content, and the same pattern can be reproduced here without silent content rewrite.

Analysis

• The decisive evidence came from publisher policies because they make the post-publication control model explicit, and those policies converged on the same rule: preserve the original, publish a notice, and signal the amended state to readers.

• Commentary was kept separate from correction because the sources consistently frame disagreement and clarification as discourse objects, not necessarily as defects in the original record.

• Living-review and preprint evidence mattered because both show how one logical work can evolve over time without erasing history, but both also impose visible version lineage and explicit stopping rules.

• The local design choice was then narrowed by repository context: git already solves archival immutability, so the required analogue is a notice-and-linkage layer that tells readers which commit is the canonical version of record and how later files reinterpret it.

• A pure git or arXiv-style in-place version chain with visible history remains a credible later design, but it is not the minimal analogue for this repository because arXiv, bioRxiv, and BMJ pair that model with reader-facing version-history surfaces that this corpus does not yet expose.

• Recommended original-item frontmatter schema: the minimal original-record metadata is:

record_status: active        # active | corrected | commented | retracted | living
version_of_record: <commit-sha>
amendments: []

• Recommended amendment-item frontmatter schema: the minimal amendment metadata is:

title: "<human-readable amendment title>"
added: <iso-8601 timestamp>
status: completed
priority: medium
tags: [amendment]
amends: <original-item-slug>
amendment_type: correction   # correction | commentary | reply | retraction | living-update
target_version: <commit-sha>
impact: scoped               # metadata-only | scoped | invalidates

• Recommended file naming convention and template: amendment files should use YYYY-MM-DD-<original-slug>-<amendment-type>.md and contain the sections ## Summary, ## Trigger, ## What Changed, ## Impact on Findings, ## Evidence, and ## Reader Action, because that is the smallest structure that preserves reason, scope, evidence, and downstream interpretation.

Risks, Gaps, and Uncertainties

• Direct COPE text is not quoted in this item, so COPE-aligned conclusions are supported indirectly through accessible publisher policies rather than by direct quotation from COPE.
• The bioRxiv evidence in this item is limited to the revision rule stated in the Frequently Asked Questions (FAQ), so it supports the stable-identifier claim but not a broader reconstruction of bioRxiv's full versioning model.
• The non-Cochrane living-guidance evidence was thinner than the Cochrane evidence, so the external corroboration for stop-or-continue criteria should be treated as supportive rather than decisive.
• The implementation question that remains open is how the site should render amendment banners or notice blocks so readers see current status without opening a second file first.

Open Questions

• Should the repository support an explicit living class of research item now, or should it first implement only correction, commentary, and retraction notices and add living mode later when a concrete use case appears?
• Should formal commentary in this repository require a reply path from the original author, or is one-way comment linkage sufficient for the first implementation?
• Should version_of_record store only the completion commit hash, or also store the completion date and original path to simplify future rendering and audits?

sources

• [ ] Committee on Publication Ethics (COPE) - Retraction Guidelines — - seeded primary source for retraction standards; not quoted directly below
• [ ] COPE - Correction Guidelines — - seeded primary source for correction standards; not quoted directly below
• [x] Nature - Corrections, Retractions and Matters Arising — - primary policy for corrections, retractions, addenda, expressions of concern, and formal commentary
• [x] Nature - Matters Arising — - primary guidance for formal comment and reply handling
• [x] Public Library of Science (PLOS) ONE - Corrections, Expressions of Concern, and Retractions — - primary policy for correction and retraction thresholds
• [x] Public Library of Science (PLOS) ONE - Comments — - primary guidance for lightweight post-publication discussion
• [x] BMJ (British Medical Journal) Author Hub - Correction and retraction policies — - primary policy for version-of-record corrections and retractions
• [x] arXiv - Submission Guidelines — - primary guidance telling authors to replace rather than resubmit corrected work
• [x] arXiv - Submission Version Availability — - primary guidance for permanent version history, withdrawals, comments, and living-review updates
• [x] bioRxiv - Frequently Asked Questions — - official revision guidance quoted through web search
• [x] Cochrane Handbook for Systematic Reviews of Interventions, current version — - primary handbook showing review updating as a distinct governed process
• [x] Cochrane decision framework for update proposals — - primary trigger logic for update versus new protocol
• [x] Guidance for the production and publication of Cochrane living systematic reviews — - primary living-review guidance for versioning, update cadence, and transition out of living mode
• [x] The Living Guidelines Handbook: Guidance for the production and publication of living clinical practice guidelines — - official living-guideline guidance outside Cochrane, located through web search