There is a great deal of ambiguous fear-based policy being shaped around AI and its use in the writing process. If you’re paying attention to current events in the publishing world, you’ll be familiar with the anecdotes of authors losing lucrative book deals over accusations of AI. The fact that ‘AI use’ isn’t clearly defined in these policies, and the increasing use of LLMs within common writing and research materials, is even more reason to fill an honest writer with a great deal of anxiety.
Luckily, there are already well-developed tools available to help a writer to easily track and document their creative process. In this post, I’ll briefly explain what these tools are, and hopefully de-obfuscate their use to show non-technical writers that they can be made accessible.
Back Up & Track with Version Control Software (VCS)
Git is an example of version control that non-technical writers may have at least heard about in passing (likely via GitHub). VCS is predominantly used in programming, and is designed to allow software developers to keep a version history and backup of the code. The development history can be reviewed at any time, and developers can also roll back the current version of the software in the event that buggy code gets implemented in a newer version.
While the software was designed for programming code, it doesn’t actually care what kind of document you’re working on. You can use it on anything.
Note: this post is not a git tutorial. There are probably hundreds (if not more) of those available for you to find via a DuckDuckGo search, so I recommend you do that to really dive into how to use git. There are also resources at the end of this post. My purpose here is to illustrate how easy it is to add VCS (git) to your writing workflow.
git add "The Kalachakra IP/Karma Ledger/Karma Ledger Draft One.docx"
git commit -m "Karma Ledger: line edits — 32,308 words"
git push
These three commands make up the entire workflow required after you finish writing or editing on your draft, and they can be put into an automated script on any platform (Mac, Windows, Linux) to minimize what you need to type after finishing a writing session.
The above commands do the following:
- Add the updated document to the tracking history (the first time, this also starts tracking the file)
- Commit the newest changes, attaching a message of what the changes were
- Push (upload) those changes to your repository
Just three simple commands not only document what you have done but also provide a full backup of the new document as well as the older version of the document. That means that, in addition to providing an exact history of how your document was created and changed, you can also completely restore it from the repository should you lose the original document due to a system failure.
Keep it private: make sure the repository you push to is private. GitHub, GitLab, and others offer private repositories for free. Pushing your manuscript to a public repository publishes it for anyone to read. GitHub will default to public, so make sure you set it to private before pushing!
git log --format='%h %ad %G? %s' --date=format:'%Y-%m-%d %H:%M' -- '*Karma Ledger Draft One.docx'
This is an example of the command I would use to list the entire history of Karma Ledger. It would output a very long history that looks something like this:
9b2c80b 2026-04-15 00:57 N Tanaka forum scene draft
28f92ca 2026-04-14 17:08 N Gas Station scene review
0c31e64 2026-04-13 16:23 N Hanging Gardens scene, Handshake lore revision
570ee61 2026-04-12 13:19 N Moat District
337b6e3 2026-04-11 16:37 N Overlay scene completed (26,915 words)
...
Each of those entries represents the full draft of the document at that time, and can be used to fully reconstruct the document at any of those stages. That’s an important thing to understand, because it is not just a log of your progress. It is a copy of your actual progress—every word of it exactly as you wrote it on the date that you committed it.
Stamp & Verify with OpenTimestamps
The dates on your git commits come from your own computer’s clock and are just text, which can easily be set to any date. To counter that argument in a witch hunt situation, we need a way to document timestamps and externally confirm that provenance detail.
OpenTimestamps is a free public service that allows you to fingerprint a document to the Bitcoin blockchain. For those unfamiliar with how the blockchain works, think of it as a giant public ledger to which you can only append things. Nobody controls this ledger, and once somebody appends to it, the entire world has access to a timestamped digital notarization that it existed no later than the date it was recorded.
While OpenTimestamps has an API that you can use programmatically, you do not need to know how to code in order to stamp your documents. You merely need to visit opentimestamps.org, scroll down to the bottom, and drop your document into the in-browser application. That’s it!
Your document does need to be stamped every time you commit. That way every single writing session you commit has its own independent proof of date.
Keep the receipt: the OpenTimestamps web application gives you a small
.otsfile. Keep it with the draft it belongs to (committing it to git alongside the draft is ideal). Without it, there is nothing to verify the timestamp against.
It should be understood that your document is never uploaded or appended to the blockchain, so you don’t have to worry about the world seeing your manuscript before you are ready: the application fingerprints the document in your isolated browser session, and only that fingerprint is sent and appended.
Personally, I prefer to use a command-line script that automates OpenTimestamps, but I get that the average writer isn’t going to have a Python environment set up on their system. However, if you are interested in seeing what a script would look like, I have created a functional Python example for you:
Download the example code (zip, 4 KB)
Python runs on Windows, Mac, and Linux, so the same code will work regardless of your system. I’ve included a README in the zip with examples of how to use it.
Signing Your Draft
In the process that I use for my own writing, I add a cryptographic signature to my commits that is generated from the private component of my key pair. This adds an additional level of evidence that I was the one who wrote the prose and committed it with git, because (it is assumed) I am the only one who has access to the private key required to generate the signature. Since cryptographic key pairs are a bit of an advanced topic for non-technical folks, I have left it out here. If you are already familiar with such things, it should be relatively easy for you to add that extra step.
Recovering Draft History
As mentioned earlier, every hash in your log (the short code at the start of each line) points to a complete copy of the draft as it stood when you committed it. To get one of those versions back, give git the hash and the document’s path:
git show 337b6e3:"The Kalachakra IP/Karma Ledger/Karma Ledger Draft One.docx" > "Karma Ledger Draft One (2026-04-11).docx"
This writes the April 11th version of my draft into a new file next to the current one. You’ll notice the working draft isn’t touched, so you can open the two side by side, or even recover a passage you cut and later decided you wanted back.
The recovered file is byte-for-byte identical to the one you committed that day. That matters for provenance, because the .ots receipt you saved for that session still verifies against it: anyone can confirm that the draft git hands back is the same document that was timestamped on that date.
If you want to show the state of each document along the complete history, you just have to type the same command for every hash in your history (or create a script to do it for you). This way you could zip up an entire directory of every stage of your draft to submit as evidence of your process.
Use the old file name: git needs the path the document had at that commit. If you have renamed or moved it since,
git ls-tree -r --name-only 337b6e3lists every file that commit contains, so you can find what it was called back then.Windows users: run this in Git Bash (installed alongside Git for Windows) rather than the PowerShell that ships with Windows. That version of PowerShell treats the
>output as text and will corrupt a.docx.
What Does This Prove?
The Resulting Evidence Demonstrates
- The work was human-paced, and content X was established by date Y
- Human-like mistakes were made in initial drafts and corrected in later drafts
- Updated versions were drafted at later dates
The Evidence This Does NOT Provide
- That a human typed in every word
- That the content is original
- That the content was not modified prior to being timestamped
Please understand that adding this to your workflow is not definitive proof that a human, or specifically you, created it. A person could still prompt an AI to write all of the text section by section, introduce human errors to it, and then use git to commit it to a repository and OpenTimestamps to document it. The human could also steal other copyrighted material and run it through the same process.
The reasonable argument, however, is that if a person is using AI to write their fiction in the first place, then they are not likely to go through the painstakingly slower process of faking provenance of the work’s creation. That doesn’t mean there aren’t people out there who may do exactly that, but the records that this relatively simple process creates will provide you with reasonably strong circumstantial evidence that your novel was human-generated if you did, in fact, write it yourself.