What Is a Lorebook? An AI Lorebook Guide With Examples

Test your own entries in Lorebook Lab

Open Lorebook Lab to edit the harbor example or import a JSON Lorebook. Try a message, inspect the matched keyword and source message, and see which entries fit Teasa’s selection limits. Save a revision before changing a keyword to compare the same tests before and after. You can share a copy, then use the entries in a private Blueprint connected to a Teasa Plot. The lab tests selection; use Play-test in the Plot editor to inspect actual AI responses. For Teasa's Blueprint rules in brief, from entry limits to keyword matching and connecting a Blueprint to a Story, see how lorebooks work on Teasa.

A lorebook example: three entries for one world

The following worked lorebook example is an authored exercise, not a production trace. The player is a traveler with a sealed letter. Iona captains the last ferry, Ren wants to inspect the letter, and Sol is repairing the engine.

A third entry can describe the ferry engine, with specific triggers such as “ferry engine” and “fuel line”: “Sol is replacing a damaged fuel line. The engine cannot be started safely until the repair is complete.” Keep the engine condition out of the entry about the warning bell so you can revise them independently.

Iona recognizing her sister's handwriting is a private character fact. The traveler choosing to reveal the letter is a conversation event. Neither should silently become something every person in every version of the world knows.

Repair a trigger that catches everything

Too broad: an entry about the Drowned Bell tavern triggered by “bell.” A message about the harbor warning bell could load unrelated tavern lore.

More specific: use “Drowned Bell” and “Drowned Bell tavern” for the tavern. Keep “harbor warning bell” for the crossing rule, or keep that short rule always on if it is essential to the whole opening.

Do the same check in the language of your story. If players write a translated place name but the entry only lists the original, its aliases may need updating. Avoid assuming the matcher understands every translation, spelling or inflection.

Test four inputs before expanding the book

These are test intentions, not claimed results from a live matcher. When activation diagnostics are available, compare them with the transcript. Otherwise, treat the reply as behavioral evidence only.

If the tavern leaks into the first response, inspect overlapping triggers and recent context. If the engine is ready too early, check for contradictory statements elsewhere before lengthening its entry. A failure might involve selection, conflicting facts, or how the model used the supplied text.

Give each fact one home

This separation also makes editing easier. If the bell's rule changes, update its authoritative entry instead of adding a second note saying the first is wrong. After publishing, check how your platform versions and applies changes before expecting an existing conversation to use a new draft.

A compact entry template

Topic: Drowned Bell tavern
Activation: Keywords
Triggers: Drowned Bell; Drowned Bell tavern
Facts: Dockside tavern beside the western pier. Passengers wait here
       when the crossing closes. The keeper trades information for repairs.
Knowledge boundary: This entry does not reveal who wrote the player's letter.

“Knowledge boundary” here is a writing instruction within your material, not a promise of a separate UI control or guaranteed secrecy. Keep each entry focused enough to understand at a glance. Use the platform's actual activation fields for triggers and mode.

Diagnose the cause before adding more text

1. Is the book attached to the story being tested? Check the relevant version as well as the library draft.
2. Could the entry match? Compare exact names and aliases with what the conversation actually says.
3. Was there room? Large always-on material competes with other instructions and recent conversation.
4. Are facts consistent? Look for an older engine condition, duplicate place entry or contradictory character profile.
5. Did the model use the fact correctly? Retrieval and faithful generation are separate things.

Start with these few entries, run the four inputs, and record what happens. Add another subject only when a scene needs it. For the cast behind this example, use the character-card workshop; for actual generated dialogue, read the roleplay walkthrough.

To see world rules carry a whole story, play one with a strong setting. Each opens in your browser:

• The One Who Calls You Weak: the afterlife runs a death game with reincarnation as the prize, and thirty players are left.
• The Oni and the Human: an oni caught in a human village by two Demon Suppression Squad hunters.
• Daily Life of the Dungeon Lords: five Demon Lords and a 10,000-year-old dungeon, between adventurers' attacks.

Test a relevant fact, a near match and a secret

This is an authored test protocol, not a report that a particular retrieval engine passed. Start with one fact: “The ferry stops sailing when the third storm bell rings.” Add a separate private character fact: “Only Iona recognizes the letter’s sender.” Keep the opening unchanged.

Run each input three times, then change only the ferry entry’s wording to make the trigger precise and repeat. Keep all 18 replies and score rule preservation, false activation and knowledge leakage separately. A lower failure count on one probe can hide a regression on another.

Inspect entry-selection diagnostics if your tool exposes them. Otherwise record only what the response did: a correct sentence does not prove the intended entry was retrieved, and an incorrect one does not identify whether retrieval or generation failed. These controls vary between apps. Teasa’s public walkthrough demonstrates responses; it is not a retrieval trace.

Use your own fictional facts and save the draft/version, language and date with the results. Do not put real credentials or confidential information in a “secret” for this exercise.

FAQ

What is a lorebook?

A lorebook is a collection of short entries about a story's world and characters, most of them with trigger keywords. When a message mentions a keyword, the AI receives that entry, so it knows the harbor's storm rule or a tavern's location only when the scene needs it. SillyTavern calls it world info or a worldbook; Teasa connects Lorebook entries to a Story through a Blueprint.

Is a Lorebook permanent memory?

No. It is creator-maintained background material. Whether an entry is supplied depends on activation, configuration and budgets, and the model can still misuse a supplied fact.

Should every important entry be always on?

Reserve always-on space for a small set of rules the scene consistently needs. Importance alone does not mean a long history belongs in every generation.

Can I tell whether an entry activated from the reply?

Not reliably. The model might know a fact from the conversation, omit a supplied fact, or invent a similar detail. Use activation diagnostics where the platform provides them.

Should I save everything that happened into the shared worldbook?

No. Keep playthrough-specific events in the conversation's own history or appropriately scoped memory. Otherwise, another conversation may inherit an event that never happened there.