Humans can’t reliably detect AI-generated writing from human-produced writing, but most think they can. No app can reliably do so either — my newspaper and magazine articles from 10, 15 years ago have been flagged by Grammarly, ZeroGPT, Pangram and others I’ve tested as various percentages of AI generated. Grammarly, which recently had to backtrack after stealing the editorial voices of various writers and offering them to its customers — without the writers’ permission — flagged entire paragraphs as AI generated, paragraphs written decades ago. I suspect it’s my use of the em dash, but that’s a hill I will die on. It’s mine, and the AI-overlords can drag it out of my cold, dead hands. My use of cliches is probably also a trigger.

I don’t have great answers for this. We live in an era where good writing is immediately suspect to the masses, and there’s little we can do to guard ourselves against false accusations — little that isn’t entirely disruptive to our workflows. Protecting yourself will likely require some changes to how you work, but they don't have to be disruptive.

• Version control. Keeping a version history lets you later produce a trail of your evolving work. The simplest way to do this is to number your files as you go, and use a different file for every set of revisions. For example, each day before you start work, copy the previous file, give it a new version number and do that day’s work in that file (I use a form of semantic versioning favored by software developers). Keep all of the historical drafts as their own files. You can automate this process through GIT, though it requires varying levels of technical skills, depending on how you do it. For work where evidence is critical, like chapters produced under a six-figure book contract or legal filings, storing these documents on servers whose timestamps can’t be modified is stronger evidence, but so is file hashing (a process that also requires technical skills). File versioning is more difficult if you’re using an app that abstracts the file system away, like a simple notes app.
• Process artifacts. A lot of fiction writers collect this epherma already, because they believe it’s useful for marketing. It can also be evidence: screenshots or exports of research notes, browser history exports during research phases, library loan records, interview recordings or correspondence with sources, margin notes in physical books. The goal is to show a research-to-draft-to-publication pipeline that AI use wouldn't produce.Apps that take time-shots of your screen and can be confined to the relevant windows are a good middle ground. Something like TimeSnapper or Hunchly (great for journalists as a research tool, too) can create reconstructable workflows and the process artifacts mentioned above.
• Metadata and stylometric consistency. A long publishing history itself is evidence (whether accepted as such or not is another question), especially when stylometric analysis shows consistent voice across decades. Worth noting that stylometric analysis, unlike AI detectors, actually has a scientific track record in authorship attribution but is very far from perfect. Writers with backlists could preemptively commission or self-run stylometric comparisons showing continuity of voice, but many writers at risk of false accusations are writing to a publication’s voice, not their own. Not everything I write, for example, sounds like a Wired front-of-book piece or an inverted-pyramid-style breaking news article, but a large volume of my work does.
• Handwriting. Really, Natalie Goldberg would be proud. Writing drafts by hand produces process artifacts that are difficult for generative-AI to convincingly fake, and there are other benefits, too. “Handwriting activates a broader network of brain regions,” and it slows you down, giving your brain more time to process and more time to process deeply. And if you can’t write in cursive, that’s even better — studies show the fluidity of cursive over block letters recruits an even broader network of brain regions. At any rate, it’ll be difficult for most people to argue with a hand-written first draft.

No single piece of evidence here will protect you from being falsely accused or losing a contract or job — and none of these solutions are currently easy or workflow-insensitive. They require thought, planning and an organized storage method for later retrieval. The more different pieces of evidence of your process you collect, the better off you’ll be.

And it’s worth noting — there are significant digital privacy costs with some of these methods. Even facing a public accusation, it’s not necessarily wise to publish private emails or even drafts in progress to satisfy an online mob. Screenshots and screen recordings come with even more dire privacy risks. But where it counts, with people who can be trusted (like editors and bosses and judges), proactively preparing to defend against the accusation can make all the difference.

In the era of AI-generated writing, proving that a piece of work is yours — that it evolved, that it grew, that it has a history — is becoming an unfortunate reality. Publishers, editors, and even legal disputes may one day hinge on whether you can demonstrate that your writing is yours, and that it changed over time the way real writing does. One way to do this is git, a version-control tool software developers have used for years.

