We do not recommend keywords in most cases, and instead encourage enabling Smart Matching

A lorebook is entirely useless if the system doesn't know when to open it. Controlling exactly when your worldbuilding data gets injected into the context is the most technical part of character creation. If you set your triggers poorly, you will flood the context window with irrelevant data, pushing out active chat memory.

This happens because users often treat the keyword fields like search engine tags. They are not search tags. They are strict conditional triggers.

Understanding how to manipulate Primary Keywords, Secondary Keywords, and matching rules is the difference between a bot that knows exactly what is happening and a bot that hallucinates wildly because it loaded the wrong city's data.

---

1) Primary Keywords

The Primary keywords field is the baseline activator for any lorebook entry. This is a comma-separated list of terms.

The logic here is strictly OR. If the system scans the recent chat messages and finds any single one of your primary keywords, the entry activates and the content is queued for injection.

Because a single match triggers the entire entry, you need to pick these words carefully. * Bad Primary Keywords: city, the king, sword, magic * Good Primary Keywords: Eldoria, King Alaric, The Sunblade, chronomancy

If you use generic words like "city" as a primary keyword, that entry will trigger every single time the word "city" is spoken, regardless of which city you are actually in. Keep primary keywords highly specific to the proper nouns or unique concepts defined in the entry.

---

2) Secondary Keywords

Sometimes, you are forced to use a broad primary keyword. Perhaps you have a character simply named "Hunter" or a location called "The Tower."

If your primary keyword is Hunter, the entry will activate every time someone says "I am going to hire a hunter" or "The hunter shot a deer". To stop this from happening, you use Secondary keywords combined with Selective logic. Secondary keywords act as strict filters that must be passed after a primary keyword is found.

You control how these filters behave using the Selective Logic dropdown:

• AND ANY: The entry will only activate if a primary keyword is found AND at least one secondary keyword is also found in the recent messages. (Example: Primary Hunter. Secondary bounty, guild, man, him. The entry triggers if the chat mentions "Hunter" and the word "guild".)
• AND ALL: The entry will only activate if a primary keyword is found AND every single secondary keyword is also present. This is extremely restrictive.
• NOT ANY: The entry will activate if a primary keyword is found, but will instantly cancel if any of the secondary keywords are present. (Example: Primary Hunter. Secondary deer, animal, bow, pelt. The entry triggers for the name "Hunter", but aborts if the chat is clearly about hunting animals.)
• NOT ALL: The entry will activate unless all of the secondary keywords are present at the same time.

By combining broad primary triggers with strict secondary filters, you can isolate exact conversational contexts without generating false positives.

---

3) Match Whole Words vs. Substring Matching

By default, every new entry has the Match whole words toggle enabled.

This means the system uses word boundary matching (\b in regular expressions). It looks for the exact word floating on its own, separated by spaces or punctuation. If your keyword is cat, it will trigger on "the cat sat". It will completely ignore the word "category" or "catch".

When to turn it off: If you disable "Match whole words", the system switches to Substring matching. This means it will look for that specific sequence of letters, even if they are buried inside another word.

You should turn Match Whole Words off if you are dealing with fictional prefixes, compound words, or species names where the root word might change forms. For example, if your keyword is cyber, turning off whole word matching guarantees the entry will trigger for "cybernetic", "cyberware", and "cyberpunk" without you having to list every single variation manually.

---

4) Case Sensitivity

The Case sensitive toggle is disabled by default. The system does not care if you type "eldoria", "ELDORIA", or "Eldoria". It treats them all as matches.

You should only enable Case Sensitivity when your lore relies on a proper noun that perfectly overlaps with a common, everyday word.

A common scenario is a character named "Rose" or "Ash". If Case Sensitivity is off, your lorebook entry for the character Rose will trigger every time someone talks about a red flower, or every time a character "rose from their chair."

By toggling Case sensitive on and setting your primary keyword to exactly Rose, the system will only trigger the entry when the capital 'R' is used, successfully isolating the proper noun from the common verb.