Chapter 1. From Glossary to Cloud: The Changing Materials We Handle

It is impossible to explain Star Wars in one word.

The moment we say, “a battle of good and evil set in space,” something important slips away: first, the Force. Star Wars without the Force is difficult to call Star Wars. But once we include the Force, the Jedi Order naturally follows; once we include the Jedi, lightsabers follow; once we include lightsabers, Darth Vader follows; and once Darth Vader appears, the line “I am your father” follows in a chain.

There are the Rebel Alliance and the Galactic Empire, the Death Star and the Millennium Falcon. These things do not exist separately. They interlock: Jedi and Darth Vader connect, the Force and lightsabers connect, the Rebels and the Empire connect.

Star Wars is this entire network of connections. It is not one word; it is the network of relations woven among those words.

The reader’s IP is the same. Whether it is a novel, game, webtoon, or rulebook, explaining an IP in one word becomes a lie. How all the words that constitute that IP connect to one another—that is the IP.

The work we call librarying is the deliberate construction of that network. It brings the network that lived only inside a creator’s head out into material that can be seen and touched. This text guides that work across fourteen chapters.

When Materials Are Not Connected

The desk of someone who has operated an IP for about five years usually looks like this.

If there are rulebooks, perhaps seven volumes are piled up: the core books have split into first, second, and third editions; a couple of supplementary books are wedged between them; and one aborted “edition zero” remains from a time when they tried to rebuild everything. If short stories have accumulated, the folder easily holds more than a hundred, and an external wiki sits open on one monitor. Pages someone began five years ago and then stopped touching have accumulated to nearly a thousand, but fewer than two hundred are alive. Open the planning folder and you find perhaps thirty files with the same name in different versions: v1.0, v1.1, v1.1_revised, v1.2_final, v1.2_final_final.

When you try to write a new short story at such a desk, small questions immediately catch your feet: what was the name of the person who appeared in a rulebook three years ago? Where in the planning documents was that person’s faction written? In which short story did the group hostile to that faction first appear? To answer them, you have no choice but to search through seven rulebooks and one hundred short stories one by one. There is no search, no link, and the same word is not arranged consistently in any material.

In the end, the writer makes a new person with a similar name, changes the setting slightly and uses the existing person, or simply moves on. Small contradictions then begin to accumulate in the IP. One person has two names; the date of one event differs between two books; the description of one place changes between an earlier and later work. As the IP grows, the amount of contradiction grows with it.

This is the reality of dispersed materials. It is not a problem caused by the absence of terms, but a problem caused by the absence of relationships.

An Old Problem

This problem is not new. Tolkien left enormous handwritten notes over decades, but because the material was not systematically managed, his son Christopher needed decades more to organize it after Tolkien’s death. Frank Herbert’s Dune world likewise presented significant reconstruction difficulties when his son continued the series.

In the era of web novels and webtoons, the problem emerges at a much larger scale. Over hundreds of serialized episodes, dozens of people and hundreds of proper terms must be managed consistently. Fans may step forward to build a wiki first, but it remains readers’ material, not the writer’s internal material. Readers’ interpretations and misreadings inevitably enter it, and above all it does not function as a tool the writer can keep beside them while writing the next episode.

An IP’s materials are not organized in one place. This problem remains unsolved even now.

Glossary as the First Answer

The first answer to this problem is a glossary: a single table that lists the proper nouns, technical terms, and worldbuilding keywords in a work in order, with a short definition beside each entry.

The way of making a glossary is familiar to everyone. When beginning a work, a writer keeps a separate glossary page in one corner of their notes and adds one line whenever a new term appears. Within the boundary of a single work, this method is sufficiently efficient: opening the glossary lets you see at once which people are missing and which mechanisms remain undefined.

But the moment there are two works, the landscape begins to change. New entries from the second work must be added to the first work’s glossary, and among them may be someone already mentioned in one line in the first work. You must first decide whether they are the same person or different people. If they are the same person, the first work’s one line must be reinforced with information from the second. As works grow to five or ten, the number of such decisions grows explosively.

A glossary fails not simply because the quantity is large. The form of a list itself is structurally mismatched to the nature of IP knowledge.

The list form has two defects.

First, it cannot hold the relationships between entries. You may write “Related: A, B, C” to indicate where a person was born or what role they played in an event, but to confirm what each of A, B, and C is, you must turn through the list again from the beginning. Even when a relationship is recorded, it is inconvenient to travel along that relationship.

