Nine Files to Keep a Book in Mind

Nine files.

Today, that sounds like the opening line of a meeting that should have been an email.

At the time, though, the logic was hard to argue with.

We had just discovered that a sound intellectual structure wasn’t enough to keep the physical production of a long book under control. The condensed draft said what The School of Athens was supposed to be, but expanding it added hundreds of new decisions. Some were conceptual. Some were editorial. Others had all the philosophical depth of choosing between HEADING_2 and Normal text—and we had already learned not to underestimate those.

The decision was to stop relying on the conversation alone. That mattered because conversations have a curious quality: while you’re in one, everything seems available. The decisions were just made, the corrections are fresh, the context seems obvious.

Then hundreds of messages go by.

What was obvious has to be found.

And what has to be found may not be exactly where we thought it was.

The plan was to move memory outside the conversation. If there were things I needed to remember across fifty chapters, they wouldn’t live only in scattered chat messages. We would have persistent documents in Google Drive, each with a job to do.

The first piece would look after ORT’s enduring conceptual foundations. That required some care. The book drew on ideas emerging from Original Reality Theory, but it also crossed philosophy, science, history, and other fields with sources of their own. We needed to distinguish an ORT formulation from an outside reference, a metaphor from a factual claim, a point of convergence from an invented intellectual lineage.

In other words, finding a similar idea in Aristotle did not give anyone permission to make him an honorary member of ORT two thousand years ahead of schedule.

The conceptual foundation would keep that sort of retrospective enthusiasm in check.

Next came the Editorial Engine.

The name may suggest an industrial machine that takes Plato in one end and delivers a typeset chapter out the other. Unfortunately, it didn’t make coffee.

Its job was to record HOW the book should read.

Voice.

Style.

Density.

Length.

Paragraphing.

The use of ORT.

Learning progression.

The relationship to chronology.

Everything that, left only in the conversation, risked being remembered with different priorities at different moments.

But knowing what the book should be like still didn’t tell us how to produce it.

So along came the Production and Quality Assurance Engine.

If the Editorial Engine said “don’t chop up the prose,” the Production Engine said things like: read first, expand, save, reread, check the transition between chapters, update the related documents.

Less poetic.

Also exactly the sort of document that starts looking unnecessary five minutes before you discover why it exists.

Next, a different problem surfaced: examples.

When an AI finds a really good example, there is a statistically driven, distinctly unromantic temptation to find it really good again.

And again.

If a metaphor explains a concept well in Chapter 7, nothing stops it from turning up cheerfully in 18, making a guest appearance in 26, and launching a solo career in 39.

The instruction was to do the opposite. Even when the analytical operation repeated, the examples should vary. Changing the example meant changing the scale, context, and perspective. The reader would exercise the same ability on different material.

So we created a Recurrence Log. It would record examples already used, metaphors, concepts already developed, concepts still being held back, and material that needed a rest.

It was probably the first time anyone had created a document to tell an artificial intelligence:

“That metaphor has put in enough hours. Give it a vacation.”

Then came Status and Continuity. This document had a job that sounded administrative but would become central: telling us where we were.

Last completed chapter.

Current Part.

Outstanding issues.

Recent decisions.

Next step.

The idea was simple. If a conversation ended, we wouldn’t have to reconstruct the entire story to work out whether we were on Chapter 14, or whether 14 had already been corrected three times and 15 was next.

The approved condensed draft also acquired a formal role.

It already existed, but now it had a designated place in the system: a frozen structural reference.

It wasn’t the final text.

It was the map that would keep the final text from forgetting what it was trying to become.

Alongside it came the Editorial Work in Progress—Final Version. This would be the living manuscript. The source of truth for actual progress.

If a document said Chapter 22 was finished but Chapter 22 wasn’t actually there, reality would take precedence over bureaucracy. A very ORT idea, incidentally, although I suspect project managers have reached the same conclusion by less metaphysical routes.

Two pieces were still missing.

The Table of Contents in Progress would track the structure as chapters were completed. We even created color conventions to distinguish their status. And the Bibliography in Progress would do something similar for references: distinguish what was already there, what had been checked and retained, and what was new or had been replaced.

In the end, we had nine files. They didn’t all appear at a solemn ceremony where someone announced, “From this day forward, we shall have nine documents.” They took shape because each problem revealed a need. Together, though, they formed a small infrastructure.

The logic was powerful. His biological memory wouldn’t have to carry every rule at once. I wouldn’t have to depend only on whatever remained most prominent in the conversation’s context.

The project would have a memory outside the two of us.

That changed the relationship. Until then, continuity had lived mainly in the interaction. Now part of it existed in documents that could be reopened, compared, and updated.

It was like building an external brain for the book.

A brain with a color-coded bibliography, which may be less elegant than evolution would have chosen, but it worked.

And there was an important consequence: a chapter was no longer just a piece of writing. To finish it properly, we would have to check how it fit into a system.

The chapter had to respect the condensed draft.

It had to follow the Editorial Engine.

It had to go through the Production Engine.

It had to consult the Recurrence Log.

It had to update Status.

It had to appear in the Table of Contents.

It had to have its references handled in the Bibliography.

The manuscript was better protected.

Producing each chapter also took more cognitive effort.

At the time, though, we mostly saw the first side of that equation. After the formatting disaster, the nine files seemed to be exactly what we needed.

We had found a way to give the project persistence.

A way to keep important decisions from disappearing into the chat history.

A way to keep fifty chapters connected to the same architecture.

And for a while, it felt as though we had finally put our house in order.

We started expanding the book again, from the beginning.

Now there was a procedure.

Now there was a memory.

Now there was control.

The system was ready.

Or at least it was ready to start producing an entirely new category of problems.