Workflow engine

Governed model workflows, typed state, code gates, and observable character runs.

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:

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:

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:

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:

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:

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.