Platform

Story Room and life simulation

Daily state packages for characters that live between messages.

LoreOS characters should not only react to user messages. They should have a life rhythm: small obligations, quiet days, social contact, visual moments, and occasional friction.

Story Room is the runtime layer that produces that narrative state.

What Story Room creates

Story Room does not send chat messages directly. It creates state packages that the runtime may later use:

  • weekly soft arcs — a non-railroading direction for the week;
  • daily-life packages — compressed time blocks for what happened today;
  • candidate beats — possible small events, frictions, callbacks, or quiet moments;
  • scene cards — concrete scenes the character can safely reference;
  • proactive-hook candidates — possible reasons to initiate a message;
  • safe runtime context — the safe subset the chat actor may use.

Generated does not mean true

Story Room follows lifecycle boundaries:

  • generated candidates are not true;
  • accepted candidates are not automatically visible;
  • committed events are not automatically revealed;
  • private plans and branch forecasts are never runtime input.

This lets the system explore story possibilities while preserving continuity and user agency.

Daily life, not daily melodrama

The goal is not to create a dramatic event every day. A believable character has:

  • low-stakes routines;
  • small external frictions;
  • contact with supporting cast;
  • quiet recovery days;
  • occasional arc movement;
  • user-influenced branches.

The chat runtime can then answer “what did you do today?” from a grounded state package instead of inventing a day from scratch.

Example: before and after

Without a stateful daily-life layer, characters often answer from a generic vibe:

User: what did you do today?
Character: I was just thinking about you.

With LoreOS, the reply can come from state the runtime prepared earlier:

User: what did you do today?
Character: I had lunch with Jungah near the flower market, then spent the afternoon
finishing a small arrangement order. Tiny thing, but I noticed my flower scissors were
getting dull — it made me realize I've been putting off tool maintenance.

Example: daily-life package

The exact internal schema can vary by runtime version, but the shape of the state is:

1{
2  "weekly_arc": "Yura becomes more realistic about opening a small flower workspace.",
3  "daily_life_package": {
4    "day_type": "workday_with_social_contact",
5    "primary_beat": "Yura notices her flower scissors are getting dull during an arrangement order.",
6    "time_blocks": [
7      "morning: checks flower supply notes",
8      "lunch: talks with Jungah about market prices",
9      "afternoon: works on a small arrangement order",
10      "evening: sends a short message about tomorrow's flower prices",
11      "night: writes a note to maintain her tools"
12    ],
13    "safe_to_share": [
14      "I had lunch with Jungah near the flower market.",
15      "My flower scissors felt dull today, so I need to get them sharpened."
16    ],
17    "do_not_reveal": [
18      "future workspace payoff",
19      "private branch forecasts"
20    ]
21  }
22}

This is the product difference: the chat actor is not inventing a day from nothing. It is speaking from safe context created by the character runtime.

What drives Story Room generation

The typed authoring fields are wired into Story Room generation today — they are not planning-only placeholders. When you author a character, these fields directly shape the weekly arcs and daily-life packages the engine produces:

  • life_template → the ordinary daily/weekly rhythm the day is built from;
  • story_engine → recurring tensions, allowed event sources, and supporting cast that events are grounded in;
  • arc_seeds → soft weekly direction (the questions the week leans into);
  • character_direction, relationship_seed, emotion_baseline → tone and constraints;
  • profile.aspiration / life_direction / drama dials → where the evolving life is heading (the north-star lever against a flat, aimless character).

See Character authoring for how to set each of these.

API status

Available today:

  • managed runtime replies;
  • sessions and event logs;
  • character readiness and runtime preview;
  • visual assets, visual readiness, and image probes;
  • Story Room state generated from your authored fields and used inside the managed runtime.

Early-access observability and control surfaces are expanding for:

  • direct Story Room run inspection;
  • weekly arc and daily-life package review (reading the generated packages back);
  • safe-context observability;
  • developer approval flows for larger story changes.

The fields above already drive generation; these are about seeing and steering the generated output. If you need these controls exposed for your app, contact us during provisioning.