Versioning a living research record: git, genetic criticism, and how scholarly publishing tracks changing texts

1Key Findings

• Git stores each commit as a full snapshot of the project, not as a list of changes. The diff a user sees is worked out on demand by comparing two snapshots [1]. Moves, splits and merges between documents are therefore not recorded; they can only be inferred afterwards (inference from [1]).
• Ink & Switch, a research lab building version control for writers, reports that git cannot compare or merge files from WYSIWYG editors such as Word. Markdown kept in git loses comments attached to passages [2]. Its later Patchwork project explicitly counts AI tools among the collaborators proposing edits [3]. It found that LLM-written summaries of changes worked well for text and less well for visual edits [4].
• Darwin made around 2,250 sentence-level changes and more than 15,000 word or phrase changes across the six British editions of the Origin. The online variorum identifies and presents every one of them [5]. To do that it gives each paragraph a stable number that survives later insertions, for example P 100, then P 110 and P 120 for paragraphs added after it [5].
• Genetic criticism began in 1968 with the Heine manuscripts acquired by the Bibliothèque nationale de France. It became a CNRS laboratory, ITEM, in 1982. Its linguists reduce writing to four operations: adding, deleting, replacing and moving [6].
• The TEI Guidelines (the standard for encoding texts in digital scholarly editions) let an editor group individual edits into a revision campaign and number them in the order they happened. They explicitly support transcriptions whose aim is to represent the creative process rather than a finished text [8].
• Crossref says a draft should not get a DOI. A published version gets one. A new DOI and a public notice are needed only for editorially significant changes, and the original should not be silently modified [10].
• Zenodo registers two DOIs on first publication: one for the specific version and a concept DOI for all versions. It then adds a new version DOI for each release, and deliberately keeps version numbers out of the identifier [11][12].
• At F1000Research, every version of an article is linked to the others and can be cited on its own. Each new version opens with a short summary of what changed, and the citation itself carries the version number [13]. For living systematic reviews, the summary is at most 300 words. The article also states the dates of the last and next literature searches, and it can lose its living status if updates lapse [14].
• Hinchliffe (2022) describes scholarly publishing moving from a single version of record toward a linked record of versions. She also reports that 83% of researchers surveyed by Springer Nature preferred the version of record for citing [15].
• On the open web, digital gardens and Gwern.net put a status label on unfinished work (notes, draft, in progress, finished) and a confidence label on each piece (certain through remote). Gwern.net also keeps a monthly changelog [16][17][18]. Ward Cunningham's Federated Wiki gives every page an edit history, called its journal, that travels with the page when it is copied and forked [19].
• The Memento protocol (RFC 7089) is a web standard for linking a page's current address to dated addresses for each past version. It can also mark a page as frozen, meaning it will not change again. That gives answer engines a standard, machine-readable way to tell a living document from a fixed one [20].

2Details

1. What git actually tracks, and where it fits prose badly

Most people imagine that git stores changes, a chain of diffs. GitHub's own engineering blog corrects this in its title: commits are snapshots, not diffs [1]. Each commit records the complete state of every file at that moment. Unchanged content is shared between snapshots by referring to it by a fingerprint of its contents, so nothing is stored twice. A diff is computed only when someone asks to compare two snapshots [1]. The author traces much of git's reputation for confusion, especially around commands that rewrite history, to people picturing commits as diffs that can be shuffled around [1].

This matters for Canopticon in two ways. First, the snapshot model is exactly right for a public record. Every past state of a document can be shown whole, not reconstructed. Second, and this is my inference from the snapshot model, git does not record relationships between pieces of content across time. If a passage moves from one file to another, or two files are combined into one, git stores two snapshots that happen to share text. Any statement that this paragraph came from that paper is reconstructed afterwards by heuristic comparison, not written down when the change was made. For a codebase that is acceptable. For a record whose claim is that the lineage of an idea is part of the content, lineage has to be written down when it happens.

