Chapter 13. Consistency, Versions, and Illustration — A Living LOREBOOK

From its first edition in 1987 to its fifth edition in 2024, D&D's Forgotten Realms has undergone five major revisions over roughly thirty-seven years. About two hundred anthologies, novels, and campaign modules appeared in that time, adding new characters, cities, and events to its LOREBOOK. Faerûn moves from 1372 DR to 1492 DR; a city called Zakara becomes the base of a rising power; the life of the wizard Elminster is retold by new writers. Those thirty-seven years exemplify what it means to say that a LOREBOOK is alive. An IP's material does not stop at publication. It continues through small quarterly and annual updates and large new editions on five- and ten-year cycles.

After v1.0 is published, regular updates taking roughly two to three days each quarter keep the LOREBOOK alive.

While an IP is operating, new short stories appear, characters are updated, the Vault receives incremental changes, multilingual editions are added, and entry names change. The LOREBOOK follows each change. A small quarterly update and a major new edition every five to ten years form the two layers of operations. If the first cycle transformed the book's material into a book, operations turn that book into material that follows time.

This chapter covers those operations: consistency checks, version control, illustration commissions, AI-illustration policy, update cycles, and the shape of five years of operation. It begins where the first cycle ends and follows the work until operations are established.

Consistency checks — a small quarterly inspection

The first part of operations is consistency checking. Chapter 11 covered it as Phase 4; in operations it runs regularly every quarter, after new short stories are published, and after character-sheet updates.

It has three stages. The first is an automated check. A review script catches dead links, duplicate entries, frontmatter consistency, absolute prohibitions, and noun grep in a first pass. It takes roughly one to two hours and runs once per quarter, within one week of a new short-story publication, within one month of a new season or major IP update, and within one month of a final character-sheet update.

The second is a manual sample review. After the automated check passes, a person directly reviews a random sample of thirty to fifty of the 1,500 entries. This handles subtle issues automation cannot catch. It takes about one to two days and proceeds alongside the automated check. Distribute samples evenly among parts—about three to five per part—follow a 1:2:7 ratio of hub, standard, and card types, and give priority to recently updated entries.

The last stage is an integrated-build review. Because it is demanding, it does not run every quarter. It runs only immediately before first-cycle publication, immediately before a new edition such as v2.0, and after a major IP update such as a season change or a large alteration to the world. A person builds the whole LOREBOOK, reads it through as one book, and makes the final judgment on whether it clears the standard.

Together, these stages create a layered system that prevents material from drifting apart during operations. Automated checks catch first-order issues each quarter, manual samples repair subtle points, and integrated builds inspect the whole book at major turning points.

Synchronizing with the Vault

The core of LOREBOOK operations is synchronization with the Vault. Because Librarying's output is LOREBOOK's input, a Vault update must update the LOREBOOK as well. This has two forms.

The first is a bulk update from Vault to LOREBOOK. When an entry's name changes in the Vault or a new entry is registered, the LOREBOOK receives and reflects that change.

Consider the hypothetical IP “○○.” Suppose Librarying's second consolidation changes an entry from “Black Hole” to “Dark Abyss.” Librarying's third rebuild creates a new .md file and isolates the old file with version=deprecated. Replace the old term with the new one throughout LOREBOOK body text and editorial notes, using sed automation or Obsidian bulk change. Add the old name to the LOREBOOK frontmatter's aliases, so a reader searching the old spelling still reaches the new entry. Finally, add to _checklist.md: zero remaining old-term occurrences in body text, 100 percent aliases registration, and a change-history entry in Appendix 1's glossary. This entire flow takes roughly one to two hours.

The second is two-way feedback for new terms. During LOREBOOK work, a new term absent from the Vault may emerge, naturally introduced by a new short story. Tag the LOREBOOK entry's editorial note as Vault unregistered: [term]. In the next quarter's first and second incremental Librarying cycles, register the term under one of the nine classifications and fill its thirteen columns. The third skeleton build creates the new .md; the fourth narrative-writing stage fills it with prose. Then update the LOREBOOK editorial note from “Vault unregistered” to [[term]] and refresh its frontmatter directly from Librarying frontmatter.

