Chapter 2. The Producer and the AI Work Partner: A Wiki Built with Two Hands

Tolkien never succeeded in binding The Silmarillion into a book himself. Notes first written in a notebook in the trenches of the First World War accumulated on his desk for almost fifty years until his death. Tribes and languages, dynasties and place names, generational genealogies all continued to multiply, and he tried to unfold every line with his own hand. In the end, the material remained without becoming one book. The person who gathered the scattered material and bound it into a book was his son, Christopher Tolkien. The son was not the author; he was the person who gathered his father’s materials and organized them into one encyclopedia and one collection of myths. We call that role the producer.

When people hear “build 1,500 headwords,” they commonly imagine one person sitting alone at a desk and arranging headword after headword: the image of an author. Work according to that image, and it takes six months.

Librarying begins from a different image. There are four stages—first extraction, second integration, third skeleton build, and fourth narrative writing—and two kinds of hands pass through them. One hand decides; the other hand produces.

Creative Industries Have Divided Hands for a Long Time

Consider how a film is completed. A director decides direction in front of the camera, selects the final cut in the edit suite, and judges how music fits. But for all those decisions to operate in reality, someone must budget, coordinate the shooting schedule, and manage dozens of teams so they work without collision. The director decides; the producer builds.

The same structure exists in every creative industry: music, publishing, and games. At ZA/UM, which made Disco Elysium, lead writer Robert Kurvitz set the standards for worldbuilding and tone, while multiple writers produced one million words under those standards. When CD Projekt Red made the enormous dialogue of The Witcher 3, a small number of leads set the direction while many writers produced material quest by quest. Only when the role that decides and the role that produces are divided does work at a wider scale become possible. Librarying’s separation of people and AI work partners is an extension of this old division of labor. It is not a new idea; only the producing hand has changed from a person to AI.

Not an Author, but a Producer

Within this division of labor, this text calls the reader not an author but a producer.

Author is a natural name in Korean and English alike. Someone who writes, makes stories, or shapes keywords may all be said to do an author’s work. But the word author has one narrow sense: it points to the person who writes text directly, sitting before paper or screen and unfolding line after line with their own hand. That is the typical image of an author.

The territory this text addresses is broader. It concerns the person responsible for the whole process by which one IP’s materials travel from scattered inputs to one encyclopedia-like wiki. That person may write every line with their own hand; an AI work partner may first produce some lines while they only review; or another person may raise some lines through outsourcing. In every case, one person decides the materials’ final passing line, and this book calls that person the producer.

One person may hold both names at once. If they write every line by hand while taking responsibility from input to output, they are both author and producer. A person may hold only one of the two: someone who does not write directly but decides the materials’ final passing line is a producer, not an author.

The stream of consciousness in librarying is closer to a producer’s. It heads not toward “How can I write one line beautifully?” but toward “What kind of encyclopedia should 1,500 headwords become?” The work of author and producer overlaps, but is not the same. Where the two divide, this text follows the producer’s side.

Why Six Months Became 9–16 Hours

Can this producer build a 1,500-headword wiki alone?

It is possible. It just takes time. Suppose each headword’s prose is 200 to 1,000 Korean characters and one person needs thirty minutes to one hour to produce one entry. Then 1,500 headwords multiplied by an average of forty-five minutes is 1,125 hours. Even at eight full hours per day, that is 140 days; excluding weekends, more than half a year. And that is only the time for fourth-stage narrative writing. Add first extraction, second integration, third skeleton build, verification, and updates, and another month enters the total. A person who carries librarying only by hand therefore spends roughly six months on one IP.

Those six months are not hypothetical; they are time experienced in actual work. Building a keyword cloud for one IP took six months, and even after it was built, every new short story brought days of update work. As those days accumulated, another month passed. Six months to build and another month to operate means you can organize one IP about once a year. That may be possible when operating only one IP, but once you begin to operate two or three, it becomes difficult to bear.

When the load cannot be borne, material is not updated. Unupdated material moves away from the work over one or two quarters. A person newly introduced in a short story spends a month outside the wiki; a keyword whose name changed in a revised rulebook remains in the wiki under its earlier notation; a discarded mechanism is still marked current. This is the point where the wiki begins to lose function by drifting away from the work.

Two changes made regular librarying possible: the organization of the procedure and the introduction of an AI work partner. For fourth-stage narrative writing alone, the AI work partner reduced 1,125 hours to five to ten hours. Add the first, second, and third stages and verification, and the work enters a range of nine to sixteen hours. Six months became a day or two of work.

The Stance of an AI Work Partner

