Browser client
Displays current state, recent narration, character data, inventory, history, maps, and the free-form action field.
ARCHITECTURE
From intention to committed reality.
A turn is not simply “send text to an AI and print the answer.” The current runtime separates player intent, canonical context, narrative reasoning, operation validation, and persistent state commit.
Runtime layers
Authenticated server layer
Checks player access, character ownership, revision freshness, routing, canonical context, and commit eligibility.
Authoritative data layer
Stores campaign state, revision history, events, snapshots, historical registries, and other durable world data.
Turn lifecycle
Player inputThe player writes a natural-language action. The client sends it with the active character, a unique turn identifier, and the expected revision.
Authentication and accessThe server verifies the session and closed-alpha access before attempting to resolve the turn.
Revision checkThe expected revision is compared with current campaign state. A stale client is rejected rather than allowed to overwrite newer reality.
Canonical context assemblyThe server constructs the state and runtime context that the turn is allowed to use: current scene, world time, present entities, supported destinations, inventory, relationships, and relevant world data.
Resolver routingThe turn router selects the normal player resolver or a specialized naval resolver when authoritative battle or engagement context requires it.
Bounded narrative reasoningThe narrative layer produces player-visible narration and, when appropriate, proposes only operations from the supported resolution vocabulary.
ValidationProposed operations are checked against the canonical input: valid destinations, present NPCs, bounded time, owned objects, supported operation types, and other constraints.
Authoritative commitApproved persistent changes are committed through server-side operations. The result advances state revision and records the turn.
Client refreshThe browser receives narration and the new revision, then reloads the authoritative state for display.
The AI boundary
The narrative model is part of the runtime, but it is not the database and it is not the final authority on persistent facts. It receives a bounded representation of current state and is instructed not to manufacture concrete entities, player choices, or unsupported persistent outcomes.
Important distinction.Narration and proposed state operations can be produced together before the commit. The server then decides whether the proposed operations are legal and commit-worthy. This is why the accurate architecture is “bounded proposal + server validation + authoritative commit,” not “the AI decides the world.”
Why revisions matter
Every committed turn belongs to a specific state revision. The client states which revision it expects to be operating on. If another committed action has already advanced the character, the stale request can be rejected. Unique turn identifiers also support idempotent handling so a retried request does not have to become a duplicated action.
expected revision N
+
unique turn identifier
↓
resolve against canonical state N
↓
validate
↓
commit once
↓
state revision N + 1
Specialized resolvers
The architecture allows authoritative routing without changing the player's interaction style. For example, the current router can direct an appropriate encounter into the naval resolver while the player still writes an ordinary natural-language action. The interface does not need to expose a separate command language simply because the backend uses a specialized mechanic.