What You Need

• A folder of writing files (plain text or Markdown works best, more on this below)
• Git installed on your computer (free)
• Optionally: a GitHub account (also free) to store your history in the cloud

Before we install git, a quick detour to explain what it is and what it does. If you’re already familiar, skip ahead to the next section.

Think of git as a logbook that sits invisibly alongside your writing folder. Every time you tell it to, it takes a complete snapshot of every file in that folder and stamps it with the date, the time, and a note you write describing what changed. These snapshots are called commits.

Unlike a backup, git does not just save the latest version. It saves every version you have ever committed, in sequence, forever — or for as long as you keep the folder. You can scroll back through the entire history of a manuscript like rewinding a film. You can see exactly what a chapter looked like six weeks ago. You can recover a paragraph you deleted in last year.

This is called version control. You may have jury-rigged a version of this for years — folders full of files named essay_FINAL_v2_REAL_THIS_TIME.docx (I use semantic versioning, with patch numbers for daily drafts, like screenplay title 1-1-1.fdx). Git does the same thing, but cleanly, automatically, and with timestamps.
For generative-AI-era writing specifically, git gives you something valuable: a dated, sequential paper trail of your creative process. A file that materializes fully-formed with no history might look like AI output. A file with fifty commits spanning months or weeks, showing a messy first draft evolving into a polished piece, looks like a human wrote it.

Do remember that git timestamps your history when you commit, not when you save the draft or do the actual work. So if you write all day but only commit once, you’ll only have a timestamped version as the file existed at commit.
And a note on file formats: git works with any file, but it works best with plain text.

If you work with .doc or .docx files, git will still track that the file changed, but it won’t be able to show you specific lines that changed the way it can with plain text (.txt) or a Markdown (.md) file. If you haven’t switched to writing in Markdown, now might be the time. Apps like iA Writer (the one I use personally), Ulysses, Obsidian, Highland Pro (which uses a screenplay-specific version of Markdown called Fountain) all use Markdown natively. If you’re committed (no pun intended) to Word or Pages, git still works — you just get less detail in your history.

Easiest Method: Github Desktop

Github Desktop is a free application that gives git a visual interface — no typing commands into a command line. This is the best starting point for most writers.

Setup

• Download and install GitHub Desktop
• Create a free account at github.com if you do not have one
• Open GitHub Desktop and sign in with your GitHub account

Creating a repository

In git, a tracked folder is called a repository, or repo for short. This is your writing project’s logbook.

1. In GitHub Desktop, click File > New Repository
2. Give it a name (e.g. my-novel or essays-2025)
3. For "Local Path," choose where on your computer to store it — or point it to a folder you already have
4. Leave everything else as default and click Create Repository

Your folder is now being watched by git, but nothing has been saved to history yet. For that, you need to make your first commit.

Making your first commit

1. Add your files to the folder you just created, or start a new file in it
2. Open GitHub Desktop and you’ll see your changed files listed on the left under Changes
3. At the bottom left, there is a text box that says “Summary (required)” — this is a commit message, and it’s stored with the version history you’re about to save
4. Write a short note describing the changes you’ve made: e.g., first draft of chapter one, opening graf, rough notes only, etc. You can provide a more detailed description if you like, but it’s not necessary.
5. Click Commit to main (main is the branch of your repository you’re using — branches are an advanced topic you can dig into here)

That’s all there is to it. Git has taken a snapshot of your file, and the date and time are recorded along with your commit message automatically.

Daily work with git

From here, your daily workflow shouldn’t be too difficult.

1. Write!
2. Open GitHub Desktop when you’re ready to make a commit
3. Review the changes shown (click on any file to see what’s changed)
4. Write a brief commit message
5. Click Commit to main

At a minimum, you should do this every time you finish a writing session. I commit anytime I get up from my chair, which is roughly every two minutes and 30 seconds — probably overkill for most of us. Just remember, the file snapshots are timestamped when you commit to git, not when you save the file and not continuously. If one of your goals is to create an evidence trail, a more balanced approach to committing — say every time you finish a major section — will probably be more helpful.

