Catching What Drifts in Your Human-Led, AI-Assisted Manuscript

This article continues a series about writing with AI, and a framework I built to help with the process. You can read those first articles using the links below.

In the first article, I describe the failure mode that made me build Author Kit: unstructured AI generation drifts toward plausible averages until the story collapses. I also define the intent layer, constitution plus concept, so voice and goals are explicit before any prose gets generated.

In the second, I turn intent into structure: a world state that can be tracked, an outline treated as a contract, and a plan, draft, review loop that forces discipline before drift compounds.

In that cave manuscript I mention in the first two articles (a person enters a cave at low tide and comes out twice, two days in a row), the second and third chapters still read clean. The collapse only appears when you line the chapters up and notice the seam.

That is the mosaic problem. Each tile looks fine. The image is wrong.

This is where chapter level discipline stops and verification starts. Author Kit treats verification as a separate layer because drift is rarely a single dramatic mistake. It is a quiet accumulation of small ones.

The Mosaic Problem

The worst kind of inconsistency is the one you do not notice.

If a chapter is obviously broken, you fix it. If it is subtly wrong, you keep building on it. You turn a local mistake into a global direction. In a series of essays, drift is not usually a timeline contradiction. It is softer and more dangerous.

The claim changes a shade between articles. In my first article I talk about models as “averaging machines”. In this one I start talking as if they were only unreliable assistants. The reader cannot tell you where the flip happens. They only feel the series become less coherent.

Or the voice shifts.

Nothing in the argument is technically wrong, but the cadence changes. A few paragraphs get longer. The metaphors get more ornate. The sentences start sounding like a helpful assistant instead of a person with skin in the game. It happens fast if I get lazy and stop enforcing my own constraints.

Or the thread simply disappears.

In the first article I promise that this is not about prompt tricks. In the second I show structure. If this one forgets to explain how structure is actually verified, the series loses its spine. The reader remembers the promise even if they do not remember the sentence.

That is why I treat this as a verification article. The goal is not to add more structure. The goal is to catch drift that structure alone cannot prevent.

Analysis as Read Only Verification (Prose CI)

In software, I do not merge code because it compiles on my machine. I merge it because checks run, and because those checks are biased toward finding the failures that show up late.

In the first article I compare this approach to spec-driven development (SDD): write the spec first, generate the artifact second, and then verify the artifact against the spec. For this series, the constitution, concept, and outline are the spec. The drafts are the artifact. Analysis is the CI pass that keeps them aligned.

That is what Author Kit does for prose with /authorkit.analyze.

It is a read only pass. It does not rewrite chapters. It produces a report with findings, severity, and suggested next actions.

This matters because of how these projects fail. If a tool quietly edits text while it is “checking” it, I cannot trust the check. I cannot tell whether the output is good, or whether it has simply been coerced into looking consistent.

Author Kit keeps analysis and mutation separate on purpose.

The analysis pass also stays high signal. It caps itself. Fifty findings is the limit by design, not a performance constraint. If a report can produce two hundred nits, it will. And if it does, I will ignore it.

Severity is what makes the report usable. When analysis finds a constitution break, voice slip, tense break, nonnegotiable style violation, the framework treats it as CRITICAL and stop to fix it first. When reader visible coherence is at risk, a claim is contradicted elsewhere, a prerequisite appears too late, a promised thread vanishes, that is HIGH. MEDIUM means the series still works but drift has started: cadence flattening, loose logic, references that need tightening. LOW is polish, useful later but not worth derailing active drafting. This hierarchy allows to focus on what matters most first and avoid modifying everything all at once.

In this series, imagine article one framing models as averaging machines, then a later piece quietly reframing them as mere assistants with no bridge between the two. No single sentence is obviously wrong. The series still loses coherence. That is why analysis runs seven lenses every time: continuity, argument coherence, themes and motifs, pacing, voice and style, thread setup and payoff, and governance around parked decisions and deadlines.

Author Kit renders the result as a table:

| ID | Category | Severity | Location(s) | Summary | Recommendation |
|----|----------|----------|-------------|---------|----------------|
| A1 | Voice | MEDIUM | Article 2 | Cadence shifts across the series | Revise to match the constitution |
| A2 | Continuity | HIGH | Article 1, Article 3 | Article 3 assumes X before Article 1 explains it | Add a bridge or reorder |

The point is that with this, drift becomes visible enough to manage.

Reconciliation (When the Specs Drift Too)

There is another drift that is more embarrassing, because it is not the model’s fault: it is when “my documents lie”.

I do not mean maliciously. I mean in the way every project lies after its first revision. I change a paragraph because it reads better. I adjust an ending because it sets up the next article more cleanly. Then my outline still describes the older version. My plan still describes the older version. A note I wrote during planning still implies a claim I removed.

If I keep planning from stale documents, the series becomes inconsistent even if every chapter is well written.

Author Kit treats drafted chapters as canonical for that reason.

It can scan for factual claims made by upstream documents about already drafted chapters, then verifies them against the prose that actually exists. When there is a mismatch, the prose can wins. The outline and plans are updated after — and this is the important part.

Fixing Drift (Revise, Pivot, Retcon)

Once analysis finds drift, the next question is not what to edit. The next question is what kind of change I am making.

Most writing workflows blur this and create chaos. Everything becomes “edit the chapter.” That works until the first real direction change.

Author Kit keeps three actions separate because the risks are different.

