Every SillyTavern campaign eventually asks the same question: where does the truth live? The narrator says you took 9 damage, your variable says HP is 17, the prose two scenes ago says 21, and your notes say the potion was already drunk. SillyTavern gives you several places to keep game state. It does not referee between them.
This guide maps the four state layers, what each is actually for, and the practices that keep a campaign coherent. It pairs with our SillyTavern D&D setup guide, which builds the full table around these pieces. Details are current as of August 31, 2026.
The four places state can live
Chat-local variables are the right home for numbers. /setvar key=hp 24 stores a value in the chat's own metadata; /addvar key=hp -5 changes it; Quick Replies turn the common updates into buttons. Being chat-local is the feature: the campaign's state stays with the campaign, unlike global variables, which leak across every chat.
World Info (lorebooks) is the right home for reference text: rules summaries, locations, factions, NPC facts. Entries activate on keywords and insert text into the prompt. It is retrieval, not enforcement, and every activated entry spends context, so entries want to be short and specific.
Author's Note is the right home for standing instructions that must stay near the end of the prompt: the narrator's job, the current scene's constraints, the reminder not to invent die results.
Summaries are the right home for history. Long campaigns outgrow context, and a maintained summary of what happened, whether you write it or an extension drafts it, is what keeps session twelve aware of session two. Our five-prompt memory test shows how quickly unsummarized history stops existing.
The two rules that prevent most drift
The model only respects state it can see. Variables are storage, not prompt content. A perfectly maintained HP variable does nothing if narration happens before the model reads it. When numbers matter, put a compact state block into the conversation, and treat "narrator contradicted the ledger" as a prompt-visibility bug before assuming model failure.
Keep one canonical ledger. Pick a single source of truth for mechanical facts, usually the variables plus one visible combat block, and demote everything else to commentary. When prose and ledger disagree, the ledger wins, out loud, in the chat. The alternative is that each unnoticed contradiction quietly becomes canon, which is how a campaign rots.
What this architecture cannot give you
Everything above is storage and discipline. None of it is enforcement. No layer stops HP going below zero, checks that the spell being cast has a slot behind it, knows that advantage does not stack, or prevents the narrator from resurrecting a consumed potion. You are the integration layer, and the maintenance grows with every mechanic and every player you add.
That is a legitimate hobby. It is also a different hobby from playing D&D.
The structural fix, if you want one, is moving state out of the prompt entirely. In TableForge, the game engine runs the game, and the AI DM narrates on top of it: HP, slots, conditions, initiative, and inventory live in a database the model cannot overwrite by being confidently wrong, and the sheet updates from the same state the narrator receives. How the rules engine works covers the architecture, and how a campaign runs shows what the table feels like when nobody has to be the ledger.
Keep the workshop if the workshop is the point. If you built all of this to protect a story you care about, it is worth knowing the protection can be someone else's job.