The second limit is the unit of comparison. Ink & Switch's Upwelling project, an experimental editor for professional writers and editors, sets out why existing tools serve writers badly. Track Changes and version comparison show deletions struck through and insertions in colour, with comments in a sidebar. Git, by contrast, cannot compare or merge files from WYSIWYG editors like Word. Writers can be trained to use Markdown, but Markdown files in git lose features writers rely on, such as threads of comments tied to particular passages [2]. Upwelling's design keeps git's best idea, the commit as a deliberate, reviewable unit. A writer working on a private draft chooses how to group related changes into a unit before merging back, even when the changes touch many parts of the document [2]. Its stated aim is to combine the strengths of ordinary writing tools with those of formal version control while avoiding the weaknesses of both [2].

Ink & Switch's next project, Patchwork, widened this into what it calls universal version control for any kind of creative data. Its opening note observes that collaborators now include AI tools proposing edits [3]. That is close to your workflow: AI drafts, you digest over time, then decide. Patchwork's prototype had three main features: lightweight branches, diff visualisation, and a chat-like interface to document history. The lab used it for its own writing [4]. Two of its findings carry over directly. Branching proved useful in every domain tried, prompting the conclusion that "branching is a powerful general primitive for all kinds of creative work" [4]. And auto-generated LLM summaries of edits served text well but were "less obviously good" for visual edits [4]. In practice the system can draft the note on what changed and you supply the reason.

So git is a fair answer to how the history should be stored, and a weak answer to how it should be shown and cited. Sections 2 to 5 take up the second question.

2. The closer parallel: genetic criticism and the variorum

What you describe has a name in literary scholarship. A finished text is the end of a process, the process can be reconstructed, and the reconstruction is itself worth reading. French genetic criticism (critique génétique) began when Louis Hay and a small group were asked to sort the Heine manuscripts that the Bibliothèque nationale de France had begun buying in 1967. The group started work in 1968. Their project grew into a centre founded in 1974, renamed the Institut des Textes et Manuscrits Modernes (ITEM) two years later, which became a CNRS laboratory in 1982 [6]. ITEM went on to study the manuscripts of Proust, Zola, Flaubert, Valéry, Sartre and others [6]. A standard overview describes the approach as treating a manuscript not as a finished product but as part of a larger collection of drafts, notes and revisions. It reconstructs the sequence of actions (writing, erasing, cutting and pasting, annotating, correcting) that produced the final version. The descent of versions is pictured as a branching tree, which is a git history by another name [7]. That overview is an encyclopedia entry. I use it only for the definition; the founding history comes from CNRS's own account [6].

Two findings from this field bear directly on Canopticon. The first is the unit of change. ITEM's linguists identified "four essential operations in the production of a text: adding, deleting, replacing and moving". The linguist Jean-Louis Lebrave noted these are "the four basic functions common to all word processing applications" [6]. Git models the first three well. It does not model the fourth, moving, because a move appears as a deletion in one place and an addition in another. For your plan to merge two addiction papers, moving is the operation that matters most.

The second is that digital tools made process records richer, not poorer. Hay is quoted saying: "Because processors keep a record and the date of every step in the writing process, we can retrace the various drafts and work phases with extreme precision." [6] CNRS describes researchers recovering Derrida's deleted drafts from his hard disks with forensic techniques, because he did not know the disks kept a trace of his operations [6]. The lesson for a deliberate record is to keep that trace on purpose, in a form readers can use, rather than leave it for forensics.

The variorum edition is the reader-facing form of this scholarship, and the Online Variorum of Darwin's Origin of Species is the best working example. Edited by Barbara Bordalejo, it covers the six British editions published between 1859 and 1872. It identifies and presents every change between them, from single words up to a whole chapter added in 1872 [5]. The scale is large: around 2,250 sentence-level changes, counting sentences added and removed, and more than 15,000 changes in words or phrases, against a first edition of 3,878 sentences by Peckham's count [5]. The editor needed specialised collation software and is candid about its limits. The software lost its way when it met long stretches of unmatched text [5]. That is the same failure as a line-based diff when a section is rewritten or moved.

The variorum's solution is a design you could adopt directly. Every paragraph and sentence carries a stable number. When the 1869 edition inserted two new paragraphs after paragraph P 100, they became P 110 and P 120. If a later edition had inserted one between them, it would have been P 111 [5]. A passage keeps its identity across versions even as text is inserted around it. That makes it possible to show one paragraph as it stood in 1859 and in 1872 side by side, and to cite a passage rather than a page. A later Canopticon article quoting a living document needs exactly this. The quotation should point to a passage that can be followed forward through revisions, not just to a position on a page that may change.

