How canon, state and memory work together behind the scenes

The problem this design is solving

If you are evaluating an AI-narrated game, especially for yourself, a child or an organisation, a fair first question is: what actually decides what is true in the story? With a simple chatbot the honest answer is "whatever the model says next." That is fine for a casual chat, but it leaves a lot to chance when a story runs for many sessions.

Fabulator's answer is to split the story's knowledge into three layers, each with different rules about who may change it and how. This post describes those layers in plain terms, and is open about where the design has limits.

Canon: what has been established

Canon is the setting's reference material. Factions, locations, languages, rules of magic, historical events. It is stored as structured entries with specific fields, not as loose paragraphs of text. Each entry records where it came from: written in advance by an Author, invented during play, or deliberately revised.

Canon is built to change slowly. A World Seed (the reusable setting an Author publishes) holds the original canon, and a campaign started from it gets its own copy, so one player's story does not rewrite the setting for everyone else.

Canon also acts as a constraint. If a setting says a kingdom is landlocked, a narrator that writes about its mighty navy is meant to be caught by a consistency check, and the turn regenerated. When the narrator invents something new mid-story, such as a minor noble house, the design captures it, checks it against existing canon for contradictions, and records it as provisional so a player can review it later.

State: what is true right now

State covers the exact, changing facts: your inventory, your stats, where characters are, an NPC's current mood. These live in a database rather than in the narrator's recollection.

The key rule, and the one most worth understanding, is that the model only proposes changes to state. The game engine validates each proposal before anything is committed. Changes to numbers are expressed as adjustments rather than replacement values. Values are clamped to limits. A proposal that uses an item you never held, or revives a character who died, is rejected. This keeps the AI's creativity in the prose, and keeps the bookkeeping in code that behaves the same way every time.

Where a campaign uses a ruleset, the rules run in an isolated WebAssembly sandbox. The ruleset cannot query the database or reach the network by itself. It is handed the context it needs, and its dice rolls are resolved by the host program, not by the ruleset or the model.

Memory: what happened

Memory is the record of events. It has several levels: recent turns kept close to verbatim, a rolling summary of the story so far, and individually stored significant events that can be recalled when they become relevant again. Events judged important, such as a death or a promise, are treated as harder to lose than incidental detail.

Memory is deliberately lossy. Each turn has a limited budget for what is shown to the model, so older material is compressed. That means a minor detail from long ago may fade, and this is the layer most likely to produce an "it forgot" moment. It is also the layer least responsible for anything that must stay exact, because exact facts belong in State or Canon instead.

How the three layers meet in a single turn

When you take a turn, the system gathers relevant canon, the current state, the summary and the most pertinent memories into a prompt for the narrator. Your own input is placed in its own labelled section, separate from system instructions, which is one way the design resists attempts to smuggle instructions in through player text.

The narrator writes the scene and proposes changes. Those proposals are checked. According to the safety specification, the generated prose is also held on the server and run through an output safety check before the turn's state changes are committed or the text is shown to you. The effect is that a turn which fails the check can be discarded without leaving half-applied changes behind. That specification describes what the platform is designed to do, and it separates hard prohibited content from the wider space of fictional darkness that a story may legitimately explore.

What you can see and change

The record is not hidden from the people playing. Players can open a view of what the game currently knows about their story, see which pieces were used on a given turn, and correct them. You can edit a fact, add one, pin one so it is always included, or remove one. Forgotten items are soft-deleted rather than destroyed immediately. Emergent canon waits in a review list where it can be accepted, edited or discarded.

What this does not claim

No design removes every error. The narrator can still write a clumsy line, memory can still compress something you cared about, and checks catch contradictions rather than all poor writing. What the layering gives you is a clear answer to "where does this fact live, and who is allowed to change it?", plus tools to inspect and correct the record when something looks off.

If you want to see this in practice, open any campaign and look at the Context Manager, which shows what the game holds about your story. The World Seeds listed on the Discover page are a way to begin one.