What persistent state means in an AI roleplaying game

If you have played a story generated by a language model, you may have had this experience: your character picks up a lantern in one scene, and ten scenes later the lantern is gone, or has become a torch, or was never mentioned. The model did not decide to lose it. It simply had nothing holding it in place.

Persistent state is the answer to that problem. This post explains what the term means, how it differs from memory and from world rules, and why an AI roleplaying game needs all three.

Persistent state in one sentence

Persistent state is the set of facts about the game world that are stored as structured data, outside the model, and updated only in controlled ways. It answers one question: what is true right now?

Examples include how much health a character has, what they are carrying, where they are standing, which door is locked, and whether a given character is alive. These are the things a story cannot afford to get wrong, and they are the things a model is least reliable at tracking on its own.

Why a model cannot just remember

A language model works from the text it is shown on each request. It has no private notebook. Anything it knows about your campaign is either in that text or it is not.

Recent turns can be included, but the window is finite. Long campaigns outgrow it. The usual workaround is summarizing older material, which keeps the shape of the story and loses detail. A summary can say "you found a lantern" and drop the fact that it holds half a flask of oil.

Persistent state works differently. The lantern is a record in a database, with a count and a location, and it is put in front of the model whenever it is relevant. The model does not have to remember it. The system does.

State, memory and canon are different things

These three get confused, so it helps to separate them.

• Canon is the fixed background of the world: its rules, its factions, how its magic works. It is established before play and changes only through deliberate edits.
• State is the ground truth of the present: inventory, conditions, positions. It changes as the story moves, through validated updates.
• Memory is the record of what happened: an append-only journal of events, summaries and retrievable details. It fades in priority over time.

An example separates them cleanly. "Magic in this city costs the caster a day of exhaustion" is canon. "Your character is exhausted right now" is state. "You used magic during the flood and the harbourmaster saw it" is memory.

Fabulator keeps these as separate layers on purpose. Each has a different rate of change and a different way of being stored, so each can be handled in the way that suits it.

How state gets changed

The most important rule about persistent state is who is allowed to change it.

In Fabulator, the language model only proposes changes. The engine then validates a proposal against schemas, bounds and canon before anything is committed. A model suggesting that a character has a thousand gold pieces does not make it so. Values are clamped to their limits, and a proposal that violates the rules is rejected.

This is what makes state trustworthy. If the model could write directly to the record of the world, one confident mistake would become a permanent fact. Because it can only propose, a mistake gets caught at the boundary instead.

Some state is mechanical and exact, such as a count of items. Some is softer, such as a mood or a relationship. Both are stored, but the exact kind is owned by the system and changed by rules, while the softer kind is proposed by the model and checked before it is accepted.

What this looks like when you play

Persistent state is mostly invisible when it works. You notice it by what does not happen. Your inventory is the same after a long conversation. An NPC who was dead stays dead. A door you unlocked is still unlocked when you return.

It also shapes how a campaign can be paused and resumed. State is stored, so picking up a campaign after a long gap puts you back where you were with what you had, rather than asking the model to reconstruct it.

State is also what lets rules apply fairly. When a mechanical check needs your character's current numbers, it reads them from the record. It does not ask the narrator to guess.

What persistent state does not do

It is worth being clear about the limits. State stores facts, not meaning. It will tell the narrator your character is carrying a sealed letter, but not why the letter matters to the plot. That is the job of memory and canon, which is why the layers work together.

Nor does it make the model a perfect narrator. It reduces one specific class of error, forgetting and inventing facts, and leaves the prose to do what prose does.

See it for yourself

The easiest way to understand persistent state is to feel its absence and then its presence. Start a campaign from a World Seed in Discover, pick up something, travel somewhere, and come back a few sessions later. If you find the same thing where you left it, that is the whole idea working.