Chapter 12. The Exits of the Vault: What the Next Tasks Take Forward

The verified Vault now enters its downstream work. It holds 1,500 headwords, wikilinks connecting them, two coordinate systems—nine classifications and worldbuilding axes—and narration for every headword.

There are four exits from here: short-form writing, character building, multilingual publication, and encyclopedia and lorebook production. Each takes the Vault as its input and makes something from it. The B2B context discussed later is not an exit: it is an operating environment in which several teams share authority to update the same Vault, and must be distinguished from the four exits.

What happens without a Vault

Teams that have operated an IP for a long time tend to have familiar experiences.

“This character is Kang Minji in one place and Kang Minseo in another. Which is correct?”

“What were this device’s constraints? It was somewhere in the third edition of the rulebook…”

“We changed this setting last year. Did we tell the translation team? The old name is still in their manuscript.”

“A new editor joined. It may take a month for them to learn the world.”

All of these problems have one cause: information is dispersed across many places, and there is no single source that establishes which information is currently official.

The cost of dispersed information is greater than it first appears. If five team members each spend one hour per week checking whether a setting is correct, that becomes 260 hours of checking in a year. If a manuscript still contains incorrect information after that checking, the cost of correcting it follows as well.

The Vault resolves this by collecting the official version of every piece of information in one place. When confirmation is needed, the team opens the Vault.

Single Source of Truth: a borrowed concept made more difficult

The idea of a Single Source of Truth (SSOT) comes from software engineering. I would not say that IP simply imports the idea unchanged; it borrows it, then places it inside a harder problem.

SSOT is comparatively easy in software. There is one codebase, and that codebase is the truth. The same function cannot have two truths at once; when values conflict, the code that actually runs supplies the answer. Because there is only one truth, SSOT arises naturally.

An IP’s SSOT is not like that. In an IP such as The Witcher, where novels, games, and television series branch into distinct continuities, there is not one canon. Several divergent canons must be managed together in one place without losing track of which line is authoritative for which work. Code does not confront this situation because it has one codebase; an IP Vault must serve as SSOT while holding several continuities side by side. In effect, IP SSOT inherits a problem software did not have to solve.

The principle is older than IP itself. When a law office handles a case, all members treat one shared case file as the official record. Errors occur if someone ignores it and works only from private notes, so everyone consulting the same file is the principle itself.

The same is true when an academic research team keeps data in one shared repository. If each member copies and stores the same data separately, inconsistencies arise among the copies, and “version 2,” “final version,” and “final-final version” all become different files. The agreement to recognize only one shared repository as the real one is SSOT.

Wikipedia was built with the ambition of becoming an SSOT for public knowledge. Just as one checks how a name appears in Wikipedia to ask whether it is official, the Librarying practice for an IP is to first ask how a setting appears in the Vault.

A well-organized IP dictionary becoming common input for several media can also be seen in actual content. Solo Leveling began as a web novel in 2016, continued as a webtoon, and in 2024 expanded into animation, Netmarble’s mobile game, and then a spin-off webtoon while sharing the same world. I read this as a case in which one well-organized world became common input for web novels, webtoons, animation, and games.

Yet more media does not mean that every work shares the same continuity. The Witcher is again the example: beginning with Polish novels and spreading through CD Projekt’s games and Netflix’s television series, its games and television branch away from the original novels. In such an IP, SSOT is not a device that forces one truth. To function as SSOT, the Vault must specify the relation among branches and the canonical scope of each branch.

The concrete mechanism by which a Vault becomes SSOT

For a Vault to become a Single Source of Truth, two conditions are necessary: every official term must be in the Vault, and changes must happen in the Vault.

First, if even one term used by the IP is absent from the Vault, the Vault cannot serve as SSOT for that term. This is why the first extraction must collect broadly and why backflow must continuously reinforce it. The higher the Vault’s coverage, the stronger its role as SSOT.

To say that changes must happen in the Vault means this: if a team member wants to change a character’s name in a manuscript, they must change the headword in the Vault first. Once the Vault is corrected, that change propagates through the Vault by wikilink. The moment “Kang Minji” becomes “Kang Minseo,” links in every file connected as [[Kang Minji]] update to [[Kang Minseo]]. If the manuscript changes first and the Vault changes later—or never—the Vault and manuscript diverge. That is the beginning of SSOT’s collapse.

There is, however, a further hierarchy for an IP that already has a published lorebook or official encyclopedia. A published work is official text disclosed to readers, so its body text takes precedence over the Vault’s working narration. In this situation, the Vault is not a superior source that overrides the publication; it is the center of working material that stays synchronized with the publication and prepares subsequent work. If the Vault conflicts with published lorebook text, the Vault must be updated from the published text. Librarying’s SSOT does not mean that “the Vault wins forever over everything.” It means making clear which material is authoritative at the current stage, reflecting that authority in the Vault, and letting everyone work from the same material.