The digital standard behind such editions is the Text Encoding Initiative (TEI). Its Guidelines provide markup for additions, deletions, substitutions and restorations, each attributable to a hand (whoever made it) with a stated certainty and responsible party [8]. Two features carry over to Canopticon. First, TEI lets the editor assign individual edits to a change, meaning a state or revision campaign, and give them a sequence number for the order in which they are believed to have happened [8]. That is a commit grouped by intent rather than by time. Second, TEI distinguishes transcriptions meant to represent the final text from those meant to represent "the process by which the document came to take its present form" [8]. It explicitly supports transcriptions whose object is "not to represent a finished text, but rather to represent the creative process" [8]. TEI's attributes for responsibility and certainty would let a Canopticon history say who made a change, AI draft or Chris, which matters for attribution.

John Bryant's The Fluid Text (2002) supplies the theory. Scholars usually treat works as fixed and try to eliminate variation. Bryant argues instead that the variations are valuable records of the interaction between artist and society [9]. He developed the argument from the versions of Melville's Typee and argued that the material is best presented by a partnership of book and screen [9]. I read only the publisher's description, not the book itself, so I cite it only for that central claim.

Assessment. Git is the right comparison for engineers building the system. Genetic criticism and the variorum are the right comparison for what readers see and what the record claims. They say outright that the path to a text is content, and they have spent decades on how to present it. The two traditions are compatible. TEI-style revision campaigns are commits grouped by intent, and a variorum is a diff viewer built for prose.

3. How scholarly publishing versions a living document

The third parallel deals with what neither git nor literary scholarship fully covers: identifiers, citation, and when a change is big enough to count as a new version.

The version of record and its critics. Crossref is the registry behind most scholarly DOIs. It defines the version of record as the typeset, copyedited and published version. Anything after it, including corrections, added data and retraction, is an update [10]. Its rules for publishers make three moves that map onto Canopticon:

• A draft (unpublished) work should not be assigned a DOI [10]. Drafts stay out of the citable record.
• A preprint gets its own DOI and the published version a separate one, with a link between them (the published version has preprint the earlier one) [10].
• After publication, a new DOI and a public notice are needed only for changes likely to affect how the work is interpreted or credited. Crossref calls these editorially significant. For such updates, the original document should not be modified; a separate notice, such as a correction, should be issued instead [10].

That threshold is the most useful single rule you can borrow. It separates a typo fix, which needs no new version, from a change of claim, which does.

Lisa Janicke Hinchliffe's landscape review (2022) explains why this matters beyond mechanics. The version of record organises the whole system: style guides, funder mandates, tenure files and publisher revenue all point at it. "As the version of record comes into being, it has the effect of fixing the earlier versions as predecessors to it." [15] She reports growing efforts to link versions into a record of versions [15]. She also sketches a possible future of documents "continuously revised and updated", perhaps across several researchers' careers, with no single version of record, before concluding that the fixed version of record will probably remain central [15]. The evidence on readers cuts both ways. A Springer Nature survey she cites found 83% of respondents preferred the version of record for citing, against 9% for author manuscripts and 2% for preprints. Respondents still valued other versions for skimming and keeping up [15]. Instructors interviewed by Ithaka S+R found preprints harder for students to place in context [15].

Inference for Canopticon: your split, with fixed research papers and everything else in development, matches what readers already expect. Fixed papers are the citable anchors. Living documents need clear labelling, so that a reader or answer engine never mistakes a draft position for a settled one.

