Boundaries, Quick Checks, OOC Control, and Runtime Health

The Play Contract records hard limits, soft limits, desired and disliked experiences, narrative and sensory intensity, prose density, option presentation, travel continuity, mechanics visibility, difficulty and lethality transparency, romance consent policy, offscreen cutaways, recap density, and table-level safety controls. These are part of the engine's configuration, not an interruption of play.

Use OOC plainly whenever you want to pause, skip, rewind presentation, correct continuity, restate intent, ask what your character knows, change a boundary, request more or less detail, or inspect a ruling. A correction is not counted as an in-story turn. It should not advance time, trigger Storybook, or cause the world to punish the request.

OMEGA also has runtime health gates. Before state-bearing narration, the selected start must be verified, the Clock and Calendar cache must be coherent, no interrupted transaction may be waiting, and no required platform capability may be marked failed. If a gate is unhealthy, the GM should tell you directly and repair the exact owner. The failure is not converted into fictional fog, amnesia, fate, or suspense.

Some release checks require the live Craft platform, a device, a human evaluator, or representative AI models. Those remain Pending until performed. The engine distinguishes this from a real failure and from a static or synthetic pass. You should never be asked to trust a certification claim that the package cannot support.

Once repair succeeds, play resumes from verified canonical state. Narration and already verified writes are not replayed. The goal is simple: technical uncertainty stays visible to the table, while fictional uncertainty stays inside the world.

Quick checks that do not move the world

You can ask for a quick read of the campaign without turning that question into fictional time. These are ordinary natural-language requests, not slash commands. Clear OOC/read-only requests do not advance the Clock, Storybook, factions, opportunities, weather, or ambient events.

Useful examples include:

• Status — a compact view of what matters right now: where you are, time/weather when the world uses them, people visibly present, relevant conditions/resources, known active objectives or pressures, and other player-facing state that is actually useful. Empty or unsupported sections are left out.
• Where am I? / Who's here? — current scene facts, not a world encyclopedia.
• Catch me up / Recap — the recent story and current situation from Storybook/current state without exposing things your character should not know.
• What changed? — only verified, player-visible changes. If the engine cannot support an exact change from committed state or recent history, it should say that instead of inventing a receipt.
• Relationships — the relationships tied to your Character, filtered to what is observable or legitimately known. The GM does not reveal private NPC interiority or decide how your Character feels.
• Reputation — player-visible audience reactions and narratives. Hidden audiences stay hidden. A world can use names/ranks instead of raw numbers.
• Travel options — routes your Character can reasonably know from the current Location, with known access, timing, and hazards where available. Hidden routes stay hidden.
• What do I know about X? — answers through the knowledge firewall, so public truth, rumors, memories, and your Character's actual knowledge are not automatically treated as the same thing.
• Conditions, Inventory / Equipment, Abilities, and Upcoming deadlines — focused reads of existing state rather than a giant permanent HUD.
• Play settings — the current Play Contract: prose density, sensory intensity, mechanics visibility, choice presentation, travel continuity, recap/HUD density, difficulty/lethality transparency, and related preferences.

The wording matters more than the keyword. “Status” as an OOC question is a utility read; “I ask the nurse for my father's status” is an in-world action. The GM should use context rather than a command parser.

You can change Play settings naturally: “make the prose more detailed,” “show fewer mechanics,” “only list choices when I ask,” or “number choices and letter travel directions.” Those preference changes consume no fictional time. They update the existing Play Contract or player-facing conventions rather than creating a second settings system.

Quick checks are intentionally on-demand. LWE does not paste a dashboard after every response just because the data exists. The goal is to make useful state easy to reach without making the game feel like an engine console.