Why the platform validates model output before it becomes game state

The problem being solved

A language model is good at producing plausible text. Plausible is not the same as correct. Left unchecked, a model can describe a dead character walking into a room, invent an item you never picked up, or quietly change a character's personality. In a game that runs for hundreds of turns, small errors like these accumulate into a story that no longer makes sense.

There is a second, less visible risk. If model output were written straight into a database, any mistake or manipulated input would become permanent state. Fabulator's architecture is built around one rule to prevent that: the model proposes, and the game engine decides. This article explains what that means in practice, and where its limits are.

What "proposal" means

Fabulator keeps three kinds of information separate. Canon is the stable facts of a world. State is what is true right now, such as inventory and how a character currently feels. Memory is the record of what happened, which is summarized and allowed to fade over time.

When a turn produces a change, such as an item picked up or a character's mood shifting, the model does not write that change into State. It emits a structured proposal. The engine then checks the proposal before committing it. Those checks include:

• Shape: is the proposal well-formed and readable as the data the engine expects?
• Bounds: is the change within sensible limits? One conversation should not flip an ally into an enemy.
• Consistency with existing facts: does it contradict what is already established, such as bringing back a character who died?
• World rules: does it violate a rule of the setting?
• Character identity: does it try to rewrite a character's core personality? Those changes are meant to happen only as deliberate edits, not as side effects of a scene.

Where possible the checks are deterministic rules rather than another model's opinion. A model is brought in only where rules cannot decide.

The order of operations

The sequence of a turn matters as much as the checks themselves.

First, the engine processes your action and records the intended state changes as a draft, marked as awaiting narration. The live game data is not changed yet. Next, the narrator writes the prose. That text is then checked for safety and for consistency with the world's facts and the character's established traits. Only if it passes does a short transaction apply the draft to the live state and save the final text.

If the prose fails, the draft is discarded and the live data stays as it was. No cleanup is needed, because nothing was changed in the first place. A failed turn is regenerated with the problem noted, up to a limited number of attempts. If it still cannot produce something consistent, the design is to tell you plainly that the narrator struggled, rather than showing you something it knows is wrong.

This arrangement has a practical side benefit. The database is not held open while a model thinks, which can take a while.

Other boundaries in the same spirit

The same instinct, treating powerful components as untrusted guests, shows up elsewhere.

• Your text is untrusted. Player input is handled as data and wrapped so that instructions hidden inside it are not mistaken for instructions to the system. The parser must return your exact original text, and if what it returns does not match, the turn is aborted.
• Custom rulesets run in a sandbox. Rulesets written by Authors are compiled to WebAssembly and have no direct access to the database or the network. They receive the context they need from the platform. Where they need more, such as looking up memories or rolling dice, they call a small set of audited functions that the platform controls. Dice are rolled by the host, within fixed limits, not by the ruleset.
• Keys are handled separately. User-supplied API keys are never stored in plain text, only in an encrypted form.

What this does not do

It is worth being honest about the limits.

Validation checks whether a proposal is well-formed and consistent with the game's records. It does not guarantee that the model understood you the way you meant. For that, the design adds a confirmation step on high-stakes turns and keeps a trace of each turn so that what the system understood can be reviewed afterward.

Memory also summarizes, so a minor detail from long ago can fade. The facts meant to stay fixed, such as world rules, character identity, and tracked state, live in layers that are not subject to that fading.

And no checker is perfect. The aim is that errors are caught before they are saved, that failures are visible rather than silent, and that when something slips through, the player can inspect what the game knows and correct it. The design principle is stated simply: the system may fail, but it may not lie about failing.

Where to see it for yourself

Any campaign includes a view of what the game currently knows about your story, which is the practical place to check these ideas against what you experience. The same Canon, State, and Memory structure is described in the platform's architecture documentation for anyone who wants the detail.