Concept identifiers plus version identifiers. Zenodo, the CERN-run research repository, introduced its DOI versioning scheme in spring 2017 [11]. On first publication it registers two DOIs, one for the specific version and one for all versions. It then adds a DOI for each new version. In its worked example, v1.0 is 10.5281/zenodo.60943, v1.1 is 10.5281/zenodo.800648, and the concept DOI is 10.5281/zenodo.705645 [12]. Zenodo deliberately keeps version numbers out of the identifier: "Including semantic information such as the version number in a DOI is bad practice, because this information may change over time, while DOIs must remain persistent and should not change." [12] Version suffixes such as .v2 are also not machine-readable, so a discovery system cannot tell that two such DOIs are versions of the same thing. Zenodo links versions in the metadata instead [12]. The Zenodo team's own write-up describes versions linked in the DataCite metadata, plus an extra DOI for all versions to give discovery systems an aggregated view [11].

For Canopticon this solves the question of which version is being quoted. A later article quoting Narcocrasis cites a version identifier, so the quotation can always be checked against the text as it then stood. A reader who wants the current thinking follows the concept identifier.

Living articles in practice. F1000Research runs this model at scale with open peer review. All versions of an article are publicly available and independently citable, each with its own DOI, and the latest is shown by default. "A short summary of the revisions is displayed at the start of each new version." [13] The platform treats all its articles as living, even after review, because authors can publish an update at any time [13]. Its citation format puts the version number and review status in square brackets straight after the title, so they are not lost when the citation is copied [13]. F1000 distinguishes two kinds of new version. A Revised version usually responds to reviewers; an Update adds small developments after review [21].

Its rules for living systematic reviews are the most developed rules anywhere for a document meant to keep changing. They adopt Cochrane's definition of such a review as "a systematic review that is continually updated, incorporating relevant new evidence as it becomes available" [14]. Each new version must include a summary of the differences from the previous one, at most 300 words, published in an amendments box [14]. A second box gives the date of the last literature search, the date of the next, and the outcome. The template example begins "Last search: 1 March 2019", with the next search on 1 June 2019, one new study found and no change to conclusions [14]. Each new search can come out one of three ways: no new studies, new studies that leave the conclusions standing, or new studies that change them. Only the third always triggers new peer review, and no living review may go more than a year without one [14]. A review can lose its living status. Grounds include missed updates, drift from the original question, or reaching the end of its planned schedule [14]. Authors are told to say when they expect the review to stop being living [14]. Authors who drop off over time are kept in the author lists of earlier versions and credited in acknowledgements, so credit is preserved across versions [14].

Inference: these rules transfer almost directly to Canopticon's living documents. The amendments box is a note on what changed and why. The search-status box is a last-checked-against-new-evidence date. Loss of living status is an honest way to retire a document from development without pretending it was finished. Credit preserved across versions is how to record which parts were AI-drafted and which were yours.

4. How writers on the web show that a piece is unfinished

Scholarly publishing handles identity and citation. Personal publishing on the web has done more on showing readers that something is unfinished.

Maggie Appleton's history of the digital garden movement defines a garden as a collection of evolving ideas that are not organised strictly by publication date. Its notes are published half-finished and expected to grow [16]. Some gardeners add an epistemic status, a short statement of how they know what they claim and how much research went into it [16]. Appleton names Gwern.net as one of the earliest and most consistent examples of this kind of self-annotation [16].

Gwern.net's own About page sets out the system. Each page's date marks the last time the page was meaningfully changed, not the last edit of any kind [17]. That is a deliberate choice: trivial edits do not reset it, much like Crossref's distinction between significant and insignificant changes. A status tag gives the state of completion: notes, draft, in progress, or finished unless more material turns up [17]. A separate confidence tag runs on a fixed scale from certain through highly likely, likely, possible, unlikely and highly unlikely to remote and impossible. It expresses how well supported the essay is [17]. Gwern.net also keeps a monthly changelog of major writings and changes, because the writing is so incremental that it is otherwise hard to follow [18].

Inference: status and confidence are two different axes, and Canopticon would benefit from showing both. A document can be finished but low-confidence, or a draft built on solid evidence. Your Pharmakrasis summary already makes a confidence claim: that the evidence for drug-specific sensory balances is better than for any medium. The history can show when such claims strengthened or weakened.

Ward Cunningham, who invented the wiki, added a property that most wikis lack. In his Federated Wiki, every page carries its own edit history, called the journal [19]. Editing someone else's page means copying it onto your own site, where further edits happen, and the original author can copy the revisions back or keep going on their own fork [19]. The history pane shows whose edits are whose, and each copy's journal records edits since it was copied [19]. The point for Canopticon is that history belongs to the page and travels with it. When content is merged or split, its journal should come along, not be left behind on a retired page.

