What happens when a rule proposal fails validation
The principle: the AI proposes, the engine commits
One rule shapes a great deal of how Fabulator is built: the language model never has write authority over your campaign. It can suggest that your character loses a few hit points, that an NPC grows more suspicious, or that a new character walks into the scene. Those are proposals. A separate engine checks each one against the world's schemas, bounds and canon before anything is saved.
That raises an obvious question for anyone evaluating the platform. What actually happens when a proposal is wrong? This article walks through the failure paths as described in Fabulator's design documents, in plain terms.
What gets checked
When the system interprets what you typed, its structured output passes through four kinds of gate.
- Schema: the output must be well formed. A proposal that cannot be parsed is not acted on.
- Bounds: changes must stay within limits. An ally cannot turn into an enemy in a single turn.
- Canon: the proposal cannot break established facts. The dead cannot be resurrected.
- Character: characters cannot have their core personality rewritten, or know things they have no way of knowing.
The design is explicit about what these gates are not. They check that a proposal is well formed and consistent with the world. They do not claim to verify that the system understood you correctly. That second problem is handled separately, through confirmation for high-stakes turns and through reviewable records of each turn.
When a proposal fails
A rejected proposal is not silently patched up. For freeform input, the system regenerates the proposal and tells the model which rules were violated. This is capped at two attempts. If it still fails, you are asked to rephrase your action. Your input is kept, so you are not forced to retype it.
If your action involves several parts, such as attacking a guard while shouting to allies, the parts run under an all-or-nothing boundary. If any part fails validation, the whole transaction is rolled back, you are notified, and your input is preserved for editing. The aim is to avoid half-applied turns, where one part of the action happened and the other did not.
Rules-based worlds: the referee says no
In campaigns that use a ruleset, a deterministic code module acts as the referee. It checks a request against the current state: is the character alive, do they have the action points, do they own the weapon. If the request is invalid, it returns a clear mechanical error, stops, and makes no state changes. A spell cast with no mana available, for example, produces a validation failure rather than narration that pretends it worked.
Rulesets run inside an isolated sandbox. The design specifies no direct network access and no host filesystem access for them, and they can only return structured results that the host then validates. Rule execution and database updates are meant to be atomic, so if the ruleset or an extension fails, the transaction rolls back and the database is left unaltered.
Button actions get a similar check. If you click an action that was available a moment ago but is no longer legal, such as a target that has since left the scene, the server rejects it with a clear message rather than resolving it against outdated information.
When the prose is the problem
Validation also applies after the story is written. The narration is checked for contradictions with the resolved mechanics, with canon and with character. If it contradicts them, the narrator is asked to try again, with the violation noted. This happens up to three times. After that, the system does not loop quietly. The design says the turn is surfaced to you as degraded, with options to retry, edit your intent, or accept it with a warning.
Importantly, state changes are saved as a draft first and only applied to the live game state once the prose passes its checks. If the prose fails, the draft is discarded and live state stays untouched, so there is nothing to undo.
The commitment behind it
The documents state a plain principle: the system may fail, but it may not lie about failing. Fallbacks, delays and retries are meant to be visible to the player instead of hidden. Each turn is also designed to produce a trace recording what the system understood, resolved and wrote, so that a question like "why did this NPC forget that?" can be answered from the record.
What this does and does not promise
None of this means the system will never make a mistake. A parser can misread you, and a narrator can still produce a clumsy line. The point of the validation layers is narrower: a mistake should be caught before it changes your campaign, and when it cannot be fixed automatically, you should be told.
Learn more
If you want to see this in action, start a campaign and try an action the world should refuse, such as using something your character does not have. The engine's response to that is the feature working as designed. Published World Seeds on the Discover page are a good place to pick a setting to test it in.