There is one more name that will appear often in this text: AI work partner. The AI discussed here means the text-generation support tools readers may have used once or twice in daily life: tools that produce an answer when given a one-line question, organize a paragraph of document, or convert one table into another format. This book does not name a particular company or model because the procedure applies unchanged regardless of the reader’s environment.

This book calls AI not a tool but a work partner, and that name contains a small intention. The word tool points to an object a person uses one-sidedly. When we call a hammer a tool, we expect it only to repeat one fixed motion accurately. A hammer does not ask, “Should I strike at a slight angle this time?” If it did, it would lie outside the category of tool.

AI is not such a thing. More exactly, in some situations it operates like a tool, and in others it holds a broader role. In first extraction, where it reads normalized input documents and produces a nine-classification table, and in second integration, where it produces synonym candidates, the AI work partner operates like a tool that rapidly repeats a fixed output for a fixed input. The stage that creates the organizational information attached to the head of each file in the third skeleton build—called frontmatter and treated in detail in Chapter 7—is even more decisive. There, fixed transformation rules and an automation contract matter more than AI inference.

But in fourth-stage narrative writing, the situation changes. When composing prose for one headword, AI does not merely receive and repeat a definition. It infers what weight that headword has within the IP context, looks at relationships to other keywords, and composes prose in the right tone. Sometimes the result is 100 percent satisfying, and sometimes only 50 percent. Yet even a 50-percent passage may contain one line worth saving; the person saves that line, asks for the rest to be written again, and AI produces again. This back-and-forth happens two or three times within one headword until it crosses the passing line. The closer metaphor is the relationship between editor and writer, with the AI work partner taking the producing role within that exchange structure.

One point should be clear. Calling an AI work partner a partner does not place it on the same level as a person. The producer decides the passing line. The producer decides whether the partner’s prose passes, whether prose that has not crossed the line after two or three exchanges should be discarded or handled another way, and what weight a headword should carry within the IP. This authority of decision belongs to the person; the AI work partner receives those decisions and produces.

This asymmetric relationship is the precise shape of the two hands described in this book. The two hands work together, but they do not do the same work. One hand decides; the other hand produces. Drawing the boundary of that division accurately is the secret by which librarying finishes within nine to sixteen hours.

The Four Axes of Collaboration

To address this division in detail each time throughout the text, we have set a single analytical frame. Four questions repeat at every stage across all fourteen chapters: What do we give and receive? Why assign this specifically to an AI work partner? What improves when we assign it? What cannot be assigned? The difference between people who obtain the results they want and people who keep being disappointed by the same tool arises here. If you merely throw out, “Please write this headword description,” AI fills it with general knowledge. If you say, “This headword plays this role against this era background in this IP; the narrative tone must match this example; the length must be within 200 characters,” it produces in a much closer direction. These four questions make the difference.

We give these four questions short names: specification, intent, expected effect, and limit. In this text, we call them the four axes of collaboration.

Introductions to commercial AI tools usually stop at “use it this way and it is fast and good.” The four axes of collaboration do not stop there. At every delegation, they ask without omission: What do we give (specification)? Why do we assign it (intent)? What do we gain (expected effect)? Where does the person stop (limit)? The four axes are therefore not a delegation checklist but a distinct analytical frame. Even a reader who does no librarying can place these four questions on their own work; at that point, there is a difference between “used a tool” and “commanded a tool.”

Specification is the format that decides what is given to the AI work partner as input at that stage and what is received as output. If you merely say, “Please organize this document,” one result is a table, another bullet points, and another a paragraph, and time is spent only unifying the next stage’s format. So at the beginning of every stage, decide the input format, output format, and field composition in one line before starting.

Intent is one line that states the purpose of delegation: why this stage is assigned to AI rather than done directly by a person. If the intent was time reduction and the result arrives in five minutes, the intent is fulfilled. If the intent was consistency and notation varies wildly across 1,500 headwords, the intent is unfulfilled. The same output thus passes or fails according to the intent. In librarying, the intent of delegation usually reduces to one of three: time reduction that turns a one-hundred-hour manual task into five hours; consistency that prevents tone drift between the first and 1,500th headwords; and 1,500-unit processing that handles a quantity one person’s mind cannot hold at once.

Expected effect is the concrete yield gained through delegation. If the intent is time reduction, it is the line “one hundred hours become five”; if the intent is consistency, it is the line specifying which consistency is guaranteed. Without deciding it in advance, a reader has difficulty judging satisfaction when designing the same collaboration in their own environment. The judgment “I tried AI too, but it was not very good” usually comes from a place where the expected effect was never set in advance.