5. Splits, merges and machine-readable history

The hard case in your example is structural: seven papers becoming one, or two addiction papers (Pharmakrasis and Narcocrasis) merged into one. None of the systems above handles this cleanly, and the reasons point to what Canopticon must record for itself.

• Git stores snapshots and infers moves afterwards. A merged document looks like a new file whose text resembles two deleted ones [1]. (Inference from [1].)
• Zenodo and Crossref link versions of one resource. Crossref also has relation types between distinct works, such as a published version linked to its preprint [10]. Neither scheme is designed to say that one new document supersedes two others (inference from what [10][12] describe; I found no published scheme for it).
• The Darwin variorum keeps passage identity through insertions [5]. It covers editions of one work, not several works combining.
• Genetic criticism handles combination best. The overview of genetic editing describes reconstructing "exactly which parts of the manuscript were acted upon where multiple manuscripts have been combined" [7]. TEI's markup for primary sources includes the dossier génétique: a collection of source documents behind one text [8].

Inference: Canopticon needs explicit lineage links at two levels, written down at the moment of change rather than inferred later.

1. Document level. Links such as merged from, split from and superseded by. The retired documents keep their identifiers and full histories, and show a notice pointing to their successor. This is Crossref's rule against modifying the original, applied to structure [10].
2. Passage level. Stable passage identifiers in the variorum style [5]. When a paragraph moves from Narcocrasis into a merged addiction paper, it keeps its identity and its history goes with it, as journals do in Federated Wiki [19]. That records moving, the fourth operation of genetic criticism [6], as a move instead of a delete plus an add.

Making it legible to machines. Your record is read by answer engines as well as people, so history also needs a machine-readable form. The Memento protocol (RFC 7089) gives one, built on a common pattern. A generic address always serves the current version, and a dedicated version address serves each past version [20]. W3C specifications are the standard example: one generic address, plus dated addresses for each draft and the final recommendation [20]. A system can add Memento headers to each version page giving its date and linking it to the generic address and to neighbouring versions. It can publish a TimeMap, a machine-readable list of all versions, and can let a client ask for the version current on a given date [20]. MediaWiki, the software behind Wikipedia, has a Memento extension supporting this [20]. Memento can also declare a resource frozen. Its Memento-Datetime header promises the content will no longer change, which the ordinary Last-Modified header does not [20]. That maps directly onto your two classes. Research papers get the frozen signal; living documents get a TimeMap.

6. Putting the parallels together for Canopticon (inference)

Everything in this section is my synthesis of the findings above. The sources do not prescribe it.

What to call it. Git for research will be understood by technical readers but suggests the wrong reading experience. Variorum or genetic edition names the reader's experience exactly, with a scholarly pedigree, though it is unfamiliar to most readers. Living document with a visible record of versions (Hinchliffe's phrase [15]) is the most widely understood. A workable public framing: living documents with a full record of versions; research papers are versions of record.

A composite model, mapped to the sources:

Worked example: the McLuhan series. Suppose you merge Pharmakrasis (06) and Narcocrasis (07) into a single addiction paper. Under this model the record would show four things. First, a new concept identifier for the merged paper, with lineage recorded as merged from 06 and 07. Second, both originals retired, not deleted: each keeps its full version history and gains a notice pointing to the successor. Third, passages carried over keep their identifiers, so a reader can follow the allostatic-state-as-medium argument from its first version in 07 into the merged paper. Fourth, an amendments note saying why you merged. The reason is the part only you can write, and it is what your digest, read, understand, decide process produces. If the seven papers later fold into a single paper, the same mechanism applies one level up. Your Krasis synthesis (01) shows how the merged structure grew out of the series.

Canopticon already holds a related piece. The research document on the Net-Casting framework recommends a deliberate cooling-off step between an AI result and publication. The version history described here would make that step visible on the record rather than private.

3Beyond this question