Another Method: Git via the Command Line

If you’ve never used the command line, it can feel intimidating. For our purposes, we only need five short commands and once they’re learned, they’re faster than using GitHub Desktop. The first step is to make sure git is installed.

Installing git

• Mac: Open Terminal and type git --version. If git is not installed, macOS will prompt you to install it automatically.
• Windows: Download Git for Windows, which installs both git and a terminal called Git Bash.
• Linux: Run sudo apt install git or the equivalent for your distribution.

Setting Up Your Identity

Git stamps every commit with a name and email so there’s a record of who made (git repositories are often shared by teams, who checkout and checkin the files they’re working on.) Run the following commands, filling in your personal details.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Creating a repository

Navigate to your writing folder in thermal. Example on a Mac or Linux machine:

cd ~/Documents/my-writing

Tip: drag the folder from Finder into the terminal window to auto-populate the correct folder path.

Then, initialize git:

git init

That’s it. Git is now watching this folder.

Two important git commands

When you’re ready to make a commit, run the following three commands one after the other.

git add .

This tells git to pay attention to everything that changed. The period means “all files” in the repository.

git commit -m "revised the ending of chapter one"

This takes the snapshot. The text inside the quotes is your commit message — write whatever is useful to help you identify the commit in the future.

Optional: pushing to GitHub

Everything so far lives only on your computer. You can push the files, along with the version history, to GitHub for an off-site archive. GitHub stores your git repository in the cloud, giving you a timestamped, off-site record of every commit. A commit on GitHub has a timestamp that GitHub's servers generate and cannot be retroactively altered.

From GitHub Desktop

1. After making at least one commit, click Publish repository in the top right
2. Give it a name and choose whether it should be public (anyone can see it) or private (only you) — private is likely the option you want
3. Click Publish Repository

From then on, after each commit, a button will appear in GitHub Desktop that says Push origin. Click it to sync your local commits to GitHub. Make this part of the habit: write, commit, push.

From the command line

Before you can push to GitHub via the command line, you need to create an empty repository on GitHub.com — don’t add any files to it to avoid merge conflicts. GitHub will show you a setup page — copy the commands under “push an existing repository.” They’ll look something like this:

git remote add origin https://github.com/yourusername/my-novel.git
git branch -M main
git push -u origin main

You only have to run those commands once. From then on, after you’ve used git add and git commit all you need is git push to send your changes to GitHub.

Some Suggestions

• Git and GitHub are not backup solutions. Yes, GitHub stores your files and version history in the cloud, but its primary purpose is version control. Still follow backup best-practices: keep a second local copy (using something like Time Machine) and a third, off-site copy via a dedicated backup service like Backblaze.
• Write commit messages that will be meaningful in the future: drafted final scene between Ryan and Jane will probably be more useful than updates
• Commit often. Certainly don’t wait until a draft is “good enough” to commit — the point is to establish an evidence trail that shows an evolving piece of work.

There’s no foolproof way to prove your writing is yours — even version-control histories can be faked or generated by large language models. But, combined with other forms of evidence, having a history of your work as it progressed can go a long way toward successfully fending off false accusations.

Ideally, the apps we use will start to build version control into their interfaces — many coding apps already do, and if you’re a screenwriter Arc Studio Pro has a robust version control and branching system. Until then, git is an easy, free solution.

As the starship Eudoxus falls to an alien pathogen and the crew turns on one another, a doctor pieces together what's happening to his ship — and, in parallel, what happened to a relationship built on the things neither of them could bring themselves to say. 

What begins as a confession unfolds into two stories told at once: the contagion that turned his crew mates into strangers, and the slower one that ended a relationship he can't stop reaching back for. Both come down to the same thing — the questions asked too late, and the ones never asked at all.

A one-act for solo performance.

Log in or join for a free ePub and PDF download, or alternatively download from Gumroad —

For this month's GalaxyQ at Planet M I wrote about one of my favorite things, plants! Here's an excerpt from The Secret Lives of Flowers and Plants:

