Why Insertion Order is not a priority ranking
Here is the definition, verbatim:
"Numeric value. Defines a priority of the entry if multiple were activated at once. Entries with larger order numbers will be inserted closer to the end of the context as they will have more impact on the output. For example, an entry with Order number 100 will appear in the context before an entry with Order number 250."
Larger number, later position, more impact. An entry at 250 lands after one at 100, and lands closer to where the model is about to write. If you numbered your world's core rule as 1 and a throwaway tavern as 400, the tavern is the thing sitting next to the model's attention.
That is job one. Job two is in a completely different section of the documentation, under Activation Settings, and it is the one that bites in long sessions:
"If the budget is exhausted, then no more entries are activated even if the keys are present in the prompt."
"Constant entries will be inserted first. Then entries with larger order numbers."
So the same number also decides who survives. Once the World Info budget runs out, activation stops — the keyword matched, the entry was eligible, and nothing was inserted. What got in first were the constant entries, then everything else from the top of the number range down. Your entry at 1 is last in line for space and last in line for attention.
One more line from the same section changes how you should think about recursive lore: "Entries inserted by directly mentioning their keys have higher priority than those that were mentioned in other entries' contents." Entries pulled in by recursion queue behind entries triggered by the actual conversation.
And a detail that explains a great deal of silent failure. The Entry Title is documented as "a text field for your convenience to label your entries, which is not utilized by the AI or any of the trigger logics." The pro tips say it more broadly: "activation keywords, titles, and other information that is not in the Content field is not inserted into context, so each World Info entry should have a comprehensive, standalone description." If your titles carry meaning, nothing has ever read them.
This is the general shape of the problem described in why agents ignore your instruction files — the file is present, the file is correct, and the file is not reaching the model.
What people try instead
Renumbering everything to 1. If everything is maximally important, the tie-break becomes arbitrary, and the budget still cuts the list off somewhere. You have not prioritised; you have removed your ability to.
Making every key entry constant. The blue-circle strategy means an entry "does not need any keywords, and will trigger regardless of content." It works, and it spends your entire budget before any conditional entry gets considered — constant entries are documented as being inserted first. Three or four is a plan. Twenty is a budget with no room left in it.
Writing shorter entries and stopping there. Useful, and it treats the wrong variable. Length affects how many entries fit; order affects which ones get the space and where they land. The limits of the shorten-everything approach are the same ones covered in how much memory you should give an AI agent.
Raising the budget until it stops hurting. This converts a lore problem into a context problem. A larger World Info allowance means less room for chat history, which is the trade described in why long context isn't memory — more room in the prompt is not more memory, just a different allocation of the same shelf.
Switching entries to vector matching to avoid the whole question. SillyTavern is candid about what that costs: "Since the retrieval quality depends entirely on the outputs of the embedding model, it's impossible to predict exactly what entries will be inserted. If you want deterministic and predictable results, stick to keyword matching." Vector matching also only replaces the keyword check — budget, probability, filters and inclusion groups all still apply. The broader version of that trade-off, similarity search standing in for a decision you could have written down, is covered in why RAG isn't memory.
The Fix: Number by how late you want it read, then check what the budget actually reaches
Step 1: Re-number by proximity, in bands
Stop thinking "rank" and start thinking "how close to the model's next sentence should this sit."
Give yourself three or four bands with wide gaps, so you can insert later without renumbering. Low numbers for background that should be established early — the world's physics, the era, the broad setting. Middle numbers for standing facts about places and factions. High numbers for the things that should be the last thing read before the model writes: active plot constraints, hard rules about what a character will never do, the current scene's stakes.
Wide gaps matter more than exact values. Bands of 100 leave room for a new entry to slot between two existing ones without a global renumber.
Then check your Lore Insertion Strategy, because it changes what the numbers are being compared against. The default is Sorted Evenly, which SillyTavern describes as sorting "all entries according to their Insertion Order as if they were a part of one big file, ignoring the source." The alternatives, Character Lore First and Global Lore First, group by origin before applying the order within each group. If your character lorebook and your global lorebook use different numbering conventions, Sorted Evenly will interleave them in ways neither author intended.
Note also that chat-bound and persona-bound lore are inserted ahead of that comparison entirely, in the documented order: chat lore, then persona lore, then character or global lore by the chosen strategy.
Step 2: Separate position from order, because they are different controls
Insertion Order decides sequence among activated entries. Insertion Position decides which region of the prompt an entry lands in, and SillyTavern annotates the impact of each.
Before Char Defs is documented as having "a moderate impact on the conversation." After Char Defs has "a greater impact." The example-message positions are parsed as example dialogue blocks and follow the example-messages rules, which means they can be pushed out as context fills. The Author's Note positions carry a trap the docs flag with an exclamation mark: "If your Author's Note is disabled (Insertion Frequency = 0), World Info entries in A/N positions will be ignored!" An entry can be perfectly written, correctly keyed, high in the order, and silently discarded because a completely different feature is switched off.
The depth position is the sharpest instrument here — an entry inserted at a specific depth in the chat, with depth zero being the bottom of the prompt, and with a choice of system, user or assistant role. That is how you put a hard constraint immediately before generation without making it constant.
If you want full control, the Outlet position removes automatic injection altogether and stores the content under a named token you place yourself. The documentation lists real caveats: outlet names are case-sensitive, leading or trailing spaces in a name are ignored when calling the macro so padded names will not match, nesting is unsupported, and character card fields cannot expand outlets because they are parsed early.
Step 3: Verify by watching what gets dropped, not by reading the panel
A correct entry and an inserted entry are different things, and the panel only shows you the first.
Run a scene that should trigger several entries at once and look at what actually arrived. If a high-order entry appears and a low-order one does not, you have found your budget ceiling, and you now know the ordering is doing its job. If nothing conditional arrives at all, count your constant entries first.
Test inclusion groups deliberately, because their behaviour surprises people: "If multiple entries having the same group label were activated, only one will be inserted into the prompt," selected by Group Weight unless you enable Prioritize Inclusion, in which case "the one with the highest 'Order' value will be selected." That is the third job your order number can be given, and it is opt-in.
Also check anything on a timed effect before blaming the order. Sticky keeps an entry active for a set number of messages and ignores probability checks while it lasts; cooldown blocks reactivation for a set number of messages; delay prevents activation until the chat is long enough. And check Scan Depth, since at zero "only recursed entries and Author's Note are evaluated" — no amount of correct numbering helps an entry whose keyword is never scanned for.
This is the same discipline as the one in auditing what your AI remembers: verify by observing output, not by reading configuration.
Setting this up in MemoryLake
Two things come out of this exercise, and only one of them belongs in a lorebook. The entries themselves are SillyTavern's job and it does it well. The reasoning — why this rule outranks that one, which constraint must never be dropped, what you learned when an entry silently stopped firing — has nowhere to live inside a numeric field.
MemoryLake holds that second layer, outside any one frontend. You write it yourself, in your own words, and it stays readable when you change tools, rebuild a lorebook, or hand a world to someone else.
Step 1: Create an API key
Sign in, open your workspace settings, and generate an API key. This is the credential your assistants use to read the same layer, so create it once and keep it reachable from each machine you write on.
Step 2: Upload your first memories
Move the reasoning out of your entry bodies and titles: why each band exists, which entries are load-bearing, which ones you demoted and why, which conditions you discovered the hard way. The lorebook keeps the lore; this layer keeps the decisions about it.
Step 3: Connect your AI & agents
Connect whatever you write with. The same decisions arrive in each, which matters because a lorebook does not travel to the next tool and the thinking behind it should.
What this changes in practice
The first difference shows up in long scenes. Once the high-value entries hold the high numbers, budget exhaustion starts trimming from the least important end instead of at random, and the entries that do arrive land where they have the most influence.
The second is that silent failure becomes diagnosable. There are at least four documented reasons an entry can be correct and absent — budget exhausted, Author's Note disabled, inclusion group lost the roll, scan depth too shallow — and knowing the list turns a mystery into a checklist.
The third is that your titles stop lying to you. Once you accept that the title is for you alone, every entry gets a self-contained body, which is what the documentation asks for anyway when it says each entry should have a comprehensive, standalone description.
The fourth is portability. A world expressed as conditions in words survives moving platforms; a world expressed as insertion numbers does not. That is the gap that makes migrations painful, as in migrating Character AI Lorebooks to ChatGPT, where OpenAI's documented personalization surfaces do not describe an ordering control to receive them.
Best practices for World Info ordering
Number by position, not by rank. Higher means later, and later means more influence. Write that on a sticky note if you have to.
Leave gaps. Bands of 100 let you insert without renumbering the world.
Budget constant entries deliberately. They are inserted first and they spend first. Keep the blue-circle list short enough to name from memory.
Put hard constraints at depth, not at the top. The depth position places content close to generation without making it permanent.
Check the Author's Note before using its positions. Entries assigned to Author's Note positions are ignored when the Author's Note is disabled.
Give every entry a standalone body. Titles and keywords are not inserted into context, so an entry that only makes sense with its title is an entry that does not make sense.
Re-test after any budget or strategy change. Changing the Lore Insertion Strategy changes what your numbers are compared against, and changing the budget changes where the cut falls. Both are silent.
Conclusion
SillyTavern gave you a genuinely powerful prompt-management system and documented it properly, including the parts that are counter-intuitive. Insertion Order is not a ranking; it is a position, and higher numbers land later and matter more. The same number decides who survives when the budget runs out, and can be made to decide inclusion-group winners as well.
Renumber by proximity in wide bands, use position and depth for the things that must land late, and verify by watching what arrives rather than by reading the panel. Then take the reasoning out of the entry bodies, because a numeric field is a poor place to record why your world works the way it does — and because the next tool you use will have its own controls, its own budget, and no way to read this lorebook at all.