Why the narrator cannot hand you items out of thin air

When a story says you pick up a lantern, something in the system has to decide whether you now own a lantern. In a pure text generator nothing does. The prose says it, so it is true. In Fabulator the order is reversed: prose follows state, and state changes only through a gate.

This is an instance of a rule that runs through the platform. The model proposes, and the Go engine validates against schemas, bounds and canon before anything is committed. Items are a clear place to see it.

Three separate problems

Inventory trouble in AI-narrated games comes in three forms, and the platform handles each differently.

1. A Player claims an item they do not have ("I pull out my bazooka").
2. A turn claims that a Player picked up an item.
3. A turn claims that a Player lost or gave away an item.

Claimed pickups are matched to real items

When you try to take something, the Intent step does not invent an object. The prompt for that turn includes a list of the campaign's items that are currently unclaimed, taken from real item records. The model is instructed to judge, using the context already in the scene, whether your attempt corresponds to one of those candidates.

Then a second, deterministic check runs. A validation stage sits between Intent and Resolution and compares every claimed pickup with that turn's snapshot of unclaimed items. A claim that does not resolve, because the model hallucinated it or because someone else already holds the item, is dropped silently and counted in a metric. Only verified claims are passed on to Resolution, which is the step that can change state.

The key property is the failure direction. If the platform cannot verify a claim, the claim does not count. The turn still completes. It degrades rather than fails, so a bad guess by the model costs you an item you did not really find, not a broken session.

Losses are checked the same way

The reverse direction gets the same treatment. A claim that you dropped, spent or handed over is compared with your actual inventory for that turn. Anything that does not match an item you really hold is dropped, and a claim cannot remove the same item twice. The model can suggest that your sword was lost in the river. The engine decides whether you had a sword.

Inventory Enforcement: for the item you say you have

The first problem, the invented bazooka, is handled by an optional per-campaign setting called Inventory Enforcement. It is off by default, so Players who prefer unconstrained freedom see no change. When it is on, your current inventory is added to the Intent prompt, and the model is asked to match any item your action depends on against that list by function rather than exact wording. A "bazooka" can resolve to a "rocket launcher" you actually carry.

Even then the model's match is not trusted on its own. A server-side gate checks that the item it claims to have matched really belongs to your current character in this campaign. If that check fails, the clause is treated as a mismatch, and if the check itself cannot complete, it fails closed.

A mismatch does not stop the story. The turn is narrated, with the missing item treated as part of the fiction: your character reaches for something that is not there. The platform shows a quiet notice in the same register as other low-key system notes, not an error banner, since a failed grab is a story event.

Two further pieces keep the guard honest. A prose-time consistency check looks for items the narrator introduced on its own, which the Intent step never proposed, and triggers the existing bounded regeneration if one appears. And a "this should have matched" action lets you dispute a refusal. It retries the match once for that clause, and the dispute is recorded, which is how the platform can tell whether the guard is being too strict.

The toggle lives in the Character Panel's settings on the game screen, and you can flip it mid-campaign. The change applies from the next turn.

What this does and does not claim

It is worth being precise. Inventory Enforcement relies on the model's semantic judgement to match wording to items, with deterministic checks around it. It is not a string-matching lookup, so a near miss is possible in either direction, and that is exactly why the dispute action exists. Pickups and losses are validated whether or not the toggle is on, but the strict "you may only use what you carry" behaviour is the opt-in part. Operators also have a platform-wide switch that can turn the enforcement feature off if it misbehaves.

The practical result is a campaign where scarcity can be meaningful if you want it to be. A lantern you find is a lantern in the records, and a key you lose stays lost.

If you would like to see this in play, start a campaign, open the Character Panel, and try Inventory Enforcement for a session. Ask for something you never picked up and see how the story handles it.