Narrative output
Scene description, dialogue from world characters, immediate sensory information, ordinary role-play, explanations, and the player-visible result of a turn.
AUTHORITATIVE SIMULATION
Prose can describe. Only the system can commit.
Fortune & Gallows uses a constrained narrative layer inside a server-authoritative state model. The narrative layer can interpret intent and propose supported changes; persistent reality changes only after validation and commit.
Two kinds of output
Persistent operations
Structured changes that alter durable campaign state and therefore require explicit validation against current canonical context.
This separation lets the game remain expressive without granting generated prose permission to silently rewrite the save.
Examples of currently supported normal-turn operations
The exact operation set can evolve, but the audited runtime currently supports a bounded vocabulary for ordinary turns rather than arbitrary state mutation.
| Operation family | What it represents | Typical validation |
|---|---|---|
| Movement | Move to a supplied destination in the current settlement or scene context. | Destination must actually be available and cannot simply invent a location. |
| Time passage | Advance the campaign clock by a bounded amount. | Minutes must fall within supported limits. |
| Job status | Change the status of an existing supported job record. | The referenced job must exist and the new status must be valid. |
| Inventory removal | Consume or drop an owned item instance. | The item must exist, be owned, and use a valid quantity. |
| Relationship change | Apply a small relationship adjustment with a present NPC. | The NPC must be physically present and the change is tightly bounded. |
| Knowledge note | Record a concrete fact the player explicitly tells a present NPC. | The NPC must be present; the system does not infer imaginary conversations. |
| Rough rest | Resolve the currently supported rough outdoor sleep path. | Handled as a dedicated supported rest action. |
Specialized mechanics can use dedicated server paths outside this ordinary operation list, such as supported naval resolution or specific transactional flows.
What the runtime refuses to fake
If a requested action reaches a persistent mechanic that the current authoritative runtime does not support, the narrator is instructed to stop at a supported immediate result instead of pretending the full outcome happened.
No invented wealth
Money, purchases, sales, prizes, or rewards cannot become durable facts merely because narration says they occurred.
No invented condition
Wounds, healing, health changes, legal consequences, or other durable statuses require supported resolution.
No invented completion
Quests, objectives, new inventory, or arbitrary flags are not silently created through prose alone.
Scene authority matters too
The current runtime treats the canonical scene as authoritative for concrete interactable presence. Background/reference candidates are not proof that a person or object is physically present. If an NPC is not in the scene's present-entity state, the narrator should not silently materialize that specific person for convenience.
Why this matters.A historical database may know that a person existed in Nassau in a given era. That is not the same as proving that person is standing in the room with the player right now.
The referee contract
Authoritative simulation supports the game's broader fair-referee philosophy: similar circumstances should use similar rules, the world should not secretly level-scale to rescue or punish the player, and implementation mistakes can be corrected without redefining them as “bad luck.”
Strict and Guided play styles use the same world truth and underlying rules. Strict primarily reduces unsolicited guidance; it is not a second hidden physics model.