Today, giving a rose is often a public (and expensive and environmentally intensive) gesture of love. You actually want as many people as possible to know that you spent a paycheck on some flowers flown across the globe in a giant refrigerator — the ostentatiousness of it is sort of the point. But the rose has real roots as a secret messenger-slash-enforcer — the exact opposite of a public display of affection — that stretch to ancient times and back. Maybe it’s the thorns? Legend has it the Romans carved roses in walls of their dining rooms to remind guests that what happened as guests in their homes stayed in their homes. Roman mythology holds that Cupid once gave a rose to the Greek god Harpocrates (aptly, the god of silence) so he’d stay quiet about some dirt he apparently had on Venus. And sub rosa, a 17th-century Latin term that means “under the rose” still pops up in a modern court documents to indicate something that was done in secret. Lawyers love Latin.

This issue also wraps up with a feature on something else near and dear to my heart, Super Mario Bros.

You can subscribe to GalaxyQ at Planet M – new issues every month.

Years ago, I was working as a newspaper reporter in West Virginia when the Pittsburgh Post-Gazette broke a major story about WVU. Former Governor and Senator Joe Manchin's daughter, Heather Bresch, had risen through the ranks at Mylan Pharmaceuticals to CEO, but when the reporters checked her published bio, they found a problem. Bresch had claimed a degree from WVU that didn't seem to exist. The reporters checked with the school, but instead of confirming the truth, they schemed to retroactively protect Bresch by claiming the degree was valid. Several university officials resigned in the wake of the Post-Gazette's stories.What stands out to me most of all, though, is a side story in the entire saga. At one point, the reporters met with confidential sources in a busy McDonald's in Morgantown. They were overheard talking, and the sources were identified and exposed. For all the Post-Gazette's stellar work, this particular episode was a spectacular failure of source security.

Journalists have an ethical obligation to protect their sources and to minimize harm. This isn’t controversial, but too few really understand what that takes, particularly in the modern era. Your sources’ identities can be exposed through a single careless tap, a convenient default setting, or an adversary’s ability to reconstruct who you’ve been talking to through a variety of data points. Even if you don't choose to talk to them in a McDonald's. If you work with sensitive sources, and you probably do, assume you are being watched. Start building habits now that hold up under pressure, not just in ideal conditions.

When talking about security, we start with threat modeling — what we’re trying to protect, who might target it, how they could do it, and how likely and costly those outcomes are. Start by asking yourself who might want your sources' identities, what powers they have, and what your security weaknesses are. For many reporters, the biggest risks are metadata and physical compromise. Metadata is the “who/when/where/how” around your communications. These could be actual call logs, message headers, location history, Wi-Fi associations, contact graphs, and device identifiers. Even if your message content is encrypted, metadata can still sketch the contours of source relationships with enough detail to reconstruct the source's identity. Physical compromise — such as a seizure, search, or compelled unlocking — makes the process even simpler.

Reduce what your devices retain. Turn off cloud backups for sensitive apps, disable message previews on lock screens, and limit notification content (see this story about Signal notifications on Apple devices). Audit app permissions. Microphone, camera, location, Bluetooth, and contact access should be granted only when needed and revoked when not. Keep your operating system updated. Most real-world compromises exploit known vulnerabilities, not zero-day exploits or state-level hacking. However, LLM-based and other artificial intelligence solutions are rapidly changing the landscape, so assume your devices are never secure at baseline.

Use strong authentication, but avoid biometric locks for high-risk work. Biometrics are convenient, yet in many jurisdictions, you can be compelled to unlock with a fingerprint or face, and your biometric markers can be used while you’re unconscious or restrained. Prefer a long passcode (more than four digits), ideally alphanumeric (not just numbers), and set the device to lock immediately when closed. Enable full-disk encryption (modern iOS and Android do this by default, but only if a passcode is set) and make sure the device requires the passcode after reboot. If your phone is taken, the difference between “locked” and “locked with a strong passcode” is often the difference between inconvenience and catastrophe. Apple devices have stolen device protection. Turn it on. You can also set a delay before security settings can be changed.