The faster and more automated this feedback cycle is, the lighter operations become. A regular quarterly run is therefore recommended.

Version control — one tree with git tags

The second part of LOREBOOK operations is version control. Once the first cycle publishes v1.0, updates proceed through v1.1, v1.2, and v2.0.

The convention is simple. Versions v0.x are internal pre-publication stages—v0.1 draft, v0.2 first revision, v0.3 consistency passed. v1.0 is the published edition; v1.x are minor post-publication updates; v2.0 is the next edition. v_confirmed means that one entry or item will no longer change, and is used when downstream work such as illustration commissioning depends on it. v_final means a v_confirmed item that has also passed the final integrated-build review.

Use a single tree managed with git tags. Do not use directory branching such as v1.0/, v1.1/, and v2.0/: it duplicates entry .md files by version, breaks the single-Markdown-source principle in Chapter 1, and causes cross-reference links to break across directories.

With git tags, all material remains in one tree and git's point-in-time snapshots determine versions.

[Project LOREBOOK]/  (one tree, git-managed)
   │
   ├─ git tag v0.1   ← draft (end of Phase 3)
   ├─ git tag v0.2   ← first revision (end of Phase 4)
   ├─ git tag v1.0   ← published edition (Phase 6 printing complete)
   ├─ git tag v1.1   ← small adjustments at reprint
   └─ git tag v2.0   ← next edition

This preserves the single-.md principle and keeps cross-references clean. A directory branch such as v1.x_archive and v2.0 is natural only when v2.0 fundamentally changes part composition—for example, expansion from ten to fourteen parts, or major merger and division of parts. Use git tags for everything else.

At every version update, record the changes in _progress.md: for example, “v1.1: added quotations from short stories 047, 052, and 061; updated the male-shaman entry in Part 9 §3.” This record becomes material that follows the LOREBOOK's operational time. Readers can see its evolution between v1.0 and v2.0 in one place, and when publishing a new edition, the record reveals which parts of v1.x were updated most often and helps decide the next edition's structure.

One principle for commissioning illustration

The third operational area is illustration. Chapters 11's Phases 3 and 6 covered commissioning procedures, but illustration additions continue during operations.

One principle is decisive: commission illustration only after the body text is v_confirmed.

If illustration is commissioned before the body text is stable, a text update requires another illustration commission and creates high recovery cost. A human artist spends more than five times the time for one illustration than for one text entry; if a character's appearance changes after an approved draft, the approved draft itself may have to be discarded. To prevent this cost, begin commissioning only after body text clears its v_confirmed threshold.

For a standard twelve-part LOREBOOK of roughly 450 B5 pages, suggested illustration quantities are: three cover images—front, back, and spine; two to four endpaper images of maps or world vistas; one frontispiece; twelve part-opening illustrations; thirty to fifty character illustrations; twelve to fifteen full-color chapter headers; five to ten maps; twenty to forty diagrams; and fifty to one hundred small atmospheric cuts. Adjust these numbers to the reader's IP.

Write a specification card for every illustration and place it in the entry's editorial note.

<!--
Illustration specification:
- Type: part opening / character / map / diagram
- Scale: full page / half page / side / small cut
- Description: [core visual; scene to draw from the text]
- Tone: cyberpunk / East Asian / beyond dimensions / everyday life
- Characters: [character-sheet [[name]]]
- Palette: which color to emphasize from the five-color palette
- Commission status: uncommissioned / commissioned / draft / approved / complete
- Artist: ___
-->

These cards are the material for commissioning. Let an AI collaborator draft them automatically, then have a person review them.

Send an artist five items with each commission: the entry body .md containing the visual; the character sheet for a character illustration; the tone guide containing Chapter 7's seven voices and five-color palette; three to five external reference images in the same tone; and a detailed checklist of required elements. With all five, an artist can construct a first draft efficiently.

Review drafts in four stages: composition and description in the rough; details and characters in line art; tone and palette in color; and print-ready specifications at final finish. The text author reviews every stage. If image and text conflict, the illustration follows the text, because the body text is the SSOT.