• Attribution is the sharpest reason to keep history. Canopticon mixes AI-generated drafts with human judgment. A revision history that records who made each change (TEI's hand attribute [8]) and keeps credit across versions (F1000's approach [14]) answers a question readers will increasingly ask of AI-assisted research: which parts were the system's and which were the author's decisions.
• Quotations into living documents need version pinning. Every later Canopticon article that quotes a living document should cite a version identifier. Otherwise a quotation that was accurate when written can become unverifiable once the source is revised. Crossref's rule against silently modifying the original exists for exactly this reason [10].
• The digest step is itself evidence. Genetic criticism treats the gaps between drafts as evidence of thinking [6]. Your slow, multi-pass reading of AI output is that gap. Dated revisions with short notes on why would turn it into a record others can study. That is what makes the claim that the evolution is the content more than a slogan.

4Open questions

• No published scheme found for merges and splits across documents. I found well-developed models for versions of a single work (Crossref, Zenodo, F1000, the Darwin variorum) and for drafts combined into one manuscript (genetic editing). I found no standard identifier scheme recording that one living document superseded two others, or split into several. Canopticon would be defining its own relation types. This needs checking against DataCite's and Crossref's full relation-type vocabularies, which I did not read in full.
• Reader behaviour with living documents is barely measured. Hinchliffe notes that systematic research on how researchers view versions is scarce. The two studies she reviews concern preprints and versions of record, not continuously revised documents [15]. Whether general readers or answer engines handle a notice that a document has changed since it was last read is, as far as I found, unmeasured.
• Passage-level identity under heavy rewriting. The Darwin variorum's paragraph numbering worked for six editions of one book, and the editor reports collation software losing track under long unmatched variation [5]. How well stable passage IDs survive the deep restructuring you describe, such as seven papers into one, is untested. It may need human assignment at merge time.
• LLM-written change summaries. Ink & Switch reports they work acceptably and are better for text than for visual edits [4], but published no measurement of accuracy. Whether AI-drafted notes on what changed are reliable enough for a public record is an open, testable question.
• Thin primary access in places. I read Bryant's argument only through the publisher's description [9], and genetic editing's definition through an encyclopedia overview [7]. The primary book behind it (Deppman, Ferrer and Groden, Genetic Criticism: Texts and Avant-textes, 2004) was not accessible. I could not read the NISO Journal Article Versions recommendation directly; its definition of the version of record reaches this report only through Hinchliffe [15].

5Sources

1. Commits are snapshots, not diffs — GitHub Blog, 2020
2. Upwelling: Combining real-time collaboration with version control for writers — Ink & Switch
3. 01 · Universal version control (Patchwork lab notebook) — Ink & Switch, 13 February 2024
4. 10 · Beyond prose (Patchwork lab notebook) — Ink & Switch, 3 April 2024
5. Introduction to the Online Variorum of Darwin's Origin of Species — Darwin Online, ed. Barbara Bordalejo
6. The Genetic Origins of Literary Works — CNRS News (Francis Lecompte), 11 July 2018
7. Genetic editing — Wikipedia (encyclopedia overview, used for definition only; primary book not accessible)
8. TEI Guidelines, Chapter 12: Representation of Primary Sources — Text Encoding Initiative Consortium, P5 Version 4.12.0
9. The Fluid Text: A Theory of Revision and Editing for Book and Screen — John L. Bryant, University of Michigan Press, 2002 (publisher's description)
10. Version control, corrections, and retractions — Crossref documentation
11. DOI Versioning Done Right — Nowak, Ioannidis, Bigarella and Nielsen, Zenodo, 31 May 2018
12. What is DOI versioning? — Zenodo FAQ, CERN
13. How It Works — F1000Research
14. Guidelines: Preparing a Living Systematic Review article — F1000Research
15. The version of record as a central organizing concept in scholarly publishing — Lisa Janicke Hinchliffe, Information Services and Use 42(3-4), 2022
16. A Brief History & Ethos of the Digital Garden — Maggie Appleton
17. About This Website — Gwern.net
18. Changelog — Gwern.net
19. On Federating Wiki — Ward Cunningham, Smallest Federated Wiki (archived repository)
20. Resource Versioning and the Memento Protocol — Memento project (companion to RFC 7089)
21. Article versioning — F1000