How writing tools use a Vault for short fiction

Tools used to write short stories, novels, and scenarios employ the Vault in three ways: they refer to worldbuilding vocabulary, check consistency, and analyze coverage.

Worldbuilding-vocabulary reference means opening the Vault whenever a setting needs to be confirmed during writing. If the question is, “What were this device’s constraints again?”, the answer is found in the Vault. This is why Chapter 9 asks for careful construction of structured sections such as constraints and established facts. A writing tool can read these sections programmatically, and a writer can read them directly.

Suppose a writer is composing a scene involving “reweaving” in the textile world Land of Nubi. To reweave Nubi and alter history and law, what is required, who has the authority, and who can expose the falsehood that has been rewoven are all recorded in the Vault. The writer can open the Vault and verify this information immediately while writing. Without it, they must search old manuscripts one by one or depend on memory.

Consistency checking finds expressions in a completed manuscript that differ from the Vault’s vocabulary. When every canonical headword and alias is registered, a checking tool can locate those spellings in a manuscript. If both “Kang Minji” and “Kang Minseo” appear, it can identify which one is the official spelling in the Vault. A newly found expression absent from the Vault enters the backflow queue, making this a mechanism for automatically tracking vocabulary a writer has newly created.

Coverage analysis examines how much the Vault’s headwords have been used in written short stories. If a hub headword has not yet appeared in a manuscript, it may suggest room to plan a new short story around it. In that sense, the Vault is also “a map of stories not yet written.”

How character-building work uses a Vault

Tools that make character sheets take two kinds of information from the Vault: worldbuilding-keyword references and character-relationship-map references.

When creating a new character, the tool draws the headwords of the worldbuilding axes to which the character belongs. For a character in the textile-record axis, the devices, concepts, and value headwords from that axis form the character’s background, and they automatically fill the “worldbuilding keywords” field of the character sheet. How naturally a new character fits this world can be measured by how well the character can be described using the Vault’s headwords. A character that cannot be explained through Vault vocabulary is, to that degree, unfamiliar to this IP’s world.

Imagine creating a new character called “the Patternless” for an IP about clans, weaving, and rank: a person unable to read or weave patterns, but able to grasp everything about the clan through bare memory alone.

When the Vault supplies the headwords forming this character’s background, the weaving axis yields [[Nubi]], [[pattern]], and [[reweaving]]; the memory axis yields [[bare memory]], [[book burning]], and [[the Patternless]]; and the character relation [[Weaving Maiden (character)]], one who reads and weaves patterns, comes along as well.

These gathered headwords enter the character sheet’s “worldbuilding keywords” field. The intersection of the weaving and memory axes is automatically presented as a candidate, without the creator manually searching the Vault. Without a Vault, the creator would need to reread the IP’s sources and collect worldbuilding vocabulary by hand.

Relationship-map reference works similarly. The related fields and structured “related characters” sections of existing character headwords reveal the network among characters at a glance. The creator follows that network to decide where a new character should be placed and what relationship—mentor and pupil, rival, family, colleague—should connect them. Without the Vault, they must draw every existing relationship mentally while they work.

How multilingual publication uses a Vault

Publishing an IP in another language requires translation, and here the Vault’s translation-related columns become core material.

Each headword’s English-name, romanization, and translation-note columns are the materials a translator opens first. The “letter to the future translator” described in Chapter 5 is precisely this translation note.

Consider a concrete case. A translator encounters the term “Munmunja” in a manuscript and must decide how to render it in English. Opening the Vault’s “Munmunja” headword shows the following:

English name: Munmunja (the unwoven) Translation note: “Munmunja (無紋者)” is a composite concept in a world where all knowledge is woven into cloth. It refers to someone who can neither read nor weave patterns and cannot be translated literally. Rendering it simply as “illiterate” loses the world-specific implication of being unable to read writing woven into fabric. Define it once as “Munmunja (the unwoven),” then use “Munmunja” alone without the source term. Add the parenthetical explanation only at its first appearance in the manuscript.

Following this decision lets every translator of this IP render “Munmunja” in the same way. Without the Vault, each translator makes the decision independently: one chooses “Munmunja,” another “the unwoven,” another “illiterate,” and the same term is translated differently in volumes one and two of the English edition.

The alternate-name and alias columns are equally important. If “reweaving,” “Nubi forgery,” and “weaving again” all occur in the source text, the Vault makes clear that they refer to the same thing. A translator can then decide whether to unify them under one translation or preserve distinct translations. Without alias information, the translator may not recognize on first meeting “weaving again” that it is a concept already encountered.

When translation is complete, the translation decisions made in that process flow back into the Vault. The decision that “this term is fixed as this translation” is recorded in the translation note and reused in future translation work.