Limit is the part delegation cannot reach, the part a person must review. The limits encountered at every stage of librarying usually arise from materials that exist only in the mind of someone who has read five years of works: keywords whose meaning changed with changes of era in the IP; in-jokes and quotations within the series; people and objects that appear only as pronouns; and viewpoint and chronology notation. By marking each stage’s limit explicitly in one line, we clarify what a person must review.

Work That Delegates Well and Work That Does Not

Now that we have set out the four axes, let us spread out at once which parts of librarying delegate well to an AI work partner and which remain human work.

Work that delegates well has common traits. First is mechanical repetition: repeating the same-format task 1,500 times. A person tires and loses tonal consistency when carrying it by hand, while an AI work partner maintains the same stance in the first and 1,500th item. Second is format conversion: moving one table row into the frontmatter of a wiki file, or compressing a paragraph into a bullet list—conversions with clear rules. Third is candidate generation: AI rapidly produces candidates for synonyms, worldbuilding axes, and related keywords, and the person selects those that cross the passing line. Fourth is first-draft writing: when the passing line is not 100 percent, the person receives a roughly 80-percent first draft and refines the remaining 20 percent to reach the line.

Work that does not delegate well has common traits too. First is judgment: deciding whether two keywords are the same headword, whether to establish a new worldbuilding-axis system, or whether one prose entry passes. Second is IP-specific subtlety: jokes and quotations across five years of work, changes over time, and traces of discarded proper nouns. Third is the big picture: deciding to rebuild the worldbuilding-axis system itself when an IP faces a large transition, and deciding hub priority. Fourth is the final passing line: after completing the entire volume, opening the integrated build, looking at Graph View at once, and deciding, “Is this truly our encyclopedia?”

When the line dividing these two areas is clear, collaboration is smooth. When it blurs, one side spends time on decisions while the other repeatedly discards what it produced.

Passing Lines and Review

One concept that determines the texture of collaboration is the passing line: the standard that separates an output into pass or fail. It is like deciding in advance whether 60 or 70 is passing on an exam; it is also like the chef looking once before a dish leaves the kitchen and passing it through.

In librarying, the passing line differs by stage. First extraction is generous, around 60 percent: duplicates, typos, and missing entries can be sorted by a person in the next stage. Second integration is strict, around 95 percent: if synonym grouping is wrong, the entire wiki drifts, so a person decides directly. Third skeleton build is 100 percent: if an automatic transformation rule is wrong in one place, it is copied identically into 1,500 files, so a person checks the rule itself before execution. Fourth narrative writing divides by headword weight: hub headwords require 95 percent and leaf headwords 80 percent.

Chapter 8 addresses what hubs and leaves are; for now, only note that a hub is a core headword and a leaf a peripheral one.

The passing line differs by stage because the stance of review must differ by stage. Ultimately, how a person holds the stance of review decides collaboration’s passing line.

In one line, the stance of review is this: accept 80 percent of the passing line and let the person supply the remaining 20. Expecting 100 percent makes collaboration burdensome. The person becomes frustrated every time the AI work partner does not produce 100-percent output; as that frustration accumulates, they discard collaboration itself and carry everything by hand, and the six months return.

If the collaborators agree not to expect 100 percent but to receive 80 percent, collaboration becomes light. The AI work partner produces 80 percent, and the person adds 20 percent to reach the passing line. The 20 percent the person takes on comes from decision, compression, and passing-line judgment. Reading one paragraph of AI-produced prose, marking “keep this one line and rewrite the rest,” then requesting another draft—that is the 20 percent. This 80-to-20 ratio follows the same principle writers have long used: quickly produce a first draft and refine it through revision.

The location of 80 percent differs by stage. In first extraction, 80 percent means the classification only needs to be correct. In second integration, it means only human decisions remain to be made. In fourth narrative writing, it means the core of one headword is present and the tone fits. Because what 80 percent means differs by stage, every chapter specifies it in one line.

What the Four Axes Leave Behind

For some readers, librarying may not apply directly to their own IP. They may never have operated an IP for five years, handled material at the scale of 1,500 headwords, or used Obsidian. If such a reader takes one thing from this text, it is the four axes of collaboration. They are not an accessory attached to librarying but an analytical frame that works outside it. Even without ever building a Vault, placing the four questions—specification, intent, expected effect, and limit—on any AI delegation changes the texture of delegation.

They apply to readers who write, draw, code, or organize materials at work. The difference between people who obtain good results and those who keep being disappointed while using the same tool lies here.

Librarying is work built with two hands. One hand decides; the other hand produces. The hand that decides is human; the hand that produces is the AI work partner.

In the next chapter, we will unfold at once the full four-stage flow through which these two hands pass together: first extraction, second integration, third skeleton build, and fourth narrative writing.