I made a rule this week, and then I spent two days building software to protect it from me.
The rule is short: no tool-building mid-book.
Some context. I've been building a writing app for most of this year, and for the last few months it has been tested against one short mystery, a test book called Quiet Boy. The testing went the way testing goes. A reader with a pen found what the metrics missed. Rounds of notes turned into rules for the drafting passes. Every week the tool got better, and every week the book got rewritten by a slightly different tool.
That was fine for a test book. Quiet Boy existed to break things.
Now there's a real one. A trilogy, three novels. The first is straight body horror about a woman who turns out to be patient zero, and it ends with her death and turning. The second is the outbreak. The third I haven't decided yet.
Looking at that plan, I could see exactly how it would go wrong. Halfway through book one I'd find a gap in the genre material, open the code, lose a week to it, come back, and the second half of the book would be written by a different instrument than the first half.
Two problems that look identical
Here's the part that only became clear once the rule was written down.
When a chapter comes back flat, there are two possible causes. The story might be wrong: the scene doesn't earn its turn, or the character wants the wrong thing. Or the tool might have changed: the genre notes got rebuilt, an editing pass got a new instruction, the beat sheet gained a step.
From inside the chapter, those look the same. Both arrive as "this isn't working."
If the tool is stable, flat means the story. That's useful, because it points my attention at the one thing only judgment can fix. If the tool is moving, flat means nothing in particular. I can't read the signal, because the instrument and the subject are both changing at once.
Every lab knows this. Nobody recalibrates the scale halfway through the experiment. I've known it about data pipelines for most of my career. I hadn't applied it to a novel, because a novel doesn't feel like an experiment. It is one, though. Every draft is a measurement of whether the idea holds.
The rule needed teeth
A rule I only hold in my head lasts until the first interesting bug. So the rule went into the software.
Each genre in the app now has a version. When a book starts writing, it records the version it used. If I rebuild Body Horror next month because I learned something, the book in progress keeps reading the old one, and a small note says a newer version is available. Switching becomes a decision I make on purpose, at a seam I choose, not something that happens to the book on a Tuesday.
The other half was moving all the setup ahead of the book. The genre material for book one got built and reviewed before chapter one exists. Book two's genre gets the same treatment months early. The first real build took 21 minutes, and I compared it against the one genre I'd already approved before trusting it.
Nothing about that review was creative work. It was inspection. It just had to happen before the creative work, not in the middle of it.
What crosses over, and what doesn't
The test book taught me a lot, and I don't want to start the trilogy from zero. So there's a way to carry lessons across. The assistant reads the old project and proposes a list, each lesson tagged with where it belongs. General craft goes to my writer-wide rules. Things true of the whole trilogy go to the series. I tick what to keep.
The detail I like most is that the items left behind are shown, not hidden. "Quiet Boy only, skipped." The clue about the doors. One character's office. I watch them stay behind. Nothing crosses silently, and nothing gets dropped silently either.
That's the version lock pointed the other way. The lock keeps change from leaking into the book. The lesson list keeps the past from leaking in unexamined. Either way, whatever enters the book is something I looked at first.
Building tools is the comfortable part
There's another reason for the rule, and it's less flattering.
Building tools is pleasant. Problems have answers. Tests pass. A feature ships and I can point at it. Chapter fourteen of a body horror novel offers none of that. The questions there are "is this frightening" and "does she still want what she wanted on page one," and nothing turns green when I get them right.
So when the book gets hard, the code is right there, offering a problem I already know how to solve. That pull is strong, and it disguises itself as diligence. I'd be improving the app. Who could object?
The rule takes that exit away. When the book gets hard, the only thing left to work on is the book. The machine already does the drafting. What it can't do is notice that a scene is lying, and I can't notice that either while I'm busy improving the machine.
What I'm carrying into the trilogy
The tools get finished before the book starts, and the book keeps the tools it started with. Not because the tools are done. They never are. Every gap I find mid-book goes on a list, and the list waits for the seam between books.
What I'm protecting is legibility. A stable instrument is what turns a bad chapter into information. Once the ground stops moving, the only thing left that can be wrong is the story, and that's the part worth my attention.