What are the established norms from academic pre-print repositories and…

Research Question

What are the established norms and practical conventions from academic pre-print repositories (arXiv, Social Science Research Network (SSRN), Open Science Framework (OSF)) and Personal Knowledge Management (PKM) implementations (Zettelkasten, Obsidian, Roam Research, Logseq) for how published research items should be corrected, versioned, retracted, or extended after initial publication, specifically: what auditability standards must a versioning model meet, how is the distinction between minor correction and substantive revision defined, and does a pragmatic model using a YAML Ain't Markup Language (YAML) frontmatter versions: array (version number, commit SHA (Secure Hash Algorithm), date, progress log path, one-line summary) combined with git commit history as the diff provide sufficient auditability, or is a stricter arXiv-style immutable-file-per-version approach warranted?

Findings

Executive Summary

The repository's frontmatter versions: array plus git commit history is sufficient for this corpus if it is treated as a visible, append-only version chain with full commit SHAs and progress-log links, rather than as a lightweight note-to-self on top of silently mutable files.

arXiv and OSF both preserve prior state and surface later change explicitly.

Those patterns mean this repository does not need an arXiv-style vN-file scheme to satisfy the same minimum auditability norm, because a visible version chain can be implemented without duplicating full-text files.

The retrievable PKM evidence points the same way, because Zettelkasten is tool-agnostic about note evolution and Obsidian Git uses one canonical note backed by commit history, diff view, and restore workflows rather than one full file per revision.

The main repository change still required is therefore governance, not storage layout: ADR-0013 should define correction-versus-revision thresholds explicitly and treat rewrite of pushed main history as disallowed for completed items that carry versions: entries.

Key Findings

1. arXiv's governing norm is a stable identifier with an explicit visible version chain, because replacements, withdrawals, errata, annual updates, and living reviews all remain linked under one record while prior versions stay accessible.
2. OSF's governing norm is frozen primary records plus explicit update workflow, because submitted registrations cannot be edited in place and later changes require a separate, justified update process that preserves the original registration.
3. Registered-reports practice reinforces the same principle by making amendment acceptable only when continuity and justification remain explicit, which favours reader-visible notice chains over silent mutation.
4. The retrievable PKM evidence does not support mandatory immutable per-version note files, because Zettelkasten is tool-agnostic and Obsidian Git implements auditability through commits, diffs, and history views around one canonical note.
5. Git can satisfy the "what changed" inspection requirement because commits are content-addressed snapshots, but git can only serve as a trustworthy audit substrate when pushed history is treated as append-only.
6. The repository's current versions: model is therefore sufficient if each substantive edit records a visible version number, changed date, one-line reason, full commit SHA, and linked progress log, because together those fields recreate the minimum audit trail that the sampled systems require.
7. The correction-versus-revision boundary should be formalised as minor when findings and evidence balance stay unchanged, and major when any finding, confidence grade, recommendation, or cited-source identity changes.
8. corrects: should be added to the relationship vocabulary because it expresses authoritative amendment lineage, while replicates: should wait until the corpus actually tracks a repeatable replication programme that needs a distinct edge.

Assumptions

• Obsidian Git is a reasonable proxy for PKM systems that externalise versioning into git, because it is an official implementation document for one widely used markdown-note workflow and exposes the exact audit surfaces this item evaluates.
• The repository can enforce an append-only norm on main well enough for audit purposes, even though git itself technically permits history rewriting.

Analysis

The core norm across the sampled academic systems is preservation plus explanation, not preservation plus file duplication, so the repository should optimise for reader legibility of change rather than mimic arXiv's exact storage surface.

Git already supplies the diff and immutable snapshot identity that arXiv exposes through public file versions, which means the repository only needs a human-readable notice index on top of git rather than a second full-text archival layer.

PKM practice matters because this corpus is both a publication surface and a working knowledge base, and the retrievable PKM evidence suggests that keeping one canonical note and pushing version granularity into history tools lowers maintenance friction.

The strongest challenge to the pragmatic model is not insufficiency of frontmatter fields but governance slippage, because a versions: array is only as trustworthy as the repository rule that prevents later disappearance or replacement of the commit it names.

The main rival remedy, separate amendment files, remains defensible for public scholarly systems with indexing infrastructure, but in this repository it adds coordination overhead without giving readers more exact diff fidelity than git already provides.

Risks, Gaps, and Uncertainties

• History rewrite on main is the highest-risk failure mode for the pragmatic model, because the versions: entry could then point at commit history that is no longer reachable in the shared branch.
• Hash-function change is a lower-probability risk than history rewrite, because git documents SHA-256 migration as a managed repository-format transition while history rewriting is a routine capability that can immediately disrupt audit trails.
• Orphaned progress-log paths remain possible if later refactors move session logs, so the repository should continue treating the progress path as part of the durable audit chain rather than as disposable process exhaust.
• The PKM comparison is weaker than the pre-print comparison because the evidence used here is concentrated in Zettelkasten principle guidance and one Obsidian Git implementation document.

Open Questions

• Should the repository add an automated check that rejects history rewrites or non-full SHAs in versions: entries so the append-only assumption is enforced rather than merely documented?
• If corrects: is added, should the site render a stronger reader warning for corrected items in the same way it already renders superseded_by: banners?
• If the corpus starts producing deliberate replications of earlier claims, should replicates: become part of the canonical edge vocabulary at that point rather than now?

sources

• [x] arXiv Submission Version Availability - official arXiv versioning policy
• [ ] SSRN FAQ - Paper Citation - seeded SSRN policy page; inaccessible in this session
• [ ] SSRN Support - Submit a Revised Paper - seeded SSRN support page; inaccessible in this session
• [x] Open Science Framework (OSF) Welcome to Registrations and Preregistrations - official registration and update workflow
• [x] Open Science Framework (OSF) Advanced Actions on Registrations - official update and withdrawal workflow
• [x] Center for Open Science Registered Reports - registered-reports continuity and sequential registration guidance
• [x] Ahrens (2017) How to Take Smart Notes - tool-agnostic Zettelkasten guidance
• [x] Obsidian Git Plugin README - official plugin features for commit history, diff, and restore
• [ ] Logseq Version Control - seeded Logseq page; not directly retrievable as usable text here
• [x] Git user manual - object names and commits - official commit identity and content-addressing guidance
• [x] Git - Rewriting History - official history-rewrite guidance
• [x] Git hash-function transition - official SHA-1 and SHA-256 object-name guidance
• [x] Srivastava et al. (2023) Beyond the Imitation Game - concrete multi-version arXiv example
• [x] Research Repo (2026) Academic post-publication amendment practices - prior completed item on the broader amendment-control problem
• [x] Research Repo (2026) Knowledge linking: building a connected research corpus - prior completed item on relationship vocabulary
• [x] Research Repo (2026) Architecture Decision Record 0013 Research Item Frontmatter Schema Extension - current repository design under review