Why your lorebook isn't triggering (and how to debug it)

You wrote thirty entries. You set the keywords. You imported the card to SillyTavern, opened a chat, and… nothing fires. The model talks past the entire lore. This is painfully common, and the cause is almost never "the card is broken" — it's one of five concrete settings interacting with how the runtime scans your conversation.

1. scan_depth is smaller than you think

SillyTavern's default scan_depth is the last 4 messages. Not your entire history, not your character description — only what you and the assistant just said. If you established "the dragon Skarn" ten turns ago and haven't mentioned him since, that entry will never re-trigger. Bump scan_depth to 8 or 12 if you have long pauses between key mentions, or mark anchor entries as constant.

2. Priority ties are an invisible coin flip

Two entries with the same priority and overlapping keys are picked arbitrarily. If you have a generic "city of Aelan" entry at priority 100 and a more specific "throne room of Aelan" entry also at 100, the throne room loses about half the time. Make specifics higher priority than the general; they should win deterministically.

3. recursive_scanning is off

With recursive scanning disabled, entries only fire on the conversation window — content from other activated entries doesn't feed back into the scan. That breaks chained lore: entry A mentions "the council," entry B's keyword is council, and you expected B to fire because A activated. It won't. Turn recursive scanning on, but cap your depth: cycles between entries can balloon context cost every turn.

4. secondary_keys are AND, not OR

If your entry has primary keys: ["king"]and secondary secondary_keys: ["crown"]with selective: true, both must appear in the scan window in many runtimes. Writing "the king arrives" alone won't fire it without "crown" nearby. Either drop secondary keys or use them deliberately for disambiguation.

5. V3 decorators with no host support

V3 lets entries declare @@constant, @@activate and other decorators inside content. Chub and stock SillyTavern recognize them; some custom forks don't. If a card was written assuming a decorator and the host ignores it, the entry silently misbehaves — you'll see neither error nor the expected output.

Diagnose against a real conversation

Reading config is one thing; watching which entries actually fire on the messages you're sending is another. The lorebook debugger takes a PNG or JSON card plus a snippet of your conversation and reports, per entry: whether it fired, the reason (primary key, secondary key, recursion, depth exceeded, constant, disabled), the matched keyword, and the token cost. No signup; the card never leaves your browser to be parsed.

For a static audit of the whole card (lint findings, lossy fields, V3 → V2 compat), run it through /audit instead — same rule engine the editor uses, no upload.