This matters because the core of IP knowledge lies not in facts but in relationships. “A person has a certain name” is far less important information than “why did that person clash with this other person in this event?” A material format in which relationships cannot be followed comfortably reveals its limit in representing that core.

Second, a list is one-way. Even if Person A’s entry says “Related: Place B, Event C,” going to Place B’s entry does not automatically show the reverse information, “People related to this place: A, D, E.” To maintain reverse information, you must write the same content by hand in both Person A and Place B. As entries increase, such manual maintenance becomes increasingly unrealistic.

Let us see how these two defects appear in actual work. Suppose you need to revise a place called “Hunsford Parsonage” in an IP, so you find and correct that entry in the glossary. To find all the events that took place at Hunsford Parsonage, scenes set there, and stories of people in which it appears, and then make them consistent, you ultimately have to read the entire glossary again from the beginning. There are no links among the entries.

Without connections, it is difficult to see how changing one side affects another. This is the structural cause of the frustration creators experience as an IP grows.

A Form That Holds Relationships

The alternative that begins with the glossary’s failure is the idea of connecting entries directly to one another.

Paper encyclopedias often include notation such as “→ See: entry name.” The idea of directly joining entries is, in fact, quite old. A paper encyclopedia tried in its own way to implement the chain in which a reader moves from A to B and then from B to C.

The internet fully realized this idea. The core idea of the World Wide Web is connecting documents to documents with links, and Wikipedia is the result of applying that idea to an encyclopedia. You can read “Napoleonic Wars,” click through to “Battle of Trafalgar,” then move again to “Admiral Nelson.” Any entry also displays documents that refer to it, allowing reverse connections to be checked.

Interestingly, popular IPs eventually grow into the shape of such linked encyclopedias. I often use Omniscient Reader’s Viewpoint as an example: its original web novel, webtoon, and film divide into large entries and are linked to one another; from one person you can immediately move to the event and worldbuilding setting they belong to. Popular Korean web novels, in the end, grow into encyclopedias whose headwords link to one another. In games, the makers of League of Legends operate an official lore site called Universe, providing a linked canon database that lets you move directly from one champion to the region and events they belong to.

Applied to IP-material management, the picture looks like this. Within a person’s page, the events they are involved with, the places where they often appear, and the mechanisms they use are all linked. The event page lists other people tied to that event; the place page links again to events set there.

This is the idea of managing IP material not as a list but as a network. We call this connected network a keyword cloud. If a glossary is a list with no connections, a keyword cloud is the network of relations in which those keywords are connected.

Here, the links themselves are information. A link between two entries contains an editor’s judgment that the two are related in some way within the IP. Entries with dense connections therefore sit near the IP’s core, while entries with few connections sit at the periphery. Follow the links and the IP’s terrain appears naturally.

The Day I Opened Graph View for the First Time

There is a tool that realizes this idea: the note tool called Obsidian.

Obsidian stores every note made by the user as an .md file inside a working folder. .md is the extension for Markdown, a format that adds a few light symbols to plain text to mark headings, emphasis, and links. It is not a heavy format like a Word file; it is light text that can be opened even in a simple text editor.

Obsidian lets these .md files connect freely with the notation [[entry name]], which is commonly called a wikilink. Obsidian spreads the network connected by wikilinks across one screen in a view called Graph View: dots float on the screen and lines run between them.

There was a day when I moved five years of material into Obsidian and opened Graph View for the first time.

Until then, I could not even estimate how much material there was. I knew the number of entries in the glossary, but I had no way to know how those entries connected to one another; which person was the actual center of the IP; which person unexpectedly stood on the periphery; which event connected to the most headwords; or which concept supported the world most deeply.

Once Graph View opened, these things began to appear. Which areas of the IP were dense and which were empty; which person connected to far more headwords than expected and which stood isolated—all of it entered the eye at once as a landscape of material that a glossary could never reveal.

That was the moment I moved from glossary to cloud.

The Work Called Librarying

We call this work of building an IP’s materials into a cloud librarying.

If a library means a library or encyclopedia, librarying turns the work of building that encyclopedia into a verb. Building one IP’s library is what we call librarying.