For communications, use end-to-end encrypted messaging. Signal is a common choice for sensitive conversations because it’s designed to minimize what it can learn about you and supports features like disappearing messages. Still, disappearing messages are not magic. Screenshots, secondary devices (such as having Signal on your phone and computer), and backups can still preserve content. Treat encryption as one layer in a broader plan. When exchanging documents, encrypt files before sending. Use tools that support modern encryption and strong passwords (or even better, passphrases), and share the password out of band. For email, encrypted services like Proton can help, but remember, email is fundamentally metadata-rich and often long-lived. Proton also offers encrypted document storage and encrypted video calls.

A VPN can be useful, but keep expectations realistic. A VPN hides the destination of your traffic from the local network (hotel Wi-Fi, cafés, possibly the ISP) and shifts trust to the VPN provider. It does not make you anonymous, and it won’t protect you if your device is compromised or if you log into identifiable accounts while using the VPN. Use a reputable paid service with a track record of independent audits (Proton and Mulvad are two currently recommended by most security experts), and treat it as security hygiene, not invisibility.

The safest communication channel is sometimes no channel. High-risk sourcing often benefits from meeting in person, without bringing a primary smartphone. Phones broadcast identifiers and can be tracked through cellular networks, Wi-Fi probing, Bluetooth beacons, and location services. If you must meet, choose a location that reduces surveillance opportunities, vary routines, and avoid discussing sensitive details while transiting or if other people are around. Consider using a dedicated “clean” device for certain work, kept separate from personal accounts, contacts, and habitual locations. But again, be careful where you meet. 

Assume surveillance is both digital and physical. Practice basic surveillance detection: notice repeated vehicles, unfamiliar people mirroring your route, or patterns around your home and workplace. Digitally, watch for sudden battery drain, unexpected heat coming from your devices, new device admin apps, configuration profiles you didn’t install, or logins from unfamiliar locations. These signals are imperfect, but they are prompts to slow down, change plans, and consult a security professional if needed. If physical surveillance is a real possibility in your threat model, take some time to learn how to execute a surveillance detection route.Finally, operational security is a team sport. Agree with editors on what you will record and what you won’t. Document secure workflows and digital security policies, train for them, and rehearse worst-case scenarios: device seizure, account takeover, and legal demands. Tools do matter, but habits protect sources.

If you want a deeper dive, here are a few good resources.

The WIRED Guide to Digital Security

In an age of nonstop breaches and hacks, here are ways to improve your online security based on your level of risk, from average user to NSA contractor.

WIREDWIRED Staff

Surveillance Self-Defense

We’re the Electronic Frontier Foundation, a member-supported non-profit working to protect online privacy for over thirty-five years. This is Surveillance Self-Defense: our expert guide to protecting you and your friends from online spying. Read the BASICS to find out how online surveillance works. Dive into our TOOL GUIDES for instructions…

Home

Cover Your Tracks

See how trackers view your browser

In graduate school I worked with one of my professors on an experiment that made novel use of Kim Witte's Extended Parallel Process Model. This model was an attempt to explain why fear-based public health messages sometimes work and sometimes backfire. The basic idea: when people encounter a threatening message, they make two quick assessments. How serious is this threat and can I actually do anything about it? Get both right and people take protective action. Get the second one wrong — scare people without giving them a path forward — and they actively resist.

The EPPM is elegant, but the scientific literature has shown inconsistent results, mixed findings, and eventually serious calls to abandon it entirely. And then the pandemic happened.

Watching COVID public communication unfold in real time was, for someone who had spent years thinking about fear appeals, genuinely painful. The messaging was heavy on threat — and the threat was real, that was not the problem — but the efficacy content arrived late, changed constantly, and was undermined by contradictory signals from the same authorities delivering it. What followed was predictable: defensive processing at population scale. Denial, resistance, reactance. People not ignoring the message but actively pushing back against it.

