Kobold AI Lorebook Guide: How to Write Entries That Trigger Reliably

A lorebook is most useful when it retrieves one small piece of world knowledge at the moment a scene needs it. Reliable entries use specific trigger terms, self-contained facts, and a clear priority. They do not try to store the whole story in one block.

Quick answer: create one entry per subject, add the names and phrases a user will actually type, write the entry so it makes sense on its own, and test it in ordinary dialogue. If an entry fires too often, narrow its keys. If it never appears, add realistic aliases or check the scan settings.

What a lorebook does in AI roleplay

Lorebooks are often called World Info, world books, or knowledge books. They hold information about locations, factions, characters, objects, customs, rules, and history. A compatible frontend scans recent text for a keyword or another relevance signal and inserts the matching entry into the prompt.

That makes a lorebook different from three other layers:

| Layer | Best use | | --- | --- | | Character definition | Permanent identity, motivation, voice, and boundaries | | Active context | The current scene and recent conversation | | Memory or summary | Durable events and relationship changes | | Lorebook | Reusable world facts that matter only in relevant scenes |

The SillyTavern World Info documentation describes World Info as a dynamic dictionary that can insert entries when associated keys appear. Exact controls vary by frontend and version, but the design principle is portable: retrieve only the knowledge required now.

The anatomy of a reliable lorebook entry

A practical entry has four parts.

1. A single subject

Keep each entry focused on one location, person, faction, item, or rule. “Glass Harbor” is a subject. “Everything about the kingdom” is a database dump.

Focused entries are easier to trigger and easier to revise. They also reduce the chance that unrelated facts will compete with the current scene.

2. Realistic trigger keys

Keys should match phrases likely to appear in conversation. For an entry about Captain Elara Voss, useful keys might include:

Elara Voss
Captain Voss
Elara
harbor captain

Avoid a key such as captain if the story contains many captains. Broad keys activate in unrelated scenes and waste context.

3. Self-contained content

The retrieved text should make sense without the lorebook editor around it. Use names instead of unexplained pronouns and write direct facts rather than commentary.

Weak:

She does not trust them after what happened there.

Stronger:

Captain Elara Voss distrusts the Ash Guild because its agents sabotaged her ship at Glass Harbor. She remains formally polite but refuses to share navigation records with guild members.

The stronger version tells the model who, why, and how the fact affects behavior.

4. A defined scope

Include only facts that should influence a response when the entry activates. A location entry may need its atmosphere, governing rule, and current conflict. It probably does not need the full biography of every resident.

A copy-ready lorebook template

Use this compact structure as a starting point:

Entry name: Glass Harbor
Primary keys: Glass Harbor, the harbor city
Secondary keys: lighthouse district, harbor council

Content:
Glass Harbor is a foggy independent port governed by a five-member council.
Unlicensed magic is prohibited inside the harbor walls.
The lighthouse district is controlled by the Ash Guild after sunset.
Visitors must register enchanted cargo at the eastern gate.

Purpose:
Retrieve this entry when the scene enters or discusses Glass Harbor.

The Purpose line is an editor note; whether it is sent to the model depends on the tool. Keep operational notes separate from the lore text when possible.

How to choose trigger keys

Build keys around the words people will actually use, not the categories you use to organize your notes.

Start with:

Start with the exact proper name.
Add common shortened names.
Include titles or aliases used in dialogue.
Add a distinctive location or object strongly associated with the subject.

Then test for two errors:

False negative: the story clearly refers to the subject, but the entry does not activate.
False positive: the entry activates when the subject is not actually relevant.

Fix false negatives by adding realistic variants. Fix false positives by removing generic words or requiring a more specific combination when the frontend supports it.

Why entries fail to trigger

The key never appears in scanned text

If users say “the old port” but the only key is Glass Harbor, the entry may never match. Add the phrase people naturally use.

Scan depth is too shallow

Some frontends inspect only a limited portion of recent conversation. A relevant term may have appeared several messages ago. Review the frontend's scan settings before rewriting the entire entry.

The entry depends on vague semantic similarity

Keyword retrieval is predictable; semantic retrieval can be flexible but less transparent. If an important rule must appear, give it a clear key rather than assuming the system will infer every paraphrase.

Too many entries compete for prompt space

An entry can activate correctly and still have little influence when the prompt is crowded. Split large entries, reduce repeated facts, and reserve constant insertion for genuinely universal rules.

The retrieved fact conflicts with another source

If the character card says magic is legal while a lore entry says it is banned, the response may become inconsistent. Decide which source is authoritative and remove stale duplicates.

Why entries trigger too often

The usual cause is a generic key: city, school, mother, king, or magic. Replace it with a proper name or a distinctive phrase.

Another cause is bundling multiple subjects into one entry. If an entry covers five kingdoms, mentioning any one kingdom may inject facts about all five. Split it into smaller units.

A five-minute reliability test

You do not need a long roleplay to check basic retrieval.

Start a clean test chat with the intended character.
Mention the primary key naturally and ask a question whose answer exists only in the entry.
Repeat the test with an alias or shortened name.
Discuss an unrelated subject that contains a similar generic word.
Inspect the prompt or activation indicator if the frontend exposes one.
Revise one variable at a time.

Record whether the right entry appeared, whether unrelated entries appeared, and whether the answer followed the retrieved facts. This separates a retrieval failure from a generation failure.

Portable worldbuilding and World Cards

Lore formats differ across tools. Field names, activation rules, ordering, and supported metadata may not map perfectly when moving a world between applications.

The public CrushOnAI World Card repository documents a structured, versioned format for portable worldbuilding data. Its v0.2.0 release includes conversion reporting so mapped, approximated, and skipped fields can be reviewed instead of silently treated as equivalent.

For users who prefer to create characters and roleplay without maintaining a separate frontend, model endpoint, and retrieval configuration, an integrated AI roleplay platform can reduce setup work. A Kobold-based workflow offers deeper control; an integrated service offers a shorter path from character creation to conversation. Neither architecture removes the need for concise, non-conflicting world information.

Lorebook checklist

Before publishing or importing an entry, ask:

Does it cover one clear subject?
Do the keys appear in normal conversation?
Are any keys so broad that they create false positives?
Does the content make sense by itself?
Does it conflict with the character card, summary, or another entry?
Is every sentence useful when the entry activates?
Have the main name, alias, and unrelated-word cases been tested?

Frequently asked questions

How long should a lorebook entry be?

There is no universal limit. Use the shortest entry that preserves the facts needed for consistent behavior. Split an entry when parts of it have different triggers or purposes.

Should personality go in a lorebook?

Core personality usually belongs in the character definition. Put situational knowledge in the lorebook—for example, how the character behaves inside a particular faction's territory.

Are more keywords always better?

No. More keys improve recall only when they refer specifically to the subject. Generic keys increase irrelevant activation.

Can a lorebook guarantee factual consistency?

No. It improves the information available to the model, but generation remains probabilistic. Contradictory prompts, crowded context, and model limitations can still produce mistakes.

Can every lorebook be imported without changes?

No. Tools support different fields and retrieval behavior. Review conversion diagnostics and manually verify important entries after an import.

Reliable lorebooks are built through routing and testing: one subject, realistic keys, self-contained facts, and observable activation. That discipline matters more than the total number of entries.