In the translation industry, such material resembles a termbase: a terminology database. Internationalization and localization systems such as ITS separately mark which strings should be translated, which terms carry particular meanings, and which notes should be shown to translators for the same reason. Translators need not only words; they need to know how those words are to be treated under which conditions.

This is exactly the information a Librarying Vault can give a translation team. Some proper names must remain untranslated in the source language; some terms need parenthetical explanation only at first occurrence; some aliases point to the same headword but should intentionally receive different translations depending on the scene. Once this information is in translation notes, translators do not repeatedly decide from scratch. They inherit decisions the IP has already made.

For multilingual publication, then, the Vault is not merely reference material. It is operating material that stores approved terminology decisions. When source spelling, official translation, forbidden spellings, whether to retain the source term, first-occurrence explanations, and cultural cautions are managed together inside each headword, translation consistency depends not on individual memory but on information architecture.

How encyclopedia and lorebook production uses a Vault

When producing an IP’s official encyclopedia or lorebook, the Vault itself becomes the source material.

The Vault’s 1,500 headwords become the encyclopedia’s 1,500 entries, and the LLM narration written in Stage 4 becomes the body text of those entries. If narration for hub headwords was written at encyclopedia-entry quality from the beginning, it can move into an entry with almost no revision.

The additional work needed to move from Vault to encyclopedia is editing and arrangement: arranging material for the order in which readers will encounter it, adding images and diagrams, and editing for publication format. Compared with the full time required to create an encyclopedia without a Vault, these tasks take far less time, because publication begins with the question “which entry should be written, and how?” already settled.

Creators who have experienced how encyclopedia and lorebook production changes after Librarying put it this way: “It used to take months to make one encyclopedia volume. With a Vault, we can focus only on editing and design.”

The role of a Vault in a B2B environment

Having covered the four exits, we can turn to the operating environment. B2B is not an exit through which the Vault produces something; it is an environment in which several teams share one Vault and divide update authority. Here the Vault is shared material between teams.

Suppose an IP development team, translation team, game-development team, and publishing team all handle the same IP. When the IP development team updates a setting, every other team must learn of that change immediately. Without a Vault, the update travels through email, documents, and meetings, so some teams receive it while others miss it. With a Vault, the moment it is updated, every team has the same current information.

The essential issue in this environment is update authority. The flow must be determined in advance: which team updates the Vault, and when the other teams receive that update.

In a typical structure, the IP development team also serves as the Librarying team. That team reflects official setting changes in the Vault. Other teams may read the Vault but do not edit it directly; when an edit is needed, they request it from the Librarying team.

Without this structure, several teams edit the Vault independently. The Vault then splits by team, and in the end there are as many SSOTs as there are teams.

A separate maintenance layer is added here. Building indexes, checking coverage to see which headwords have been sufficiently used, and regularly examining which hubs exert major influence on other headwords are not exit tasks like writing short fiction or translating. They are operational work for using a Vault over time. When automation exists, it should regularly produce snapshots of indexes, coverage, and influence; when it does not, a responsible person must at least record that state manually.

Over the long term, this Vault may move into a more structured knowledge base. Tools such as Wikibase are strong at letting many people collaboratively revise structured information and allowing people and machines to reuse it. If an Obsidian Vault is a workshop comfortable for people to read and write, a Wikibase-style knowledge base is an operating ground closer to querying, reuse, and public linkage.

There is no need to begin at that stage. What a creative team needs immediately is not a completed database but a Vault it can use today. Yet if frontmatter, the manifest, and headword relations are kept consistent, a path opens to move part of the material later into a knowledge graph or database. Librarying preserves that possibility while starting with a form people can actually operate.

With a Vault and without one

Let us place IP operation with a Vault beside IP operation without one.

Without a Vault, confirming a setting means searching source documents whose locations are only vaguely remembered. The same concept appears under different spellings in different manuscripts, and a new team member needs one to three months to grasp the world. Translators render the same term differently, and making an encyclopedia requires rereading source documents from the beginning and writing entries anew. Five years later, when someone other than the original creator takes over the IP, much of the world may exist only in the writers’ heads, making transfer itself impossible.

With a Vault, the situation changes. Confirming a setting is as simple as opening Obsidian and searching; every headword has one official spelling and all aliases are registered. A new team member can grasp the IP’s core by reading one hundred hubs. Translators carry forward unified translation decisions through translation notes, and encyclopedia production can focus on editing and design. A team newly assigned the IP five years later can open the Vault and understand the world from the beginning.

A Vault is a starting point

A Vault is not an endpoint but a starting point. From the Vault that Librarying creates, short-form writing begins, character sheets are made, and translation proceeds. New vocabulary and decisions arising from those tasks then return to the Vault through backflow. A Single Source of Truth ultimately means that every team, every task, and every tool looks to the same Vault.

Chapter 13 is a practical retrospective. It candidly records what was learned while directly shaping 1,500 entries, what differed from expectations, and what I would do differently if I did it again.