There is a small intention in this name. Just as a library is not finished once it has been built, librarying is not work that ends after building once. When a new book arrives, you examine the classification system and decide where to place it. When shelves fill, you bring in new shelves. When classification becomes disordered, you sort it again. Like library operation, an IP’s keyword cloud is living material.

The library metaphor carries another meaning. A library does not merely stack books: it classifies them, gives every book a number according to a fixed standard, and assigns a location. Without classification a library is only a warehouse; no matter how many books it holds, if they cannot be found, it is as good as having none.

Librarying is the same. The goal is not to stack keywords, but to classify, connect, and make them findable. The four-stage work toward that goal is the body of librarying.

It Is Not Making a Wiki

Let us cut off one misunderstanding here. Guides to making a wiki with Obsidian are already common; search and dozens appear. But librarying is not that wiki-making. The difference is not the vessel but the method of cutting.

Librarying does not list keywords in Korean alphabetical order or order of appearance. It divides them by narrative function. It first asks whether a word is a person, mechanism, or value. Cross that with a worldbuilding axis designed differently for each IP, and two-coordinate searches become possible, such as “only people headwords tied to the Association in Gongdong” or “only object headwords attached to a dungeon.” A dictionary with only one classification standard cannot do this.

The result therefore has a different status. If a fan wiki is for a reader’s reference and a note-app vault is a private aid to memory, the Vault built by librarying is the one original from which a producer operates the entire IP. New short stories, new characters, foreign-language translations, and encyclopedias all pass through this one book. The vessel may be the same Obsidian, but what is held and how it is held are different.

A Graph Read by People and a Graph Read by Machines

At this point, librarying touches the larger current of the knowledge graph. In Wikidata and its underlying tool Wikibase, multiple people collaboratively correct the same knowledge, while the result remains as structured data a machine can read. A person reads an entry’s name and description; a machine reads its properties and relationships. The same material is read in different ways by people and machines.

Librarying’s Vault does not aim to build such a structured database immediately. Obsidian .md files are closer to what people read easily, and a producer needs to be able to open them directly while creating. But the moment headword, aliases, nine classifications, worldbuilding axis, related keywords, and sources are divided into consistent fields, this Vault too begins to take on the character of a machine-readable knowledge graph.

So to call librarying “making a wiki” makes it too small, while calling it “a completed knowledge-graph system” goes too far. It lies exactly between the two. It begins as an Obsidian Vault fitted to a human hand, while organizing an IP’s relationship network in a form that can later move toward structured data and knowledge graphs.

The Four-Stage Flow

The inputs to librarying include scattered documents such as rulebooks, short stories, planning documents, external wikis, and scripts; the output is an Obsidian wiki. What connects the two are four stages: first extraction, second integration, third skeleton build, and fourth narrative writing.

First extraction draws keywords from every input. It records without omission every person, place, object, event, mechanism, concept, and value appearing in a rulebook, according to nine classifications. It does not worry about duplication; even if the same person appears under another notation, it extracts the term as it is. The first-extraction result for one IP becomes an enormous table of 5,000 to 15,000 rows.

When that table enters second integration, terms with the same meaning are gathered under one headword. A headword is the form in which a keyword is formally registered, like an entry in a dictionary. For example, if three notations—“Black Fog,” “black smoke,” and “Tenebre”—are gathered into one headword, the row aligns English and Korean, definition, related keywords, and translation candidates. The result reduces 5,000–15,000 rows to 1,000–2,000 headwords.

Once the headword table is ready, the third skeleton build converts it into 1,500 Obsidian .md files. One headword becomes one .md file; inside it are a definition, detailed description, and wikilinks to related keywords, with a writing space still left empty.

The final fourth narrative-writing stage fills that writing space with prose for each headword. Each headword ranges from 200 to 1,000 Korean characters. In the modern hunter-fiction world of Gongdong, for example, it does not stop at the one-line definition “Density is the density of mana that seeped from gates.” It unfolds, in one flow, what the concept means within the IP’s world. Only after 1,500 writing spaces have been filled with such prose is an IP’s keyword cloud complete.

The essence of the first, second, and third stages is mechanical organization; the essence of the fourth is writing. The difference between these two essences divides the nature of the work. It also determines the texture of the collaboration with an AI work partner, the topic most important to this text.

Work Built with Two Hands

Can one person build all 1,500 .md files?

It is possible. But if one person carries it entirely by hand, it takes months. In the days when we worked only by hand, librarying one IP took close to six months. Work that takes six months is eventually not done often; when it is not done often, materials are not updated; materials that are not updated eventually become dead materials.

