> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.loreos.app/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.loreos.app/_mcp/server. # Workflow engine LoreOS is not a single chat completion with a bigger prompt. It is a workflow engine for long-running characters. Each user-visible reply or daily-life update is the end of a governed workflow: ```text API request or scheduled trigger -> app isolation, validation, metering, idempotency -> state projection from typed ledgers -> role-specific model workflows -> policy, quality, and lifecycle gates -> code-owned commit or safe runtime context -> session event, delivery adapter, trace, usage record ``` The public API stays simple because the orchestration happens inside LoreOS. ## Methodology LoreOS follows three principles. ### 1. State before generation The runtime compiles character behavior from typed state: authoring fields, character facts, memory, relationship state, user agency, visual state, Story Room outputs, and recent events. A model is not asked to remember everything inside one prompt. ### 2. Models propose; code decides LLMs are used where language judgment is useful: interpreting conversation, drafting voice, planning safe character state, reviewing quality, and evaluating believability. Code owns schema validation, app isolation, lifecycle transitions, visibility, idempotency, budget checks, and DB commit. That separation is why generated text does not automatically become character truth. ### 3. Runtime only sees safe context Internal plans, future-facing analysis, unapproved candidates, and developer-only seeds stay out of the chat actor's speakable context. The actor receives a compiled, bounded view of what it may use. ## Workflow families LoreOS routes work through specialized workflow families instead of one general-purpose prompt. The exact internal graph can evolve, but the managed responsibilities stay stable: | Workflow family | What it manages | Why it matters | | ------------------------------ | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **State compilation** | Builds the current character state from ledgers and recent events. | The model is not asked to remember everything in one prompt. | | **Conversation understanding** | Interprets user intent, tone, and relationship-relevant signals. | Replies and memory updates can respond to what the user actually did. | | **Character acting** | Produces visible character replies from safe runtime context. | The actor speaks from bounded state instead of private plans. | | **Narrative state planning** | Prepares daily-life context, small frictions, quiet days, and safe story material. | Characters can live between messages without improvising everything at reply time. | | **Research and evidence** | Plans external research, accepts field evidence, gates state commits, and exposes public-safe slices. | Characters can learn about the world without turning unverified claims into lived truth. | | **Policy and quality review** | Reviews grounding, safety, voice fit, continuity, and disclosure boundaries. | Model output is inspected before it becomes user-facing or durable. | | **Visual continuity** | Maintains character identity, visual readiness, and reusable assets. | Images are treated as part of a long-running character, not one-off generations. | | **Feedback and evaluation** | Tracks behavior quality over time and supports trajectory-level review. | Operators can improve characters using evidence, not guesswork. | Workflow outputs use typed contracts. A model is not trusted because it sounds confident; its output must pass validation and downstream gates. ## Model routing Different workflow roles need different models. LoreOS keeps model choice role-specific: Some work is high-volume and structured. Some work needs stronger language judgment. Some work should not call a model at all. LoreOS treats model choice as runtime policy: role, risk, latency, structured-output reliability, and cost all matter. This lets the platform spend model budget where it matters while keeping high-throughput work economical. Routing is not a hidden prompt convention; it is part of the managed runtime contract. ## Reply workflow A managed chat reply roughly follows this path: ```text User message -> session event and usage guard -> conversation understanding -> character state projection -> safe-context compilation -> character actor draft -> policy and quality review -> store character event -> deliver through events, SSE, or managed channels -> record traces, usage, and quality signals ``` The actor is the only node that writes the visible reply. Planners and critics influence the reply by shaping state, constraints, or review decisions; they do not directly send messages to the user. ## Story Room workflow Story Room is a separate workflow that updates character state, not a chat-response generator: ```text Recent context + character state -> narrative planning candidates -> continuity, agency, pacing, and safety review -> approved daily-life state -> safe runtime context for the chat actor ``` The key lifecycle boundary: ```text generated != true approved != visible committed != revealed ``` This lets LoreOS explore possible story movement without forcing the user, leaking future plans, or turning a draft into canon. ## Character operating loop LoreOS is designed as a closed loop: ```text Authoring contract -> state projection -> runtime reply / Story Room package -> user reaction -> quality and relationship signals -> future projection and workflow tuning ``` Over time, feedback-aware signals can make useful recurring patterns more available and fatiguing patterns less prominent. This is how characters can become more specific without letting one model hallucinate a new personality. ## Evaluation and proof LoreOS evaluates more than one reply at a time. The important question is whether a character remains believable over time. The eval stack combines: * deterministic invariant tests for schema, lifecycle, scope isolation, and leakage; * workflow-level evals for understanding, planning, review, and safe-context construction; * single-run and multi-day Story Room evals; * longitudinal and counterfactual trajectory review; * LLM-as-judge for subjective believability, calibrated against human review; * live dogfood traces and usage/cost reports. Green plumbing is not enough. The final artifact must be read: the reply, the daily-life package, the trajectory, or the delivered image must actually feel right. ## What developers get You do not have to rebuild: * memory and character-fact ledgers; * per-user relationship state; * safe context boundaries; * model routing and structured-output validation; * Story Room planning and lifecycle gates; * visual identity and image continuity; * async delivery and proactive scheduling; * usage metering and observability. You call the API. LoreOS runs the character operating workflow behind it.