Write a long novel with AI and the lore you set up early keeps blurring. To fix that, I built TypeTak's lore dictionary, the World, and I'm writing up what I weighed and chose along the way, one post at a time.
A Story Bible Template, and What a Wiki Taught Me
A story bible template is a frame that decides in advance which fields to fill in for each kind of entry, such as characters or places. With fixed fields, every entry comes out the same shape no matter who fills it in, and an empty field tells you which detail you haven't decided yet.
In the previous post, I chose to help the AI remember earlier material by having it read files where the lore is organized separately. That meant first deciding what those files should look like: easy for a person to make sense of, and something the AI could fill in on its own. This post is about how I settled on that shape, the story bible template.
Left to itself, AI gives every page a different shape
Ask an AI to “write up this character” and you get something quite convincing. The trouble starts with the second and third characters. One page opens with personality, another with backstory. One character has an age and another doesn't. Once there are ten or so, a writer who wants to check “How old was this character again?” has to read the page from top to bottom.
The AI can still read it. But a story bible the writer can't skim and fix isn't one they can trust. I needed a shape that was easy on the eyes for people and that the AI could fill in on its own.
What I saw in Namuwiki's pages on stories
My lead came from an unexpected place: the pages for novels, comics, and other works on Namuwiki, Korea's biggest community-written wiki.
The works were different, the characters were different, and the people writing the pages were all different, yet the pages looked almost the same. Open a character page and you'll find short facts like name, age, and affiliation laid out in a table at the top, followed by longer writing such as an overview or what the character does in the story. Place pages had their own consistent shape, and so did event pages.
The kind of thing being described was deciding the fields. That's why you know where everything is even on a page for a work you've never seen. And since the short facts sit in a table where you can take them in at a glance, mistakes are easy to spot.
I wondered whether an approach that works in a wiki written by people would also work in a story bible written by AI. So I tested it with the same lore. I put two results side by side: one where the AI wrote freely with no fields, and one where I gave it fields for each kind of thing and had it fill them in. The content was the same, but the version with fields was easier to read.
So around March 2026 I set the direction: wiki-style lore pages that are easy for people to read and that the AI writes on its own. And deciding the fields would be left to the kind of thing being described.
The node type decides the fields
In the World, each lore entry is called a node. One character is a node; one place is a node. Nodes are grouped into node types such as character, place, and faction, and the type decides the fields. I call those fields slots.
Every node of the same type has the same slots. If the character type has an Age slot, every character has an age field, and each node fills in its own value. Add or remove a slot, and the change applies to every node of that type. As with what I saw on Namuwiki, the aim is that the result looks the same no matter who fills it in.
Short facts and long writing, kept apart
I called it a wiki, but it's not just plain pages. Like the table and body text of a Namuwiki character page, the slots come in two kinds.
- Properties: fields for short facts, like age or occupation. They're the table in a character profile.
- Sections: fields for longer, free-form writing, like background or personality. They're the body text.
If short facts are mixed into long writing, you have to read a whole paragraph just to check someone's age. Keep them apart and you can see them at a glance, like a table.
Property values get types, too
I went a step further and split the values that go into properties into types as well. The World now has four: Plain, Number, Select, and Node relation.
- Plain: a value written as short text. In an estate-size field, you'd write a short fact that's neither an option nor a number, like “the fifth-largest estate in the kingdom.”
- Number: a value written as a number. In an age field, you'd write 17 or 30, and you can add a unit or write a range or an approximation.
- Select: a value picked from preset options. In an occupation field, you'd pick one option such as apprentice mage, knight, or merchant.
- Node relation: a value that points to another node. Put another character node in a mentor field, and it links to that node.
I split them this way because it keeps things tidy. When the value type is fixed, the same field always holds the same kind of value. You're less likely to get one character's age written as 17 and another's as “about seventeen.”
Node relation mattered most. In part 1, I chose files because they let you follow what's connected, and node relation properties are exactly those connections. The property name, mentor, tells you what the relationship between the two nodes is, so both the AI and the writer can follow the link to the next piece of lore.
The structure was settled, but filling it in was the problem
With the structure settled, I still couldn't build it right away. This time, cost got in the way.
Lore and plot change often while you write a novel. Each change means the AI has to fill those fields in again, and at the time, AI models that could organize lore well enough were quite expensive. I couldn't make writers pay that every time they wrote.
So for a while I spent my time building ways to cut costs, and development slowed down accordingly.
In the end, I didn't solve this problem; time did. Better models came out and prices dropped until I could get the quality I wanted at a price that made sense. Some of the cost-cutting machinery I'd built was no longer needed, so I took it out.
The next post covers the problem that came up once AI started filling in this template: upkeep. In novels where the same character goes by a surname, a given name, and a nickname, I'll write about what I did to keep lore from being created twice.
I decided TypeTak would store lore in a wiki where the node type decides the fields. Short facts go in properties and long writing in sections, and property values are split into Plain, Number, Select, and Node relation.
Frequently asked questions
Why do you need a story bible template?
Without fixed fields, every character's page takes a different shape, and you have to read from the top just to check one age. Give each kind of entry the same fields and the result looks the same no matter who fills it in, while empty fields show which details you haven't decided yet.
How should I decide the fields in a story bible?
Decide them per kind of entry rather than per entry. Characters share one set of fields, places another. As on a Namuwiki character page, splitting short facts into a table and longer stories into body text makes everything easy to see at a glance.
How do I separate short facts from long descriptions in a story bible?
Put short facts like age or occupation in fields, like a table, and longer descriptions like background or personality in body text, and everything is easy to see at a glance. In TypeTak's World, the first kind of field is called a property and the second a section.
What's the benefit of splitting story bible values into text, numbers, options, and links to other entries?
The same field always holds the same kind of value, which keeps things tidy. Values that point to another entry become links in particular, so both people and AI can follow connected lore.
Features used in this lesson
Step-by-step details are in the guide.
I'm building TypeTak. In this series, I'm recording the problems I ran into while designing the World and the answers I chose.