So I went back to the EPPM and started to wonder if the experimental literature testing it had been making a basic error for thirty years. Witte's theory is explicitly about perceived threat and perceived efficacy — what an audience member actually feels and believes, not what a researcher designed a message to convey. But study after study tested messages that were intended to produce high threat or high efficacy, declared the intention equivalent to the perception, and then received results that were inconsistent. I started to feel that the model was never properly tested and began looking for a way to fix the problem. So I built a systems dynamics model that eliminated the message resonance problem that I call the Integrated Parallel Processing Model (IPPM). It’s essentially a mathematical simulation.

Rather than a branching decision tree showing which path people take, the simulation represents the emotional and behavioral response to a message as a system of interconnected feedback loops that evolve over time. Fear builds on itself. Hope, properly cultivated, does too. The competition between them determines not just whether someone takes protective action, but the trajectory of that response over days and weeks and what happens under repeated exposure.

Fear appeals are not optional. Many comm studies theorists wish they are, but life is dangerous. Threats exist and must be communicated. When you tell someone they are at risk of a serious disease, that will activate a fear response. The question was never whether to include threat content. The question is what you pair it with, and in what proportion, and in what sequence.

The IPPM shows that efficacy content does not merely balance threat content, it must exceed it by a meaningful margin from the first moment of exposure. And it must give people something they can actually do, early enough that they experience a small success before the larger ask arrives. The hope loop — a feedback structure I found missing from Witte's original formulation — needs fuel from real behavioral experience to sustain itself.

The IPPM is built in Insight Maker, a free web-based simulation platform, and is available to run and explore. You can adjust the four key variables representing how an audience perceives a message — severity, susceptibility, self-efficacy, and response efficacy — and watch how those inputs play out over time across emotional and behavioral trajectories. The full model code, scenario definitions, and Python and JavaScript runners are also available on GitHub for researchers who want to run simulations programmatically or extend the model. An accompanying paper is in progress.

The pandemic was not the last time we will need to communicate serious threats to large populations under pressure. Building better tools for that work felt, honestly, like the minimum responsible response to watching it go wrong.

In the inaugural issue of Planet M's flagship newsletter, I wrote about my first tarot card reading. An excerpt:

In my research for this story, I found that fortune-telling really hasn’t changed all that much in human history or across cultures. Sure, the Mesopotamians used entrails to divine answers to their questions — “particularly the liver and the lungs,” Chris Godsen writes in his book, Magic: A History — but they also used the stars, too. The Zodiac was created in 410 BCE, according to Godsen. The Vikings cast runes, little stones with symbols on them, each with a specific meaning that shifts depending on how the stone is cast. Egyptians were fond of interpreting meaning from the distorted language of dreams, because they believed dreams were messages from the gods. In ancient China, The I Ching or Book of Changes used yarrow sticks or coins to help the user consult the so-called 64 hexagrams. The Romans saw omens in the flight patterns of birds. The Greeks had the Oracle at Delphi. Scrying, the practice of gazing into mirrors, water, or crystal balls took off among mystics in 15th-century Europe, and astrology among Europeans really came into its own not long after that. Tarot cards had been around for centuries as an Italian game called tarocchi before being adopted for fortune-telling sometime in the 18th century.

None of these methods, of course, predict the future. My psychic does not really know that I’m supposedly in for a period of good luck or that my insurance company will suddenly start showering me with the money I’m owed. But there’s a reason humans have practiced and reinvented and repurposed divination methods since apparently the beginning of time — they can and do reveal secret information. It’s just secret information we already know but need help to access directly. We’re talking about the subconscious, and its role in generating thoughts, feelings, and behaviors before they enter our conscious awareness.

The human brain has pretty much one job — to keep you alive. It does this by distributing energy throughout the body based on the environment. Running from a tiger on the savannah is going to look very different, energy distribution-wise, than say a night at home watching Netflix. The brain is also a prediction machine. It is constantly trying to guess what’s coming next so it can be prepared to shift your body’s energy supply where it’s most needed as quickly as possible. Is a tiger likely to jump you in the Starbucks line? No. So, energy can be more broadly distributed.

Read the rest of the story and the whole issue – including a story from Harry Houdini — at Planet M.