Same department, different building

Put the two repositories side by side and the first thing you notice is that I appear to have had the same idea twice.

Perpetūra and Pantheon each have a drafter, a second reader, a continuity editor, an editorial board, a re-reader, a character analyst, a test audience, a production editor, an acquisitions editor, and a trailer cutter. Ten roles, the same ten names, doing the same ten jobs on two books that have almost nothing in common.

I did not have the same idea twice. I had it once and moved house with it.

The port

The Pantheon editorial board opens with a line saying where it came from: the mechanism is adapted from Perpetūra’s, rebuilt for a single-author linear novel. Evidence pack, parallel lenses, a debate round, an adversarial sceptic, a chair. Same five phases, different book.

That is the honest version of the ten shared roles. The first project is where I worked out that a review is a pack of evidence handed to a reader who has nothing else, that lenses should argue before anything gets written down, and that the last step before a report is somebody whose job is to try to kill each finding. None of that is specific to interactive fiction. It is just how you review a long piece of writing without believing your own press.

So the interesting question was never what the two departments have in common. It is what each one grew once it got there.

What each one grew

Perpetūra grew six more roles. A writers’ room, a set builder, a playtester, a shipping desk, a front desk, and a composer. Four of those six are engineering jobs, and they exist because Perpetūra is a program: it has branches that can be unreachable, builds that can go out stale, players who can file bugs, and a release that can be wrong in a way that strands saved games.

Pantheon grew two, and both of them are restraints.

One is a reviewer whose tool list omits the ability to edit, so a reviewer that finds a bad line has to quote it and hand it back. The other reads every edit into the manuscript before it lands, looks at what I am about to write against what is already on the page, and then declines to stop me. Neither adds a capability. Both remove one.

Sixteen roles against twelve, and the difference is not size. It is direction. One department grew outward into the machinery around the book. The other grew inward, against itself.

The tools tell the same story twice

Perpetūra has 42 files in its tools directory, five of them named for tests. They answer questions with a pass or a fail: is this node reachable, does this flag ever get set on a path that arrives here, does this set of picks land the reader in the lane it should.

Pantheon has 25, and every one of them counts something. Sentence length distribution. Words repeated across a chapter. Contraction rates by point of view. Which register band a chapter is sitting in and how far it has drifted. Not one of them can fail a build, because there is no build. They produce numbers, and a number is a prompt to go and read.

The hooks make the point more bluntly than I would have. Pantheon has four and three of them fire before something happens: before an edit lands, before a commit, before a push. Perpetūra has one, and it fires after a commit, to push it.

One project guards the writing. The other guards the shipping.

The bench that did not come along

The port dropped something, and the file says so rather than quietly leaving it out.

Perpetūra’s editorial board does not only run in-session. It sends the same evidence packs out to models from other vendors and reconciles both sets of findings in the debate step, because a panel drawn from one vendor agrees with itself, and I am worse than that: every planted detail lands for me, because I put it there.

Pantheon has no such bench. Not for a reason of principle. It has neither the roster file nor the keys, and its own documentation says a second opinion from a different vendor on the same packs would be a reasonable future addition, that it is not built, and that nobody should write code assuming it is there.

I like that paragraph more than I like most of the code. It is a note from me to a later me about a thing I did not do, with the reason attached, positioned exactly where the mistake would otherwise get made.

Two ways of writing down what went wrong

Both projects keep a record of their own failures. The records do not resemble each other at all.

Pantheon’s runs to 708 lines and is a taxonomy. Nine families, each with a name, a rule, a list of what catches it now, and a paragraph on what still nothing catches. Repetition. A restated number contradicting its source. An instrument measuring the wrong thing. A document claiming what the prose did not have. The reader unable to follow. A rule applied mechanically making the prose worse. A head knowing something it had not been given. Unenforced hygiene. And the canon itself being incomplete, so every rule was locally satisfied inside the hole.

Perpetūra’s is an on-call runbook. A service map with a row per dependency: what it does, where its configuration lives, and how it fails. Which failures are silent. What to do when a release goes wrong, which is always to roll forward, because rolling a version number backwards leaves players pinned to a cached build. It ends on a heading that reads “known monitoring blind spots (accepted, not solved)”, under which sit three things that fail quietly and that I have decided not to fix, with a manual check to run instead.

One of those documents is a novelist’s, and one is an operator’s, and I wrote both of them about my own fiction inside the same eight months.

The taxonomy exists because a novel fails by degrees. Nothing breaks; it just gradually stops sounding like itself, and the only way to catch that is to name the ways it has happened before. The runbook exists because a program fails at a moment. Something is up or it is down, and what you need at that moment is not a category, it is the phone number.

What the two departments have in common is the ten roles. What separates them is that one book can only be wrong, and the other one can also be broken.