Chapter 11. The Lifetime of a Vault: Backflow and the Operating Cycle

Once a verified Vault moves into downstream work, short stories are written from it and character-sheet work begins. Does a Vault that has been made once have nothing more to do?

No. The answer follows from one of the most important principles of operating Librarying.

The error in the very idea of completion

The phrase “a completed Vault” silently assumes a stable state that will never change again.

But an IP changes. New works appear, settings are revised, new characters enter, and established characters reveal new sides. As long as an IP is alive, its vocabulary changes with it.

Treating a Vault as finished once and for all produces a familiar failure. A team may carefully build 1,500 files, then release ten new works across two years while the Vault remains in its original state. A writer looks for new vocabulary, cannot find it, stops using the Vault, and finally finds no reason to update it. The neglected Vault eventually ceases to function.

Wikipedia is useful to recall here. It has never been “complete”: the English Wikipedia receives hundreds of new articles and edits to tens of thousands of existing articles every day, and an event from yesterday can become an article today. That is a living document.

A Vault is also a living document. It does not end when it is completed; it changes alongside the IP for as long as the IP lives. This shift in understanding is the starting point of Chapter 11.

Backflow: the cycle in which writing returns to the Vault

Librarying normally moves information from IP documents toward the Vault. First-stage extraction draws keywords from source documents, and stages two through four turn them into Vault entries.

Backflow is movement in the opposite direction: vocabulary newly created while writing a short story with the Vault returns to the Vault.

Once the reason for this reverse movement is understood, backflow becomes not an exceptional event but a natural by-product of creation.

Imagine a writer using the “Correction” and “Adjustment” entries in the mystery world of “Rosy Hollow”. While writing a scene, the writer needs a concept absent from existing settings and coins “reverse reading.” It is the act by which an original maker reads backward the overly new trace left by correction after it erases a flaw, restoring what was just removed: the opposite of correction, which erases the flaw.

The concept appears for the first time in this story and is not yet in the Vault, but it is likely to be used in future works of the same IP. This is exactly where backflow is needed.

The writer leaves a short definition and a note of its source within the story; that note enters the backflow queue. On the next incremental run, Librarying reviews new vocabulary in the queue. It is important not to register everything automatically. A person first decides whether the term deserves a Vault entry, is an alias for an existing entry, or is only a temporary expression used in one story. Only approved items are added to the stage-two CSV. After confirming that their worldbuilding axes use allowed values, the stage-three skeleton build runs incrementally and creates the new .md files. Stage four then fills their narratives, and the backflow queue records the registration date.

When writing discovers a new term and registers it in the Vault, later writing can refer to it again. As long as that circulation continues, the Vault grows into a living dictionary.

Practical operation of backflow

Writers frequently use a term that does not exist in the Vault. They can choose one of two approaches. Immediate registration pauses the writing briefly and adds the term to the Vault at once. Queueing backflow leaves only a note that the term was found, without interrupting the writing, and processes the queue after the story is complete. Immediate registration is preferable when the term is a central concept in the story; peripheral vocabulary can wait in the queue. Its advantage is that the term can be referenced from the Vault immediately when it appears again in the same story.

Without backflow, the Vault eventually stops functioning. If writing continues without it, the gap between Vault and writing grows until the vocabulary used in writing cannot be found in the Vault. The belief that the Vault is useless then takes hold, and writers stop consulting it.

Operating backflow too strictly is not realistic either. Stopping the writing to update the Vault for every word breaks the flow; backflow must not become a burden on writing. Processing the queue after each short story is a practical balance.

Incremental updates: process only what changed

New or revised material requires Librarying to run again, but rerunning everything from the beginning would repeat the nine to sixteen hours required by the first full cycle. Doing that every time is plainly inefficient.

Version control in software development provides a useful comparison. When code changes, a system compiles only changed files and reuses previous build results for untouched files. This incremental build is far faster than a full build.

Librarying follows the same principle and processes only changed material. When one new short story arrives, the incremental flow is as follows.

Run first-stage extraction only on the new short-story file. Add its new rows to the existing stage-one CSV; do not touch existing rows.
Rerun second-stage consolidation across the whole set. New rows may be absorbed into existing entries or become new entries. Existing entries may gain aliases, alternative names, or related keywords.
Run the third-stage skeleton build incrementally. Create .md files only for new entries. Under the idempotency rule, existing files update their frontmatter and body while preserving LLM blocks.
Run fourth-stage narrative writing incrementally. Fill LLM blocks only in newly created files.

A single short story usually adds thirty to fifty entries. An incremental update of that size takes about 1.5 to 2 hours—roughly one eighth to one tenth of a full rerun.

Why existing LLM narratives survive: the long-term value of idempotency