• /authorkit.revise is what I use when direction is still correct and execution is not. A paragraph drifts in tone. A transition gets muddy. A claim is correct but poorly staged. Revision is targeted surgery with local risk.
• /authorkit.pivot is different. I am changing direction on purpose. Maybe this series should center model switching earlier (this actually happened!), or spend less space on tool taxonomy and more on governance. That is not a bug fix. It is a scope decision with cascade risk across concept, outline, and chapter plans.
• /authorkit.retcon is the sharpest tool. An established fact changes retroactively, and every downstream consumer has to move with it. In prose, that is the same risk profile as refactoring a public API: partial application is worse than doing nothing, because nine updates and one miss create a contradiction that looks intentional.

The workflow looks simple when the category is clear.

/authorkit.analyze
/authorkit.revise Address the top 3 CRITICAL findings
/authorkit.retcon "duplicates only copy humans" -> "duplicates copy humans and their clothes"

Those commands make the type of change explicit so the rest of the workflow can behave correctly.

Safe Experimentation (Snapshots and What If)

Not every decision is a fix. Some are exploration.

In writing, especially with AI in the loop, the only honest way to evaluate a direction is to draft it. The problem is that drafting commits you. You now have prose that either becomes canon or becomes sunk cost.

Author Kit treats experimentation as a workflow primitive using /authorkit.whatif.

Snapshots are bookmarks with context. It uses the local folder git infrastructure (Author Kit requires — or assumes — you are using a version control system). A snapshot is not only a git tag. It also records why I bookmarked the state, what is working, and what I am uncertain about. That context matters later when I compare outcomes.

What if branches are controlled experiments. Author Kit creates an experimental branch, takes a snapshot first, and records a hypothesis. Then I can try the alternate direction without polluting mainline.

The key difference is that comparison is narrative, not only textual. A diff tells me what lines changed. A narrative comparison tells me what the reader experience changed.

That is what makes experimentation safe. It lowers the cost of admitting uncertainty.

Decision Parking (Momentum Without Amnesia)

Some uncertainty is not worth exploring immediately.

The failure mode is familiar. I notice a question. I keep writing. I forget to answer it. Then I reach the end and discover that three chapters depend on a choice that I never made.

Decision parking is Author Kit’s way of preventing that: /authorkit.park.

When a decision is parked, it is written down with a deadline, urgency, and options considered. The point is not to solve it. The point is to make it impossible to accidentally forget it. A decision may need to be made about Chapter 2, but it won’t matter until we start working on Chapter 12. We can wait until then.

This is also where analysis becomes more than continuity checking. If a parked decision is overdue, it should show up as a finding. Not because the tool is trying to force my hand, but because the workflow needs to surface risks before they become retroactive clean up.

There is a subtle benefit here too. Parking is a way to keep writing without lying to myself. I do not have to pretend the uncertainty does not exist. I do not have to resolve it prematurely. I can keep momentum and keep honesty.

Changing the Rules of Duplications in the Cave Story

This is where the cave story becomes useful again, because it contains the exact kind of change that breaks long projects.

Suppose I write half the manuscript with one duplication rule, and then I realize the rule is wrong.

Maybe duplicates should age faster. Maybe the duplication only works at the spring equinox, not any low tide. Maybe the cave duplicates clothing after all, because otherwise the story keeps tripping over naked copies and the joke gets old.

This is not a continuity error. It is a creative decision.

But it is also a cascade.

The moment the rule changes, every downstream reference to the rule becomes suspect. Any paragraph that relied on the old rule must be updated, including the indirect consequences. If duplicates age faster, it changes alibis, motivations, and what counts as urgent.

This is the kind of change that makes unstructured AI writing collapse, because the model has no global map of which chapters depend on which facts. It only sees the local context window, and the window is not a memory. It is a sampling of recent text.

Author Kit treats this as a sequence, not as a vibe.

1. First, /authorkit.snapshot. Lock the state so I can compare later if the change was a mistake.
2. Then, authorkit.pivot. Generate an impact plan across artifacts. What does this rule touch in the concept, the outline, the world, and the drafted chapters.
3. Then, /authorkit.retcon. Produce a manifest of direct references, indirect references, and derivative consequences. Show the list before editing anything.
4. Then, /authorkit.revise the chapters that were affected, keeping the local voice intact.

Then, /authorkit.analyze again. Not because the tool is trying to win an argument, but because retroactive considerations are where humans miss the tenth reference.

The point of this workflow is not to make direction changes painless. Direction changes are not painless. The point is to make them tractable, so the cost is visible and the results are consistent.

Conclusion

This article is not a promise that Author Kit produces perfect prose. It is a claim that process help, especially with AI. But drift is inevitable. Models average. Humans forget. Documents rot.

The difference between a project that survives and a project that dissolves is whether the workflow catches drift before the reader does. Author Kit adds structure. It adds gates. It adds verification.

Does all this governance produce better writing, or only more consistent writing? The next article will try to answer.

Trying Author Kit

Author Kit is open source. However, you will need an AI Coding agent at your disposal (Claude Code, Codex or GitHub Copilot) and a Python environment with uv. I acknowledge that for many writers, this can be quite tech oriented. Later, if any interest, a better UI/UX could be developed into a product.

Install Author Kit by running:

uv tool install authorkit-cli --from git+https://github.com/mazemerize/author-kit.git