The domain of AI illustration

As AI image generation has entered the market, LOREBOOK illustration needs a policy defining what to delegate and where human artists remain necessary.

The recommended policy has five classes. Recommended: concept drafts for tone alignment before commissioning human artists; mood boards and reference cuts; maps, diagrams, and charts, after human review because accuracy matters. Conditional: small atmospheric cuts between paragraphs, only when series tone and character consistency are established; and part openings or chapter headers, with mandatory human-artist finishing. Not recommended or prohibited: character illustrations and covers. Main-character appearances and series consistency are difficult to preserve with AI, while front, back, and spine covers are exclusively human-artist territory because marketing, copyright, and identification are all at stake.

There are six operating rules. Credit every AI-generated illustration with its model, prompt, and post-processor. Discard it if it conflicts with a character sheet or text description. Every illustration included in the main volume receives human illustrator post-processing. When the same character or place appears repeatedly, obtain human consistency review. Do not use models with unclear training-data provenance. Permit AI assistance for concepts, mood, and diagrams, but reserve covers and characters for people.

These rules divide the artist's domain from AI's. Each IP may adjust them, but human exclusivity for covers and major characters remains a passing standard for almost all IPs.

Update cycles — quarters and five years

LOREBOOK operations have two update layers: quarterly updates and new-edition publication.

A quarterly update happens once per quarter and takes roughly two to three days. An automated check of dead links and frontmatter consistency takes one to two hours. Vault synchronization takes half a day to one day for new-term feedback and bulk name replacement. Character-sheet synchronization takes half a day. Short-story consistency work takes half a day to one day to inspect stories published during the quarter and add quotation boxes. Automatic appendix generation takes one to two hours for the glossary and index. Finally, update _progress.md and mark a git tag in one to two hours. This quarterly work sustains LOREBOOK operations.

The large cycle publishes v2.0 after five or ten years. Organizing v1.x operations takes one to two months to collect quarterly updates and analyze patterns. Reconsidering part composition takes one month and reapplies Chapter 4's process to decide the form of v2.0. The v2.0 work itself takes three to six months for directory reorganization and new material, followed by three to five months for its Phases 4–6: consistency verification, appendices, and web/print packaging. v2.0 then publishes with a new cover and ISBN, while v1.x is preserved as archived.

This new-edition cycle takes roughly eight to fourteen months. It is comparable to the first cycle, but lighter because it begins with v1.x material.

The picture after five years

Briefly consider the hypothetical IP “○○” after five years. Its main LOREBOOK starts with v1.0 in 2026: a 450-page B5 hardcover, first printing of 1,000 copies. v1.1 in 2026 makes minor adjustments and reprints 500 copies; v1.2 in 2027 adds short-story quotations and reprints another 500; v2.0 in 2028 expands from twelve to fourteen parts and publishes 1,500 new copies.

Its companion short-story collection grows from thirty stories and 600 pages in 2026, to fifty additional stories and 800 pages in 2027, to one hundred stories and 1,000 pages in 2028. The web edition is available at lorebook.example.com/○○, receives quarterly updates, and reaches roughly 500,000 cumulative page views over five years. The Vault grows from 1,200 entries in the first cycle to 1,800 after five years, and its Obsidian graph grows denser as quarterly feedback continues.

Sister tools grow as well: character sheets reach one hundred people over five years, one hundred short stories accumulate, and multilingual publication adds one English edition in 2027 and one Japanese edition in 2028.

This five-year picture naturally shows why a LOREBOOK is not material made once and finished. If readers imagine how these procedures will work when their IP reaches five years of operation, the importance of the first cycle becomes more tangible.

Small quarterly updates of two to three days and a new-edition cycle every five to ten years form the operational shape of a LOREBOOK. A book on a shelf becomes not static material but living material updated every quarter, then undergoes another large transformation in its next edition five years later as it follows the time of its IP.

Copyright in this work belongs to Kim Dong-eun WhtDrgon and MEJE Works Corp. Without the copyright holders' prior written consent, no part of this work may be reproduced, distributed, transmitted, displayed, performed, broadcast, translated, adapted, or otherwise used.