Developers have git. Writers have "Final_v3_FINAL_edited(2).docx". We thought writers deserved better. When we started building Metric37, the humanization pipeline was the obvious focus — but we quickly realized that the editing workflow around it mattered just as much. You do not humanize text once and walk away. You iterate. You try different tones, make manual tweaks, compare results. And without version control, every iteration overwrites the last.

The Problem with Undo

Most writing tools give you linear undo. Press Ctrl+Z enough times and you can walk backward through your edits. But undo is the wrong abstraction for iterative rewriting. It assumes you want to reverse your changes in order. It does not let you compare two arbitrary states side by side. It does not survive a page refresh. And it certainly does not let you branch — try a different direction from a previous state while keeping your current work intact.

When you are working with AI-humanized text, the workflow is inherently non-linear. You humanize a draft, read the result, tweak it manually, then decide you want to try a completely different tone. Or you like paragraph two from version three but paragraph four from version five. Undo history cannot help you here. You need something closer to version control.

How Version Trees Work in Metric37

Every action that changes your text creates a new version. Humanizing creates a version. Re-humanizing with a different tone creates a version. Manually editing and saving creates a version. Each version stores the full text, a timestamp, the action that produced it (humanize, re-humanize, manual edit), the tone setting, and a human score.

Versions are linked to their parent. When you humanize the original text, that creates version 2 as a child of version 1. If you then edit manually, version 3 is a child of version 2. If you go back to version 1 and humanize with a different tone, that creates version 4 as another child of version 1. Now you have two branches diverging from the same root.

From the version panel, you can see the full history, click any version to see a word-level diff against your current text, and restore any previous version with a single click. The diff highlights exactly which words were added, removed, or changed — not just that something is different, but precisely what.

Why Trees, Not Just a List

A flat version list would be simpler to build and simpler to display. We considered it. But a list implies a single sequence of changes, and that does not match how people actually iterate on text.

Consider this scenario: you paste in an AI-generated blog post and humanize it with a professional tone. The result is good but a bit stiff. You humanize again with a conversational tone. Better, but now some technical accuracy is lost. You want to go back to the professional version and manually loosen it up instead of relying on a tone preset. In a linear history, that means losing your conversational version. In a tree, both paths coexist.

The tree structure also makes it possible to answer questions a list cannot: "What did the text look like before I started editing the humanized output?" or "Which of these three different approaches scored highest?" Each branch preserves a complete alternate history.

Technical Decisions

A few choices we made that are worth explaining:

Append-only storage. Versions are never deleted when you create new ones. We do not overwrite or garbage-collect silently. If you created a version, it exists until you hit the cap.
20-version cap with oldest eviction. Unbounded history creates storage problems. Twenty versions is enough to preserve meaningful iteration history without accumulating stale data. When you exceed the cap, the oldest version (by creation time) is evicted first.
Word-level diffing. Character-level diffs are too noisy. Sentence-level diffs hide too much. We use the diff npm package to compute word-level changes, which matches how people actually read and compare text. You can see that "significantly" was replaced with "noticeably" without wading through a wall of red and green.
Version metadata. Each version stores the tone setting, the edit source (humanize, re-humanize, manual save), and the human score. This metadata turns the version tree into something you can reason about, not just a pile of snapshots.

The Score as Commit Message

In git, every commit has a message that describes the change. Good commit messages let you scan a log and understand the trajectory of a project without reading the code. We wanted something equivalent for text versions.

Our version of a commit message is the human score — a 0-100 rating of how natural the text sounds, computed by a separate evaluation model. When you look at your version tree, each node has a score. You can immediately see that your manual edit improved the text from 72 to 85, or that switching to a casual tone dropped it from 88 to 64.

The score is not a vanity metric. It is a decision-making tool. When you have three branches and need to pick one, the scores give you a quantitative signal to pair with your qualitative judgment. You might choose the 78-scoring version over the 91 because it better matches your voice — but at least you know the tradeoff.

What This Enables

Version trees change the workflow from "humanize and hope" to something more deliberate:

Compare your "professional" tone version against "conversational" with a single click and see exactly which words differ.
Restore a version from three edits ago without losing your current work — the current version stays in the tree.
Track which edits improved your score and which hurt it, building intuition about what makes text sound human.
Start a new branch from any previous version to explore a different direction without commitment.

For people who produce content regularly — writers, marketers, agencies — this turns humanization from a black box into a transparent, repeatable process. You are not just getting output. You are building an understanding of how your text evolves.

Try It

Version trees are available to all Metric37 users, including the free tier (5,000 words per month). Paste in some AI-generated text, humanize it a few times with different tones, make some manual edits, and watch the tree grow. The version panel is on the right side of the editor. Click any version to see the diff. Click "Use this version" to restore it.

We built this because we kept losing good intermediate versions during our own testing. If you have ever wished you could go back to "the one from two edits ago," you know the feeling. Now you can.

Version Trees for Text: Git-Like Branching for Writing