The idempotent update rule discussed in Chapter 7 rewrites frontmatter, definitions, and details when the skeleton build runs again, but leaves the human-filled LLM narrative blocks untouched. Its importance in long-term operation becomes clear in a simple case.

Suppose an IP releases fifty short stories and runs fifty incremental updates over two years. Some LLM narratives were written during the first fourth-stage session two years ago; others were written in recent updates. Even after fifty rebuilds, not one line of those LLM blocks has been lost. Without the idempotency rule, two years of writing could disappear during any one of the fifty rebuilds.

There is one caution. If a definition or detailed explanation in the stage-two CSV changes, the frontmatter and body update, while the LLM narrative may still refer to old information. When such a mismatch is found, rewrite that entry’s LLM narrative incrementally: do not erase it wholesale, but use the existing narrative and change only what has changed.

The seriousness of the mismatch depends on the case. If only the official English name of “Correction” changes, edit the places where the name appears in the narrative. If the core concept of “Correction” itself changes, rewrite the whole narrative. The former is P2; the latter is P1.

Reconfiguration: updates on a larger scale

Backflow and incremental updates are everyday operation. Reconfiguration is a larger, occasional update, and it has two forms.

The first is redesigning worldbuilding axes. This becomes necessary when the IP expands in a new direction and keywords accumulate that the existing axes cannot classify. Reprofile the IP, redesign the axes, and update the axis classification of all entries. Chapter 6 recommends setting axes provisionally at first and adjusting them as the IP’s needs become clear. Small adjustments can be incremental, but a major expansion in an unexpected direction can leave the axes unable to contain the IP. That is the moment for reconfiguration. Delaying it increases the number of entries classified under wrong axes and the narratives that refer to them, raising the later cost of reclassification. When the signal appears, act early.

The second is a change in naming policy. It is needed when one category has inconsistent naming rules: some representative keywords are Korean, some English, and some mixed. Correct the representative keywords in the stage-two CSV in bulk and rerun the stage-three skeleton build; idempotency preserves the LLM blocks.

During reconfiguration, preserve old entries by changing their version state instead of deleting them. Entries adopted under the new setting remain current; old settings that are no longer canon but still remain in published works are marked past version; only what has become wholly invalid is retired. Old vocabulary then remains available when older stories or settings must be consulted.

Renamed entries need greater care. Deleting the old file as soon as a new representative-keyword file is made can lose its LLM narrative and work notes. Isolate the old file, then determine whether to transplant its LLM and note blocks into the new entry. Names can change, but the accumulated traces of narrative and judgment are work assets.

Living IPs operate this way in practice. In April 2014 Lucasfilm grouped the existing expanded Star Wars universe of novels and comics under “Legends,” removed it from canon, and began managing new canon separately with a dedicated Story Group. It did not delete old settings; it preserved them as past versions. DC Comics’ 2011 “New 52,” which restarted issue numbering while retaining some settings rather than replacing everything, is likewise a form of canon-version management.

The rhythm of the operating cycle

The frequency of incremental updates depends on the form of the IP. For a short-story project, update when each story is finished. Waiting until ten stories have accumulated makes the backflow queue unmanageably large and leaves new vocabulary unavailable to writing for too long. For a long-form manuscript or game content, chapter-level or patch-level increments are suitable: run them when a chapter is complete or a patch is released. An IP with a regular update rhythm can schedule Librarying updates accordingly. For example, an operating calendar can reserve the first Monday of every month for an incremental update, keeping the Vault close to current.

One rule does not change: the moment a Vault update becomes “something we will do when there is time,” the Vault begins to be neglected. The safest method is to connect updates automatically to specific IP events such as finishing a story or chapter, or releasing a patch.

What a Vault operated for ten years might look like

What would a Vault look like after ten years if the Librarying operating cycle worked well?

The initial 1,500 entries may have grown to 3,000–5,000 as vocabulary backflowed from new works across the decade. The hub structure will also have changed: entries that were not hubs at first may have been promoted because later works cited them frequently.

Some LLM narratives will have been written ten years ago, others recently. Thanks to idempotency, the older prose survives repeated rebuilds without deletion. Reading those narratives in sequence reveals how the IP has spoken of its world over time.

This is the memory store Librarying creates for an IP: ten years of one IP contained in a single folder.

What it means to keep a Vault alive

Keeping a Vault alive can be harder than building it in the first place. At the beginning there is ample motivation and energy; six months later, processing the backflow queue and running incremental updates requires the work to have become a natural part of IP creation. It must not remain a separate add-on task, but become one component of IP operation.

Chapter 12 examines the exits from the Vault: how downstream work uses the Vault created by Librarying, and what role the Vault plays in the IP ecosystem.