Two changes made it possible to operate librarying regularly as it is now. The first was procedural organization: we established the four-stage flow and decided the input, output, and passing line for each stage in advance. The second was the introduction of an AI work partner.

Librarying works without AI. The methodology itself is independent of AI: so are the four-stage pipeline, the nine-classification system, the design of two coordinate axes, and the thirteen-column headword structure. Many unfamiliar terms have appeared at once, but there is no need to memorize them now. Chapters 4 through 9 will unfold them one by one. The important point here is that these were methods implementable by hand before AI appeared, and in fact were implemented that way for a long time.

The current operational workflow, however, assumes an AI work partner and an automation contract. Current librarying takes a method possible by hand and makes it repeatable in a workable amount of time, across multiple IPs. AI does not replace the methodology; it brings that methodology into sustainable operating time.

The work assigned to AI is concrete: mass processing in first extraction, extracting synonym candidates, and drafting the first version of fourth-stage narrative writing. Work that takes months by hand can finish in a day or two through collaboration with AI.

But decisive judgment always belongs to a person: deciding whether two notations refer to the same person, what to name a headword, how to design the worldbuilding axis, and whether writing has crossed the passing line. These final decisions belong not to AI but to people.

Saying AI writes 1,500 entries can sound like mass production, but the truth is the opposite. A few representative hub entries directly written by the producer set the voice for the remaining headwords. AI is the hand; the producer is the voice. The hand is fast, but the voice decides what to write and in what tone.

When the two roles work together, that day or two is actually nine to sixteen hours of work. Frankly, the first cycle takes longer; before the process becomes familiar, it takes about 1.4 times as long as expected, and settles into this range from the second or third cycle. Even so, six months have become a few days.

At each stage, this text identifies line by line what is exchanged, why it is delegated, what improves, and how far a person must decide directly. It is not a vague pamphlet saying “AI is good to use,” but a text that clearly distinguishes where the person stops and where the tool begins.

Relationship to the Sister Texts

Two sister texts continue alongside this one: Seoyeongak and New Character Build.

Seoyeongak deals with the work of reading a foreign-language work deeply. Taking a work such as Jane Austen’s Pride and Prejudice, it unfolds across fourteen chapters a six-stage process for precisely analyzing and documenting people, events, worldbuilding, and language before entering translation and adaptation. New Character Build deals with making one person from zero.

This text deals with building the common material foundation used by both sister texts. If Seoyeongak is the work of reading a work deeply and New Character Build is the work of shaping a person, Librarying is the work of building one encyclopedia through which both that deep reading and that person-making pass. This text can be followed independently even if the sister texts have not yet been read.

The Flow Ahead

Let us spread out the flow of fourteen chapters in advance.

Chapter 1 has set the direction of moving from glossary to cloud, from list to network, and from one person to two hands. Chapter 2 looks more closely at the roles of producer and AI work partner, and Chapter 3 spreads out the full four-stage flow at once.

From Chapter 4, full work begins. Chapter 4 covers the method of first extraction, Chapter 5 second integration, and Chapter 6 the two classification standards: nine classifications and the worldbuilding axis. Chapters 7, 8, and 9 concern the shape of a Vault: Chapter 7 covers the third skeleton build, and Chapter 8 the classification of hubs and leaves. Chapter 9, the climax of this text, examines in detail across an entire chapter the specification for fourth-stage narrative writing: a few representative hubs written directly by the producer determine the tone of the rest, and an AI work partner fills the headwords in that tone.

Chapters 10, 11, and 12 handle verification and operation; Chapter 13 is a practical retrospective; Chapter 14 is the closing chapter.

Returning to the Network

Let us return to Star Wars at the beginning.

How the Force, the Jedi, lightsabers, Darth Vader, the Rebel Alliance, and the Galactic Empire connect to one another is Star Wars. That network first existed in George Lucas’s head; the network in his head became rulebooks, film scripts, and character-setting books. Because those materials were sufficiently organized, Star Wars remains consistently alive in the hands of other producers even a generation later.

If v1.2_final_final is still somewhere in a folder and the relationship network has not been organized in one place, after passing through all fourteen chapters something finally becomes visible: which person is the actual center of the IP, and which concept supports the world most deeply.

We now begin fourteen chapters of deliberately building that relationship network.