Learning library / Complete beginner handbook

OD beginner handbook

All 26 lessons in one readable, printable document.

Lesson 01

Getting started with OD

You will open the site, learn the main controls, and send a first message. You do not need a character sheet, art prompt, or game engine for this lesson.

OD is an adults-only website. Complete its own age and account steps before using the service. An AI character is a fictional participant whose replies are generated by an artificial-intelligence model. A chat is the conversation you have with that character. An image model makes pictures and may be different from the model writing the chat.

Before you begin

Open the OD website in your browser. Have access to the account you intend to use. If the site offers a plan or a paid operation, read the current terms and displayed cost before choosing it; you can learn the navigation without buying anything.

Step by step

Sign in. Use Login, or complete the site's registration process if you need an account. Keep your sign-in details in the site's own login form.
Find the navigation. On a narrow screen, expand the site menu if its labels are hidden. Look for the labels below rather than relying on an icon's shape.
Open Explore. This is the starting point for browsing characters made available by creators.
Choose a character. Read its public description. This explains the premise to you. Then read the opening message, called the Greeting.
Identify your role. Decide who you are in this particular conversation. You can begin with an ordinary visitor without inventing a long biography.
Write a first message. Enter it in the chat message box. For example, in a suitable archive scenario, write: “Hello. I'm looking for an old town map. Can you help?”
Send once and read the reply. Check whether the character addressed your question. Your next message can answer, ask for clarification, or take an action.
Return to Chat. Find the conversation you just used. This gives you a way back without starting another conversation accidentally.

The Known State Quickstart describes browsing, beginning a chat, creating a character, and generating an image.

What the main areas are for

Area	Use it when you want to
Explore	Find a public character
Chat	Open or continue conversations
Create	Build a character of your own
My AI	Find characters you have created
Generate	Open the available media-generation tools
Profile	Find account and persona settings
Help Desk	Get help with account or service problems

These labels appear on the public site. Their position can change between desktop and mobile views.

How to write an action

Dialogue can be ordinary text. To describe an action, place an asterisk before and after it:

*I place the folded map on the desk.* Is this the right district?

Here, you supplied the action. You do not need to ask the AI to decide what your character does. Action formatting.

Check your result

You should be able to find your conversation again, identify who the AI character is, and send a message without mixing up the chat and image tools.

If something goes wrong

A button is missing: expand the menu and check that you are signed in. Account features can differ. Use the service’s Help Desk if the feature is still unavailable; do not enter credentials into a third-party tutorial or unverified support form.
The opening assumes a role you do not want: choose another scenario or explain the desired starting role before continuing.
The reply invents your decision: correct that particular action and use the user-agency instructions in Personas and Custom Instructions.

Next: Create your first character, or learn the chat controls.

Back to the tutorial index

Lesson 02

Create your first character

You will build a private practice character named Mira and begin a short conversation. A private character is for your own use; publishing to the community is a separate procedure. Private visibility is not a promise that prompt text is secret from the service, so keep passwords and sensitive personal information out of character fields.

Mira is an original example: a 30-year-old adult woman who works as an archivist. Her job is to help visitors find accurate records. Replace these facts if you prefer another original character.

Before you begin

Sign in and open Create. Keep a copy of your text outside the site so you can revise it later. If you have never used the navigation, complete Getting started.

Step by step

Choose the broad appearance. In the creation flow, locate Style and choose Realistic or Anime. These are broad visual choices. Choose the character's gender as appropriate.
Set the visible features. Work through General, Face, and Body where shown. For this example, aim for warm brown skin, brown eyes, black hair in shoulder-length braids, and a lean build. Use the closest available options; avoid choosing presets that contradict your intended description.
Open Details. Enter the name Mira and age 30. Select or write Archivist for occupation. If there is a relationship setting, choose one compatible with a first meeting rather than an established partnership.
Open Advanced Details. Find Greeting, Scenario, Additional Personality Details, and Extra Details. These labels have different jobs. The Known State builder walkthrough shows this grouping; use the named fields if your layout differs.
Add the personality. Paste the next box into Additional Personality Details, often shortened to APD.

Mira is patient, precise, and curious. She checks a record before making a confident claim. She speaks clearly, with occasional dry humor. She wants visitors to find useful information while keeping the archive accurate. She can disagree politely and admit when she does not know something.

Set the opening situation. Paste this into Scenario.

The user is an adult traveler visiting the town archive for the first time. Mira is at the north desk in late afternoon. A local map is missing from its usual shelf. Mira has not met the traveler before. No prior friendship, completed delivery, or traveler decision is assumed.

Write the opening message. Paste this into Greeting.

*Mira closes a catalog and looks toward the visitor space.* “Welcome to the archive. Are you looking for a particular record, or would you like help getting started?”

Add a small behavior rule. Paste this into Extra Details, often shortened to ED.

Describe Mira and the surroundings. Leave the traveler's actions, words, decisions, and private thoughts to the user. Distinguish a suggested action from an action that has actually happened.

Finish the character preview. Follow the creation flow's image and completion controls. Read any displayed generation cost before submitting. Choose an acceptable base image and keep the character Private while you test. Reopen the saved character and confirm the intended text and visibility remain before starting the test chat.
Open a new chat with Mira. Send: “I'm looking for the missing map. What do you know so far?” Read the actual answer before adding more rules.

Check your result

Mira should introduce a useful next step while leaving your response open. Record whether the saved Greeting appears, the map remains missing, and the reply leaves your next action undecided. These short examples are for private practice, not a complete public-submission package. Inspect her appearance separately from her dialogue: a good picture does not establish that the personality works.

If something goes wrong

The character assumes a close relationship: reconcile the relationship selector, Scenario, Greeting, and APD.
Appearance options conflict: revise the relevant preset or physical field. Do not add a second contradictory description.
The opening is too passive: give Mira a concrete problem or question in the Greeting rather than adding more biography.

The character workflow organizes creation into concept, appearance, writing, optional progression, gallery, and testing.

Next: Character sheets, then CPD and Face Details.

Back to the tutorial index

Lesson 03

Make and use a character sheet

You will create one reference sheet that keeps a character's facts organized, then move each part into the appropriate OD field.

A character sheet is a worksheet you maintain. It is not a special OD command, and it does not become a native import simply because it is written in a box or saved as JSON. Canon means the facts you have established as true for this story.

Before you begin

Have a character concept or the practice character from Create your first character. Open a text editor or document beside OD.

Step by step

Name the record. Use “Mira character sheet” so you can identify it later. If you keep versions, add a date or revision number.
Write the stable facts. Record age, role, appearance, motives, capabilities, and established relationships. Leave unknown facts blank rather than filling them with guesses.
Write behavior as decisions. “Checks uncertain claims against a source” gives you something to observe. “Perfect personality” does not.
Separate current conditions. Clothing, location, present companions, and immediate tasks belong in a current-scene section.
Record knowledge carefully. Note what the character learned and how. Another character's private experience is not automatically shared knowledge.
Use the example below as a worksheet. Copy it to your local document, not into one OD field.

Name: Mira
Age: 30, adult woman
Role: Town archivist
Appearance: Warm brown skin; brown eyes; black shoulder-length braids;
lean build.
Motive: Help visitors find useful records without falsifying the archive.
Traits: Patient, precise, curious.
Written speech style: Clear sentences; occasional dry humor.
Capability: Catalog research and local records.
Limitation: Does not know every answer or the traveler's private thoughts.
Relationships: Rowan is a courier she recognizes from work.
Knowledge: Knows the archive catalog; has not seen Rowan's latest parcel.

Current scene: North desk, late afternoon.
Current clothing: Navy jacket.
Immediate problem: A map is missing from its usual shelf.
Open choice: The traveler has not chosen what to investigate.

Map the sheet into the site. Use the destinations below rather than pasting the complete worksheet everywhere.
Save your local revision. After an intentional character change, update the canonical sheet and any affected fields together.

Where each part goes

Sheet content	Destination
Stable visible features	Custom Physical Details and available Face Details
Motives, traits, written speech style, capabilities	Additional Personality Details
Initial situation and user role	Scenario
First message	Greeting
Relevant world rules or supporting cast	Extra Details
Facts learned during this chat	A suitable memory record
Outfit, pose, lighting for one image	That image's scene prompt

The character-writing guide describes the narrative fields; the worksheet is a practical way to prepare their content.

Written speech style describes wording and tone. The audio Voice selector controls how spoken output sounds; see Voices and calls.

Optional drafting prompt

If you use a writing assistant, give it your facts and ask:

Organize the following facts into separate Appearance, APD, Scenario,
Greeting, and ED blocks. Preserve the supplied age, role, appearance,
relationships, and boundaries. Leave unknown facts unspecified.
Do not add gameplay statistics or a new romance premise.
Facts: [replace this line with your character facts]

Read its draft before copying the individual blocks into OD.

Optional: make motives and knowledge easier to inspect

Use a short character spine when a trait list does not explain the person's choices. A spine connects a motive, a constraint or tension, and a plausible response. It is an optional authoring worksheet; every character does not need a wound, hidden fear, false belief, or relationship arc. See the character-spine module.

Add only useful lines to your local sheet:

Current goal: [replace with the character's current objective]
Important value or motive: [replace with an established or deliberately authored trait]
Constraint or tension: [replace, or omit]
Established fact and source: [replace with what is known and how]
Character belief or suspicion: [replace, or state unspecified]
Unknown: [replace with what has not been established]

A belief can be mistaken without changing the world fact. A reported address is not automatically a verified destination. A creator's explicit correction is different from an in-character claim or lie; establishing a world fact also does not make every NPC know it. Keep the worksheet local, then put motives and written voice in APD, the starting situation in Scenario, and learned facts in the maintained scene or memory record.

Choose one conflict-free behavior base. Add a small module only for a specific need, reconcile its wording with existing text, and remove unused scaffolding. A larger sheet is not evidence of better model behavior.

Turn a broad trait into usable wording

This original local drafting exercise practices the writing guide's advice to describe behavior. Replace Mira is realistic and smart with a choice the reader can inspect:

When a visitor gives an unverified address, Mira checks the available
register before confirming it. If the register is unavailable, she says
which part remains uncertain and offers a way to check it.

The subject is Mira; the situation is an unverified address; the response is checking or naming the gap. Put the resulting personality line in APD, rather than copying the worksheet into every field. A record of an address already checked belongs with the accepted scene facts. Try a different uncertain claim in chat and inspect the reply. This is a proposed exercise, not a demonstrated enforcement rule. The OD prompt lab provides more practice with wording and placement.

Check your result

You should be able to answer “Where is this fact maintained?” for each important detail. A name or record ID helps you find your local sheet; it does not make the AI retrieve an absent file. Reopen the saved editor and compare one appearance fact, one motive, and the opening premise with the worksheet. A missing or truncated field is a save/import problem to resolve before judging the next reply.

If something goes wrong

Two versions disagree: choose the intended current fact and remove the stale copy.
The sheet becomes very long: move historical notes to a separate archive and retain the facts needed for the next scene.
Every new picture repeats the same outfit: move that outfit out of permanent appearance unless it is deliberately permanent.

Next: CPD and Face Details or personality and roleplay engines.

Back to the tutorial index

Lesson 04

Set permanent appearance with CPD and Face Details

This lesson gives Mira a reusable physical description. Mira is a fictional 30-year-old adult archivist with warm brown skin, brown eyes, black shoulder-length braids, and a lean build. Her profession explains the story; it does not require a uniform or archive in every picture.

CPD means Custom Physical Details, an appearance field. CFD means Custom Face Details, available in some workflows. An image model is the selected generator. A preset is a ready-made selection that contributes instructions. A scene describes this particular picture.

1 Open the character appearance settings

For a new character, start at Create. For an existing character, open My AI, choose Mira, and locate Edit in the character's options. Find the appearance controls, including Custom Physical Details. The exact grouping can vary; do not put this lesson's text into Additional Personality Details merely because that field is easier to find.

Before replacing anything, copy Mira's existing appearance text into your notes. Record the selected model and relevant face, hair, and body presets. You need this record if a change makes the result worse.

2 Check the overlapping selections

Compare presets with the intended character. A blond-hair selection conflicts with black braids. Keep the closest useful selections and correct specific conflicts. Clearing every field is not a required installation step. The Known State workflow recommends a simple base and gradual changes. Appearance workflow

Check age separately where the editor provides an age field. Keep Mira's established age as 30. A written age does not guarantee a particular face.

3 Enter the permanent description

Paste this example into Custom Physical Details, replacing only the appearance block you intend to replace:

30-year-old adult woman, warm brown skin, brown eyes,
black shoulder-length braids, lean build

Leave her navy jacket, current pose, and archive out of this field. Those will belong to an individual scene.

If a realistic workflow also offers Custom Face Details, the Known State guide suggests beginning with the same focused appearance description in both fields. For this first comparison, use the same block. This is the guide's suggested starting workflow, not proof that both fields always have equal influence. If CFD is absent, continue with the fields actually available.

4 Save then request a simple comparison image

Use the editor's save control. Reopen the character if needed and confirm that your text remains.

Go to Generate, select Mira, and locate the custom scene prompt. Paste:

navy jacket over a cream shirt, standing with arms relaxed,
eye-level waist-up view, plain gray background, soft daylight

Check the selected model and displayed generation cost. Generate when ready. The target is Mira's visible identity in a simple scene, not a finished archive illustration.

5 Inspect before adding more details

Check skin tone, eye color where visible, braid length, and overall build. Keep the prompt and image together. If one feature is wrong, change that feature's wording or conflicting preset before changing the whole description.

Checkpoint: You can identify which text defines Mira permanently and which text requested the jacket and background. Nothing in the permanent block requires her to stand still or wear the same outfit forever.

Keep a withdrawn placement trick out of the baseline

An October 31, 2026 review of supplied community notes found an explicit correction: the guide's author withdrew the claim that moving all persistent features into a custom skin-tone field makes clothing cover them reliably. The author reports that other factors affected the initial examples and that later tests on clean characters contradicted the claim. The correction itself has no supplied date, and this library has not reproduced the trials.

Do not move scars, markings, jewelry, or makeup into skin tone as a universal visibility workaround. Use the actual appearance fields for their documented jobs, and inspect clothing coverage in the returned image. A stable feature and its visibility in a particular crop are different facts. An opaque sleeve can conceal a forearm marking; a request to preserve the marking does not require showing it through the sleeve.

If a character has deliberately authored alternate forms, record the current form and its visible features explicitly rather than combining every form into one permanent description. The current-form continuity module provides a planning method; it does not change native fields automatically.

Three common problems

Hair keeps changing: compare every active hair selection with the CPD. Correct a contradictory length or color, then repeat the same scene.
The jacket appears everywhere: search permanent appearance fields for clothing. Move the jacket instruction into the scene and save the correction.
The face changes after a large rewrite: restore your saved description. Make a smaller revision and compare with the accepted image instead of adopting the unwanted face.

Next: Choose an art style. Return to the Tutorial index.

Lesson 05

Choose an art style without changing the person

This lesson makes three visual versions of the same archive scene. The examples are original style choices to compare, not guaranteed recipes.

First separate three questions:

Subject: who appears? Here, Mira is a 30-year-old adult archivist.
Scene: what is happening in this picture? Mira wears a navy jacket inside an archive.
Style or medium: how is it depicted? Watercolor, anime illustration, and photography are different treatments.

CPD, or Custom Physical Details, holds permanent appearance. An image model is the generator selected in the interface; a watercolor description does not select a model. A preset is a reusable selection. In this lesson, “style preset” means your saved text example, not necessarily a native Community Preset.

1 Establish one scene first

Complete Mira's appearance, then open Generate and select her. Record the actual model label.

Locate the custom scene prompt. Begin with this text:

navy jacket over a cream shirt, standing beside archive shelves,
holding a closed folder at waist level, eye-level waist-up view,
soft window light

Keep this wording unchanged while comparing styles. Her brown eyes, warm brown skin, black shoulder-length braids, and lean build should continue to come from her character definition.

2 Choose one rendering description

Add one of the following blocks to the end of the scene prompt. Do not paste all three.

Watercolor choice

watercolor illustration, translucent color washes, visible paper texture,
soft pigment edges, restrained detail around the face

Soft anime choice

soft anime illustration, gentle contour lines, rounded tonal shading,
natural colors, selective detail in the face and braids

Photographic choice

photographic rendering, natural skin and fabric texture,
plausible perspective, soft environmental light

These describe rendering. They do not authorize a younger face, different hair, altered physique, or a new personality.

3 Match the writing to the available model

OD recommends short visual phrasing for Dreamy and Fluidity, while Vivid and editing models can use descriptive prose. Exact known Fluidity tags may use underscores; ordinary phrases can remain ordinary words. This is not a reason to invent new underscored tokens. Prompting reference

For a prose-oriented route, you can instead paste the following into its scene prompt:

Mira wears a navy jacket over a cream shirt and holds a closed folder
beside archive shelves. Show her waist-up at eye level in soft window
light. Render the scene as a watercolor illustration with translucent
washes, paper texture, and gently softened pigment edges.

This assumes the selected character already supplies Mira's appearance.

If you need to exclude an unwanted visible element and this generation route offers a separate Negative Prompt field, keep that exclusion there. Do not append a list of unwanted objects or no ... instructions to the positive scene prompt. The prompting reference gives this distinction; it does not establish that every model or image-editing route exposes the same fields.

4 Make a comparison you can interpret

Save the first prompt and result. For the next comparison, replace only the rendering description. Keep the character, scene, model, and exposed settings unchanged. Generation still varies: one pair cannot prove the style text caused every visible difference. Repeat within your chosen budget before deciding a wording change is more reliable.

If you also change the model, label that as a separate experiment. A different result would then have more than one possible cause.

Look for the intended surface treatment: pigment washes, illustrated contours, or photographic textures. Separately inspect Mira's face, skin tone, braids, and build. An attractive picture can still fail the identity check.

5 Save a usable choice

Keep the style wording beside the image it produced, with the date and actual model. Use a descriptive note such as “Mira archive watercolor attempt,” rather than claiming the wording always works.

Checkpoint: Removing the style block leaves a complete subject-and-scene request. Replacing it changes rendering intent without rewriting Mira.

Resolve a placement claim before copying it

The supplied community discussion, reviewed October 31, 2026, refers to a PD section without expanding that abbreviation. It also reports a style name appearing as unwanted text inside an image. These observations do not establish a universal field or prompt order. If a recipe names an abbreviated field, identify its full label, model, and route before using it; do not assume that PD means Public Description or Custom Physical Details.

For your next comparison, describe the visible treatment you want: for example, translucent pigment washes and softly feathered edges. Keep the scene unchanged and inspect unwanted lettering separately from rendering quality. Repeated names, stronger weights, or a different order are additional experimental changes, not established remedies.

For the supplied tag catalog and reported watercolor, flat anime, manga and ligne-claire combinations, use the art-style reference. It also records the unsuccessful sepia interaction and preserves recipe-specific spellings and weights.

For a separate prompt-writing workspace with local presets and a pose finder, open Prompt Crafter. Copy its outputs into the appropriate fields of your chosen route.

Three common problems

A mixed or muddy finish: remove competing rendering blocks, then test one choice.
Mira's body changes with “realistic”: restore the accepted appearance and describe surface treatment more specifically.
A style has no visible effect: inspect the actual model and active presets. Simplify the style wording before adding emphasis or more names.

Next: Generate images. Back: Permanent appearance or the Tutorial index.

Lesson 06

Generate an image from a character or a standalone prompt

This lesson creates Mira in the archive and then explains a two-person alternative. Generation makes a new image from the supplied inputs. It is different from editing an existing picture.

An image model is the selected generator. A preset supplies a ready-made pose, outfit, or background instruction. The scene prompt describes the current picture. CPD, meaning Custom Physical Details, supplies permanent appearance when the selected-character workflow includes it.

1 Choose the route

Open Generate. Decide whether to select an existing character or use an available standalone option, sometimes labeled Free Play. The public page describes both routes; the account's current interface determines which controls you see.

For the first exercise, select Mira. Verify that you chose the intended character, not simply a similar cover image. Confirm her record describes a 30-year-old adult woman with warm brown skin, brown eyes, black shoulder-length braids, and a lean build.

2 Inspect the inputs already active

Locate the model selector and record its label. Look at pose, outfit, and background selections before typing. A seated preset can oppose a request to stand.

For this exercise, use custom controls where available and remove only selections that conflict with the example. Do not assume that an empty-looking field disables every underlying preset.

Check custom-prompt access before preparing the comparison. The public Generate form, read November 1, 2026, labels Custom prompt as Premium and shows an upgrade message. If your chosen route locks that field, pause this custom-prompt exercise or use the controls your account actually offers. Having enough dreamcoins does not by itself establish access to a locked control; do not paste the scene into permanent CPD to work around it.

Follow the style lesson if you need to choose a medium. Keep the first comparison free of additional style experiments.

3 Enter the selected character scene

Paste this into the custom scene prompt, not Mira's permanent appearance field:

navy jacket over a cream shirt, dark trousers, standing beside archive
shelves, holding a closed folder at waist level, eye-level waist-up view,
soft window daylight

The Known State gallery workflow says selected-character Generate receives the character's permanent appearance. That is why this exercise puts only changing details in the scene; it is not a guarantee about every other generation or editing route. Scene versus appearance

Read the request once as a picture: one person, specified clothes, a readable pose, archive shelves, and simple illumination.

4 Review and generate

Check the displayed cost, batch size, and any exposed settings before pressing Generate once. Start with the smallest useful batch. Keep the returned images even when you prefer only one; failures are useful comparison evidence. If the request appears stuck, inspect its status and gallery before submitting again so an uncertain response does not become a duplicate paid request.

The target is recognizable Mira in the requested jacket and archive. Do not judge the attempt solely by polish. Check hair, face, skin tone, clothing, crop, and unwanted extra people separately.

Save the prompt with the image identifier or filename. Record what was correct and what needs revision.

5 Use a standalone prompt when no card is selected

A standalone input cannot rely on Mira's name to supply her physical definition. For an available standalone route, paste this complete example into its prompt field:

30-year-old adult woman with warm brown skin, brown eyes, black
shoulder-length braids, and a lean build; navy jacket over a cream shirt,
dark trousers; standing beside archive shelves, holding a closed folder;
eye-level waist-up view, soft window daylight

This creates a new interpretation. It does not reproduce the pixels of an earlier picture.

6 Add Rowan deliberately

For a two-person standalone exercise, replace the single-person prompt with:

Mira on image left: 30-year-old adult woman, warm brown skin, brown eyes,
black shoulder-length braids, lean build, navy jacket.
Rowan on image right: 32-year-old adult man, light skin, green eyes,
short red hair, freckles, gray courier jacket.
Both stand beside archive shelves, facing one another, hands relaxed;
eye-level waist-up view, soft window daylight.

The target is two distinct adults. Rowan's profession motivates his presence; the visible jacket remains an explicit scene choice.

Checkpoint: You can explain whether the current input gets identity from a selected card or from the prompt itself.

Three common problems

Unexpected clothes or pose: inspect active scene presets before rewriting Mira.
Hair or eye colors swap between people: shorten each person's clause and keep position, identity, and clothing together.
The scene ignores a revision: return to the previous prompt and change one phrase. Record whether the actual combined prompt is available instead of guessing what reached the model.

Next: Edit an existing image. Back: Art styles or the Tutorial index.

Lesson 07

Edit an existing image while checking what stays unchanged

This lesson changes only Mira's navy jacket to dark green. Mira remains the same fictional 30-year-old adult archivist. You will work from an image already generated inside OD.

An edit modifies a selected source picture. A scene is the situation shown in that picture. An editing model is the tool selected to perform the change; it may differ from the model that generated the original. A preset is a ready-made instruction and can introduce changes beyond the words you type.

1 Choose a useful source

Open your generated-image collection and locate an accepted picture of Mira. The ideal exercise source shows her warm brown skin, brown eyes, black shoulder-length braids, and navy jacket clearly.

Open that image and locate its Edit action. If Edit is unavailable, do not substitute copying its prompt into Generate: that would make a new generation, not edit the original.

Keep the original's identifier and an available saved copy. You should be able to return to it after a disappointing result.

The Help Center article dated March 9, 2026 says external reference-photo uploads are not allowed. This lesson uses an in-app generated source; it does not authorize uploads or imply that every later media-reference feature follows the same workflow. Reference-photo policy

2 Inspect the editing controls

Record the actual editor or model label. The Known State guide describes Spark for ordinary clothing and background edits; use the options actually present in your account. Locate the edit instruction field. Do not put the instruction into Mira's permanent appearance settings. Editing guidance

Look for any active preset that would change the pose, outfit, or background. For this exercise, retain only inputs compatible with a jacket-color change.

3 State the change precisely

Paste this into the edit instruction field with the original image selected:

Change only Mira's navy jacket to dark green, keeping the same cut and
fabric. Preserve the same adult woman's face, brown eyes, warm brown skin,
black shoulder-length braids, lean build, expression, pose, hands,
camera angle, crop, archive background, and existing lighting.

This is a preservation goal for comparison. The sentence cannot guarantee that every retained feature will survive.

Notice what the request does not require: new shelves, a different hairstyle, a smile, or a fresh camera angle. Saving those ideas for later makes this result easier to judge.

4 Use selective editing if available

A September update added brush-based selective editing to ordinary image editing. Availability and exact controls should be checked in the current editor. Selective-editing update

If a brush or region-selection tool is shown, follow its instructions to select the jacket. Keep the selection away from the face and braids as far as the garment boundary allows. Use the same edit text.

If no selection tool appears, continue with the ordinary edit field. Do not invent a mask parameter or assume that unselected areas are perfectly locked.

5 Generate and compare side by side

Read the displayed cost before submitting the edit. Once the result appears, compare it with the actual original.

First check the intended change: is the jacket dark green, with the same garment design? Then check Mira's identity, braid length, build, hands, pose, framing, background, and light. Look at the face before accepting an otherwise attractive image.

Keep a short note:

Requested: navy jacket becomes dark green.
Observed: [describe what the result actually shows].
Unwanted changes: [list them, or write none observed].
Decision: keep result / return to source / revise instruction.

The brackets are note-taking prompts, not text to send to the image editor.

6 Choose the next source deliberately

Keep a successful green-jacket result if it is useful. Retain the original as well. For a later background experiment, decide whether you want the navy or green jacket before choosing the source image.

Checkpoint: You have inspected both images. You can name the requested change and any unintended changes instead of claiming preservation from the prompt alone.

Treat several editing passes as a source chain

Community examples reviewed October 31, 2026 describe achieving a composition through several passes, with unwanted pose and background changes along the way. Keep those as creator reports, not evidence that a particular emphatic phrase or numeric weight reliably preserves an image.

For each pass, record the selected source, the one intended change, the returned candidate, the displayed charge, and whether you accepted that candidate as the next source. Compare against the original as well as the immediate parent; small changes can accumulate. Keep an unsuccessful weather or lighting attempt from silently becoming the new identity reference.

In a two-person archive scene, inspect the two adults separately, then their relative positions, hands, crop, and the door's location and shape. A recognizable face does not establish that the rest of the composition survived. If you deliberately crop a source, save the crop as a distinct input and recheck what is still visible. The current-form continuity module helps distinguish intended identity or form changes from drift.

Keep a two-image experiment conditional

A supplied suggestion proposes borrowing identity from one image and composition from another. Try that only through a current workflow that actually accepts the necessary generated-image inputs and lets you identify their roles. If the editor offers one source image, do not assume that mentioning another image or character name supplies its pixels. Continue with the single-source exercise instead.

Where the required inputs are supported, first write a source-role note: which image supplies the person, which supplies pose and layout, and which properties may change. Review every pass and retain failures. This is a proposed experiment; no two-image native procedure or successful preservation result is established here.

Three common problems

The face changed: return to the accepted original and retry the narrow jacket change.
The jacket changed shape: explicitly retain its cut and fabric; inspect overlapping outfit instructions.
Each correction makes the picture worse: stop extending that edit chain. Choose a cleaner source and make the next change from it.

Next: Gallery and image reuse. Back: Generate images or the Tutorial index.

Lesson 08

Personality and roleplay engines

Tutorial index

What you will make

You will give Mira a recognizable voice and a few rules for interactive storytelling. Mira is a 30-year-old adult archivist: precise, patient, and dryly humorous. You play an adult traveler.

Additional Personality Details (APD) describes a character's motives and behavior. Extra Details (ED) holds relevant world information and operating rules. These field purposes are documented in the writing guide; they do not establish an absolute priority between fields. A roleplay engine here means written guidance for a language model, not installed software. An NPC, or non-player character, is someone the model portrays. Agency means you choose your own actions, words, and feelings.

Before you start

Have an editable Mira character and a local copy of its existing text. Use a practice chat for the exercises. These examples are short teaching fixtures, not a complete public-submission package; follow any current field validation.

Follow these steps

Open Mira's editor. The Help Center's community-written FAQ describes My AI → choose character → three dots → Edit. Check the labels in your account. Find APD and ED; do not paste the examples into Public Description.

Replace conflicting personality text in APD. Preserve unrelated established facts, but remove earlier claims that Mira is impatient or habitually careless. Put this original example in Additional Personality Details:

Mira is a 30-year-old archivist who protects accurate records.
She is patient with questions and precise about evidence.
When uncertain, she says what remains unknown and checks the register.
She uses brief, dry humor without humiliating visitors.
She wants records and deliveries handled correctly but dislikes rushed signatures.
Voice example: "The paperwork is optimistic. Let us check the parcel."

Give the story rules one destination. Put the following in Extra Details, replacing an older engine that covers the same ground. Keep other relevant lore in separate short paragraphs.

Portray Mira and relevant supporting characters.
Leave the traveler's speech, actions, decisions, and private feelings to the user.
Distinguish an attempted action from its completed outcome.
Each person knows only what they observed, were told, or reasonably inferred.
Mark uncertain beliefs as uncertain.
NPCs may disagree, ask questions, and pursue their own reasonable goals.
Offer an actionable situation and leave room for the traveler to respond.

Check the rest of the setup. Read Scenario and Greeting. Remove any sentence that makes the traveler automatically sign, trust Mira, or surrender the parcel. Do not copy the whole APD into ED. Repetition adds maintenance work and can preserve conflicting versions.
Save using the visible control, then begin a practice conversation. Record the selected chat model and settings in your local notes. If the editor changes incur a charge, review the displayed amount before submitting. A saved edit is not proof that an existing conversation has discarded its older context.
Try a cooperative message. Send: I place parcel A17 on the counter and ask what needs checking. Look for Mira checking something concrete and answering in her own voice. She should not announce that you signed a receipt unless you chose to do so.
Try a disagreement. Send: I want to skip the register and leave now. A useful response can be patient but firm. For example: "You may leave. I cannot record a delivery I have not checked." This is an illustrative response, not a required output.
Test knowledge and choice. Send: Rowan has not arrived. I wonder whether he knows the western gate is closed. Mira may speculate or offer to tell him later. She should not suddenly make the absent courier remember the closure, or decide that you will fetch him.

Keep one behavior base and a recognizable written voice

A voice fingerprint is a small description of wording: sentence rhythm, vocabulary, directness, humor, and how certainty is expressed. It is a writing aid, not an audio setting or a native parameter. The character-spine module connects that voice with a motive and choices.

If Mira's replies sound generic, revise her existing APD voice guidance rather than adding another full engine. This original replacement is for APD:

Mira uses precise vocabulary, direct answers, and short-to-medium sentences,
with occasional dry humor. When established workload makes her tired or rushed,
she may become briefer while retaining her care with evidence.
She can answer with an observation or practical action; a question is optional.

Context can change expression without replacing identity. Do not infer an illness, diagnosis, or private feeling from a brief reply. Preserve meaningful learning and development rather than freezing every trait. Keep one maintained set of agency and knowledge rules in ED or the chosen chat-level instructions, and reconcile conflicting examples before retesting.

Teach the voice without prescribing every reply

The OD writing guide recommends brief voice samples when a description alone is unclear. For an optional APD revision, replace the existing single sample with these original examples; keep the surrounding motives and facts:

Voice samples, to illustrate tone rather than repeat verbatim:
Asked to confirm an unchecked address: "A promising label. Not yet proof."
Asked an ordinary catalog question: "Start with the district index.
It is less dramatic than the rumor and considerably better organized."

Then ask a new question, such as Which record would help us compare the street names? Inspect whether Mira uses her own wording and addresses that question. Repeating the sample is a separate failure from losing the personality. Keep the samples consistent with any point-of-view or formatting instructions already selected. See the OD prompt lab for a small wording comparison.

Optional: stop comparative flattery

The Comparison Ban module preserves a supplied anti-cliché protocol and shows how to apply it. Use it when a character should ground praise in the user's established present actions, without ranking the user against past partners, other people, or hypothetical majorities.

Place it once beside the written-voice guidance in APD, or in the single ED location where your setup already maintains dialogue rules. For a chat-specific trial, use that chat's Custom Instructions. Reconcile conflicting examples first. The module does not require praise or erase established continuity. Its proposed checks have not been run as controlled OD tests.

Checkpoint

You are ready to continue when Mira remains recognizable through cooperation and disagreement, leaves your decisions open, and distinguishes known facts from guesses. One good reply is a useful example, not a measured reliability rate. Save a problematic reply alongside the exact input before changing the setup.

If something goes wrong

If Mira repeats the voice example, replace it with a different sample or shorten it. If she controls the traveler, look for conflicting agency instructions in ED, Custom Instructions, Scenario, and earlier messages. Change one cause, then repeat the same test. If she becomes rigid, add a practical alternative she can offer instead of another prohibition.

Next: Scenarios, greetings, and worldbuilding.

Optional non-graphic voice and pacing

Use the voice, pacing and consent module for a non-graphic adult-intimacy writing preference. Its copyable block belongs in the intended chat Custom Instructions scope; preserve the character's own established voice and leave the user's choices open.

Lesson 09

Scenarios greetings and worldbuilding

Tutorial index

What you will make

You will open an archival-delivery story without deciding its outcome. A Scenario describes the starting situation. A Greeting is the character's opening message. Worldbuilding supplies setting facts that affect choices. An NPC, or non-player character, is a supporting person portrayed by the model. State is what is currently true, such as the parcel's location; it differs from a permanent world rule.

You will use Mira, a 30-year-old adult archivist with a precise, patient manner and dry humor; Rowan, a 32-year-old adult courier who is practical and informal; and yourself as an adult traveler.

Before you start

Open an editable practice character. Keep Mira's personality from Tutorial 08. Additional Personality Details (APD) is the personality field; Extra Details (ED) holds supporting lore and rules. The field guide distinguishes these jobs from Scenario and Greeting. The examples below are compact exercises; expand meaningful content if the current editor requires more for publication.

Optional planning check: promise, access, and launch

An October 31 adaptation of the supplied Scenario Engineering guide adds a useful local drafting check. Write the experience you intend to offer, why the traveler can meet Mira again, which records require permission, who knows the address problem, and what is happening at the exact opening. Leave later possibilities undecided. A recurring cast record gives Rowan a role; it does not establish his arrival or completed work outside the scene.

For this example, the traveler can use the public reading area and ask Mira for access to staff records. The traveler may compare addresses, wait, refuse delivery, or pursue a quiet map question. A deadline is optional; if used, it follows the accepted story time rather than advancing automatically after each reply. The scenario-planning module provides a local worksheet and a short Scenario payload. Its SCE headings are organizational labels, and its source's ADP spelling is normalized to the documented APD field. Keep ED available for relevant lore, cast, and rules as well as formatting.

Follow these steps

Choose one immediate problem. In your local notes, write: Can parcel A17 reach the records office before its delivery window closes? This is a question for play, not a promised ending. Leave room for a delay, a mistaken address, or a negotiated alternative.

Put the opening circumstances in Scenario. Use Mira's character editor and find the field explicitly labelled Scenario. Replace a conflicting old opening with this text. The October 2 update restored one private Scenario field and removed multi-scenario controls; do not search for a separate scenario stack to install this exercise:

Late afternoon at the public archive. Mira is checking outgoing records.
The adult traveler is invited to help deliver sealed parcel A17.
Rowan, an adult courier, is expected but has not arrived.
The records office can accept A17 today if delivery is completed in time.
No one has accepted the parcel or signed a receipt yet.
Begin before the traveler decides whether to help.

Add only the world rules the opening needs. In Extra Details, retain the behavior rules from Tutorial 08 and add this separate section once:

WORLD FACTS
The archive and records office are separate public buildings.
A17 is a sealed records parcel, not a weapon or a living creature.
The records clerk issues receipt R-A17 only after accepting A17.
A delivery attempt is not an accepted delivery.
Rowan knows courier routes but has not heard this conversation.
New consequential world facts should remain consistent after introduction.

Write a playable Greeting. Put this in Greeting:

Mira straightens a curling label beside the sealed parcel.
"A17. One destination, two contradictory street names. Efficient."
She turns the address card toward you.
"Would you rather check the register with me or wait for Rowan's route advice?"

This establishes an object and a choice. It does not make you pick up the parcel, feel anxious, or agree to the job. You may also refuse both suggestions.

Make the reader-facing introduction honest. If you are also editing Public Description, use a brief invitation such as: Help a patient archivist and an informal courier untangle a records delivery. Choose your approach; a successful handover is earned during play. Keep essential model instructions in their actual fields rather than relying on this introduction.
Save and inspect the opening in a practice chat. Read the displayed Greeting. Confirm that A17 remains sealed, Rowan is absent, and the job has not already succeeded. If the old Greeting appears, check whether you reopened an existing conversation rather than starting the intended test.
Try an unexpected but reasonable action. Send: I decline the delivery but offer to compare the two addresses. Mira should have a way to continue without forcing you into courier work. Your refusal should change the scene's options, not automatically end every possible story.
Introduce Rowan deliberately. When you want him to arrive in a single-narrator story, send: Rowan arrives at the archive door. I ask him which street name is current. His answer can use his route knowledge. He should learn details of the parcel from the current scene, rather than inheriting every private exchange with Mira.

Keep calm scenes distinct from stalled scenes

A quiet conversation, reading, rest, or shared task can remain meaningful. A short user reply is not itself a stall. A stalled scene repeats an exhausted exchange without useful change; it does not automatically require a stranger, accident, confession, or new deadline. See the scene-motion module.

For a focused trial, merge these lines into the existing ED continuation rules once, or use the chat's Custom Instructions for that trial:

Allow calm or slow scenes without compulsory escalation.
If an exchange genuinely repeats without useful change, pursue one plausible
existing task, question, obligation, or consequence; otherwise allow a pause.
Preserve accepted scene facts and stop before the player's unprovided choice.

In the archive, Mira can consult an available record while you read. She does not need to invent a crisis. If you decline delivery, the address question can remain open without forcing you onto the road. A journey's start is not arrival, a message is not physical presence, and offscreen plans are not completed background work. Carry forward relevant locations, object possession, knowledge, and consequences. Unknown state stays unknown until established or explicitly recovered.

Separate an opening fact from a continuing rule

In this original drafting check, classify each line before copying it:

Line	Intended destination and lifetime
`Rowan has not arrived at the opening.`	Scenario: the starting situation; revise continuing notes after his arrival
`Mira checks uncertain records before confirming them.`	APD: a stable way she behaves
`Leave the traveler's next decision open.`	The one maintained ED or chat Custom Instructions behavior block
`Rowan arrives at the door now.`	A deliberate current event; use available temporary direction when appropriate

Do not turn the opening into Rowan never arrives, or leave his first arrival as a recurring instruction. The instructions guide distinguishes temporary events from persistent behavior. After the scene changes, inspect its accepted facts instead of repeating the original opening. The OD prompt lab expands this placement exercise.

Checkpoint

The opening should answer where you are, who is present, what remains unresolved, and how you can participate. It should still support a quiet conversation about old maps. You do not need to add points or combat simply because the story has a goal.

If something goes wrong

If the story repeatedly restarts, check for an arrival instruction left in a persistent field. If it invents a whole city unnecessarily, reduce lore to facts that affect the next choice. If Rowan knows everything, state what he actually witnessed and correct the mistaken event before continuing. For a later scene, update the current situation rather than stacking several incompatible openings.

Next: Group chats.

Lesson 10

Group chats

Tutorial index

What you will make

You will create a conversation with Mira and Rowan as separate respondents. A native group chat contains separately selected character cards. A narrated ensemble is one character or narrator portraying several people in its replies. An NPC, or non-player character, is a fictional person portrayed by the model. A respondent is the character chosen to answer the next message; that choice alone does not place them in the fictional room.

Our cast is Mira, a 30-year-old adult archivist who is precise, patient, and dryly humorous; Rowan, a 32-year-old adult courier who is practical and informal; and you, an adult traveler.

Before you start

Have both character cards available. If you only have Mira, repeat Create your first character for Rowan: age 32, adult man, courier, light skin, freckles, green eyes, and short red hair. Keep the new card private. Additional Personality Details (APD) means the field describing behavior; Extra Details (ED) holds supporting rules and lore. Prepare Mira with Tutorial 08. Keep a copy of both cards. Group setup does not establish that their older private conversations will be available.

Follow these steps

Prepare Rowan's separate identity. Open Rowan's editor and put this original example in Additional Personality Details, replacing conflicting personality text:

Rowan is a 32-year-old courier. He is practical and informal.
He checks what can actually be carried, delivered, or repaired.
He calls a problem by its ordinary name and suggests a workable next step.
He respects Mira's recordkeeping but jokes about slow paperwork.
He knows local courier routes, not private conversations he did not hear.
Voice example: "Fine. Show me the address and the awkward bit."

Open the group creator. Visit Create A Scenario in your account. The public page displays Add Character and Create New Chat. Use Add Character to select Mira, then Rowan. Inspect the roster before creating the chat. If your account does not offer this workflow, use the single-narrator alternative below rather than assuming a normal chat has become a native group.

Establish the shared scene. If the group editor provides Premise or Private Details, put essential shared circumstances there. The Known State group-publishing guide states that individual character Scenarios are ignored inside a group chat. Put essential shared circumstances in the group fields even when they already appear on a character card. If those fields are unavailable in your practice setup, send the following as an ordinary chat setup message, not as a character's personality:

Begin a neutral archive-delivery story.
Present: Mira, Rowan, and me, an adult traveler, at the archive counter.
Parcel A17 is sealed and undelivered. No receipt has been issued.
Mira handles records; Rowan advises on courier routes.
Each keeps their own voice, knowledge, and goals.
Distinguish observed facts, received claims, and uncertain beliefs.
Select relevant speakers; no full-cast reaction or private-thought quota.
When a question needs my choice, stop before supplying my answer.
Leave my speech, decisions, and private feelings to me.
An attempted handover does not become a completed delivery without acceptance.

Choose Mira to answer. Before sending, click Mira's portrait, or type @ and select Mira from the displayed list. These controls are described in the Help Center's community-written group FAQ. It is a practical guide, not a guarantee that a particular account uses the same layout. Send: Mira, what must the clerk verify before accepting A17? Confirm that Mira answers the recordkeeping question. Typing a name in prose is not the same as selecting a respondent.
Choose Rowan for a different question. Select Rowan through the same control. Send: Rowan, which route would you recommend, and why? His reply should reflect practical route knowledge rather than imitate Mira's formal register checking. Disagreement about the best route can be useful; neither character must endorse your first suggestion.
Test individual knowledge. Send: Rowan steps outside to inspect his bicycle. While he is away, I tell Mira that the address card may be outdated. Choose Mira for that reply. Then choose Rowan and send: Rowan returns. I ask whether he has checked today's address card yet. He should not claim to remember the private exchange as something he heard. This is a narrative test, not a privacy barrier: all participants' text can remain in the group conversation.

Add a second check: send Rowan a message without a read confirmation. Record that it was sent; do not assume he read it. A reasonable guess about an outdated address can remain a labelled hypothesis. An audience-visible secret or another character's private thought is not his evidence.
Repair one concrete mistake. If Rowan borrows Mira's memory, send: Correction: Rowan was outside during that exchange. He knows the courier routes, but nobody has told him our concern about the card yet. Continue from his return. Then let Mira or you actually explain the concern. Do not keep several incompatible versions of the event in your maintained summary.
Try the alternative only if needed. For a narrated ensemble, open one narrator-led chat and provide both brief character records in its ED. Ask that one narrator to label speakers as Mira or Rowan. Do not add native-group portrait instructions to that format. It can tell a cast story without pretending to provide separate native respondents.

Checkpoint and troubleshooting

Confirm that the roster is correct, the intended portrait answers, voices remain distinct, and absent people do not acquire unexplained knowledge. If the wrong person answers, inspect the selection before rewriting personality. If both sound alike, shorten overlapping traits and keep one contrasting voice example each. If a scene becomes crowded, reduce the present cast.

Write an exchange with named actors

When they know the new address is ambiguous, write the event that supplied the knowledge. For this original chat correction, use it only if the exchange actually occurred:

Mira checked the register and told Alex the eastern address.
Rowan was outside during that exchange. When he returns, Mira can explain
the correction; until that explanation, he has only his earlier route advice.

Check an ordinary question to Rowan before and after he is told. Keep the present cast and selected respondent fixed for the comparison. Do not test only with a question that contains the correct address. The wording distinguishes story knowledge; it does not conceal group text from the model. Use the OD prompt lab to compare a broad rule with a specific one.

Questions, time, and checkpoints

If Rowan asks which route you choose, inspect the rest of the reply: it should not decide your answer, depart for you, or skip to a later outcome. Other people may stay silent; presence is not a POV quota. Native respondent selection and an NPC's fictional opportunity to speak are different controls.

A generated label such as Next: Rowan describes a proposed story handoff. Treat it as a cue to check the selected respondent before sending your next message. The label is not confirmation that Rowan's portrait or @ entry is selected. Keep the fictional turn owner and the selected native respondent as separate entries in your checkpoint.

Record GR02 (shared scenario) and GR03 (handoff cue versus UI respondent) in the Native creator test log. For GR02, compare replies with the group setup when individual cards have different Scenarios. For GR03, check the selected UI respondent separately from the fictional next owner. Save the model and settings, exact setup and prompts, respondent selection, generated cue, and actual replies. Keep planned expectations separate from observed output; leave each case not_run until you perform it in your account.

If you adopt a clock, count a shared interval once. Mira checking the register and Rowan checking his bicycle during the same five minutes do not create ten minutes merely because both are narrated. Without a chosen timing rule, keep time qualitative rather than inventing arithmetic.

Keep a short checkpoint of who is present, each person's actual knowledge, important object custody, accepted incident IDs, and open choices. None of these examples establishes private storage or automatic offscreen simulation. Try the knowledge/evidence cases; they remain proposed tests until you save actual outputs.

Next: RPGs.

Lesson 11

A tiny RPG

Tutorial index

What you will make

An RPG, or role-playing game, combines fictional choices with agreed rules and consequences. State is the current inventory, location, and other changing facts. A check resolves an uncertain action. An NPC, or non-player character, is someone the model portrays. An incident is one accepted story event, even when retold. EXP means experience points; this exercise uses none. A quiet conversation does not need to become a game.

You will help Mira, a 30-year-old adult archivist who is precise, patient, and dryly humorous, and Rowan, a 32-year-old adult courier who is practical and informal, deliver A17. You are an adult traveler. Neither success nor failure is predetermined.

Before you start

Use one narrator-led practice chat with the cast from Tutorial 09. This avoids learning group routing and game rules simultaneously. Extra Details (ED) is the character-editor field for supporting rules. Additional Personality Details (APD) holds personality; keep Mira's existing APD rather than replacing it with game mechanics. The systems guide documents optional progression and native State Trackers.

Follow these steps

Choose how uncertainty will be resolved. For this exercise, roll a physical six-sided die outside OD when a check is needed. Tell the chat the result. This is your external method, not an OD dice feature. If you prefer freeform storytelling, agree on outcomes in conversation and omit the numerical rules.

Add one small written rules module. In Mira's ED, append this original module once beneath the existing story rules. Remove conflicting mechanics from older engines. This is narrative guidance, not installed game software.

ARCHIVE DELIVERY GAME
Goal: the records clerk accepts sealed parcel A17 and issues receipt R-A17.
Start: Time 3; A17 at the archive; no receipt.
Time means remaining delivery opportunities, not real minutes.
Ordinary questions, planning, and quiet social conversation cost no Time.
Before a risky route action, state its stakes and ask the traveler to choose.
A chosen risky route attempt requires Time above 0.
Resolve its outcome, then subtract 1 Time, whether it succeeds or fails.
Attach that cost to one accepted incident ID; retelling it adds no new cost.
Plans, quoted examples, and hypothetical attempts are not completed attempts.
The user supplies an external six-sided die result: 4-6 succeeds; 1-3 fails.
Do not invent a roll or repeat a check merely to force success.
At Time 0, allow no new route attempts. If already at the office,
finish the pending handover; otherwise store A17 safely for tomorrow.
A final route success permits a handover, not automatic acceptance.
NPCs retain their own goals. Never choose the traveler's action or feelings.

Agree on the starting state in chat. Send: Use the archive delivery game. Starting Time is 3, A17 is sealed at the archive, and no receipt exists. I will supply external die results. Explain a check's stakes before I choose an action. Confirm the reply matches before beginning.
Play a quiet turn first. Send: Before we leave, I ask Mira why she became an archivist. She can tell a story, decline, or ask about you. Time should remain 3. Her answer need not become a reward, a new skill, or an automatic relationship increase.
Make a consequential choice. First establish who carries A17 and who joins the journey; ask rather than assuming Mira and Rowan accompany you. Then send: What would be at stake if I tried the narrow canal shortcut? An illustrative explanation is: success reaches the office approach; failure returns you to the junction; either attempt costs one Time. You can reject those stakes and take another approach. The narrator should not roll or move you before you decide.
Resolve an attempted action. Suppose you choose the shortcut and your real die shows 2. Send: I attempt the shortcut. My external die result is 2. A possible worked outcome is:
```
The footbridge is blocked by repair equipment.
Rowan points back toward the junction. "Long way, then."
Time: 2. A17 remains sealed with the traveler. No receipt.
Mira studies the map. "Its confidence exceeded its accuracy."
```
This example assumes you chose to carry A17 and Mira and Rowan joined the journey. Otherwise preserve the established parcel location and present cast. The failed route should change your available choices; it should not award the delivery.
Require an actual ending event. Reaching the office is not acceptance. Play the handover and any clerk questions. Read the accepted NPC reply before updating the final checkpoint: an offer can become acceptance only in that reply. Count the delivery only when A17 is accepted and R-A17 is issued. Record that incident identity once, so retelling, quoting, or regenerating the same accepted incident cannot earn it twice. A genuinely new attempt needs its own identity.

If you use the companion's coded local ledger, record the route cost under a stable ID such as A17-route-01/cost. Its roll record records dice only; it does not automatically spend Time, transfer ownership, or update native trackers.
Write a resume point. Save current Time and its units, parcel identity/holder/location/condition, actual cast, receipt and already-counted incident IDs, individual knowledge, relevant permissions, and the open choice. Keep required unknowns explicit. If using native trackers, follow Tutorial 13 and inspect their actual values. A local ledger backup preserves its own events; keep the narrative checkpoint too, because item names and a count do not retain everyone's knowledge.

Checkpoint and troubleshooting

Test a failed attempt, a successful attempt, and a social turn. Verify the arithmetic and parcel location yourself. If every action succeeds, restate the agreed failure consequence rather than adding harsher adjectives. If the story charges for conversation, correct Time to the last confirmed value. If a regenerated reply changes an outcome, choose the accepted version and reconcile state before continuing.

Read a game rule as a condition and consequence

Before adding stronger words such as always or absolute, identify the event that permits a change. In this exercise, planning a shortcut is different from choosing and resolving its risky attempt. The stated consequence is one Time cost attached to that accepted attempt, not a cost for every mention of the route.

Try these original inputs from separately restored starting states: What if we used the shortcut?, I decline that route, and I attempt it; my external roll is 2. Save the actual reply and Time for each. The first two target no change; the last targets the agreed failure and one cost. These are proposed cases. The OD prompt lab shows how to write and compare similarly scoped rules.

Check the last-opportunity boundary

In a separate practice run, explicitly start with Time 1 and an undelivered A17. A chosen route attempt must resolve before Time becomes 0. If it succeeds and reaches the office, the clerk can still accept or reject the handover; a receipt is not automatic. If it fails short of the office, no new route attempt is allowed until a deliberately established next-day reset. A question or refusal at Time 0 costs nothing. Record each result as observed rather than treating this rule text as an executable timer.

One interval, one accepted timeline

Printing Mira's and Rowan's activities does not itself spend two opportunities or add their simultaneous durations. If both act during the same five-minute interval, a separate story clock advances five minutes; sequential activities require a different explicit rule. Offscreen plans do not run a background process.

After edits or regeneration, choose which outcome is accepted and reconcile affected records. Preserve unrelated events and the selected Persona (user identity profile); local undo is not an OD rollback. Use the checkpoint audit to identify missing state before resuming.

Next: Memory and continuity.

Lesson 12

Memory and continuity

Tutorial index

What you will make

You will maintain a short, accurate record of an ongoing story. Continuity means later replies respect established events. State means changing facts, such as where A17 is now. Memory means context supplied to help the model continue; it is guidance, not an exact database.

The native layers have different jobs: Auto Memory Log summarizes history; Pinned Memories preserves selected continuing facts; Custom Instructions describes response behavior; Persona describes the user. The memory guide documents these layers. A summary does not guarantee flawless recall or make every fictional character know its contents.

Before you start

Use a practice chat with Mira, a 30-year-old adult archivist who is precise, patient, and dryly humorous, and Rowan, a 32-year-old adult courier who is practical and informal. You are an adult traveler. Have your last accepted scene and a local notes file open. Do not manufacture completed events just to make a summary look complete.

Follow these steps

Confirm a small scene to preserve. For a fresh exercise, send this as a chat setup message:

Practice continuity scene: late afternoon at the archive.
A17 is sealed on the counter, and no delivery receipt exists.
Mira and I checked the register and confirmed the eastern records office.
Rowan is outside checking his bicycle and has not been told the corrected destination.
My next choice is how to tell Rowan and arrange the delivery.

This explicitly establishes an agreed starting premise. In an existing story, substitute what actually happened rather than overwriting its history with the fixture.

Inspect Auto Memory Log. Open Chat settings → Memory, the path documented in the memory guide. The guide, last modified July 27, 2026, says the log normally regenerates after approximately 20 AI messages. Check its displayed update progress instead of treating this as an exact timer or recall guarantee. Read the current summary if available. Look for invented delivery completion, an incorrect destination, or unexplained shared knowledge. An empty or older log does not establish that the latest event has been retained.
Correct the story before refreshing its summary. If the log or a reply says the parcel was delivered, send: Correction: A17 is still sealed on the archive counter. No handover or receipt has occurred. Continue from that state. The documented memory controls let you force a regeneration, pause updates, or temporarily unlock the summary for editing; use the controls actually offered in your account. Preserve useful corrections locally before regenerating. The July 27 guide warns that later regeneration can replace manual summary edits. Regenerating a chat reply is a different operation. The October 2 update reports improved preservation during message edits, regeneration, and deletion, not a guarantee that every later summary keeps every manual change.
Create a compact pin. Locate Pinned Memories among the available memory controls; its exact placement may differ. The memory guide documents a 15,000-character capacity. Treat that as an allowance, not a target: keep the most consequential facts near the top and check your account's current limit. Do not copy the whole Auto Memory Log into the pin; independently maintained summaries can disagree. Enter this only if it matches the accepted scene:
```
REVISION: archive-practice-01; before delivery.
CURRENT DELIVERY
Destination: eastern records office, checked in the register by Mira and traveler.
A17: sealed; on archive counter; holder not yet assigned.
Access: address card readable; sealed contents not inspected.
Receipt R-A17: not issued. Counted receipt IDs: none.

KNOWLEDGE
Mira/traveler know the destination from the register check.
Rowan is outside and has not been told; no confirmed read message.

OPEN CHOICE
How to inform Rowan and arrange the delivery.
```
This is a small maintained reference, not a second transcript. Remove the Rowan knowledge line after he is actually informed, and update the parcel location when it changes.
Keep response rules in Custom Instructions. If you need a persistent writing rule, put this in the field labelled Custom Instructions: Leave my decisions and private feelings to me. Distinguish proposals from completed actions. Do not add it again if an equivalent instruction already covers the chat. The instructions guide distinguishes user identity from response behavior.
Check the selected Persona. A Persona describes you, the adult traveler; it does not automatically grant Mira your private history or report a completed quest. Preserve supplied identity facts. Correcting the parcel's location does not authorize clearing Persona, deleting unrelated memories, or resetting the entire story. If two records genuinely conflict, identify the disputed fact and choose a narrow correction.
Test recall through ordinary play. Send: Before Rowan returns, I ask Mira where A17 is and what we still need to do. Check that the answer keeps A17 at the counter and delivery unfinished. Then bring Rowan back and explicitly tell him the eastern destination. Update the pin's knowledge section after that exchange.
Save a resume point locally. Retain location/time, actual cast/channels, object identity/custody/condition/access, resources and units if used, individual knowledge and sources, relevant permissions, counted incident IDs, and the next choice. In another chat, supply the available checkpoint explicitly. A local companion backup preserves its coded ledger separately; neither an evocative summary nor a delivery count restores omitted identities. Mark required missing facts as unknown and recover them before relying on duplicate prevention.

Separate recall, an unsolicited callback, and a reminder

The ordinary question in step 7 tests prompted recall: can the reply use the accepted facts when asked? A character mentioning an earlier event without being asked is an unsolicited callback. A scheduled notification or reminder outside the conversation would be a separate product capability. The dated memory guide does not establish that capability here.

A November 2 caption review of AI Companion Mag's October 23 short found a proposed future-event check at 0:00–0:16, followed by a pending score. That is a creator's test proposal, not an observed memory result. Waiting for a spontaneous mention tests initiative and timing as well as retained context. Absence of a callback does not by itself isolate a recall failure.

If you manually try that optional comparison, define the expected event, whether its time belongs to the story or the real calendar, the exact trigger and observation window, and what counts as a callback before starting. Retain the intervening conversation and available memory/settings. Grade an ordinary recall question separately. This proposed comparison remains not_run; no scheduler, notification feature or successful outcome is claimed. The video questions review keeps the creator context separate from platform evidence.

Replace a stale state instead of adding a competing version

After an accepted handover, A17 is still on the archive counter is obsolete. Update that maintained state line; do not append A17 was delivered underneath it and expect the model to choose. This original memory-editing example applies only after the recorded acceptance:

CURRENT DELIVERY — after accepted handover
The clerk holds A17 at the eastern records office and issued R-A17.
The delivery is complete; R-A17 has already been counted once.
Next unresolved choice: what the traveler does next.

Preserve the earlier history in your local record. The current-state pin should identify the accepted result, while the Auto Memory Log can summarize how it happened. The memory guide warns against conflicting copies and completed plans left active. Ask an ordinary question about what remains to do, with no receipt details supplied in the question, before trying an explicit correction. See the OD prompt lab.

Checkpoint and troubleshooting

Compare the reply, pin, and actual accepted events. They should agree. There is no need to wait an exact number of turns before checking.

If a fact keeps drifting, shorten it and remove conflicting copies before adding more repetition. If play loops, remove a completed plan still pinned as pending. If you edited or regenerated an earlier event, reconcile later summaries and counters before continuing. Keep unknown facts marked unknown.

Before resuming, read the final accepted reply as well as your input. If the clerk issued R-A17 in that reply, the checkpoint must include it; an earlier offer-only summary is now obsolete. Choose the accepted timeline after regeneration and reconcile its consequences explicitly. Do not invent a receipt or silently restore a supposed earlier state to make records agree. The checkpoint audit gives a complete neutral example and proposed omission tests.

Record a memory refresh

Use the native creator test worksheet for MEM01 and MEM02. Both cases start as not_run; these are proposed checks, not recorded results.

MEM01 — regeneration and recall. Save the accepted reply that establishes A17's location, receipt status, and who knows its destination. Record the current Auto Memory Log, Pinned Memories, visible model/settings, and displayed update progress. Use the available memory-regeneration control, save the resulting log, then ask the ordinary recall question in step 7. Record summary accuracy and reply accuracy separately; do not supply the expected facts in the recall question.
MEM02 — manual summary edit. From a saved accepted scene, make one accurate, narrow summary correction and save its exact text locally. Observe what happens after a later actual memory regeneration. Record the before/after summary and whether the correction survived or was replaced; do not assume manual edits are permanent.

Keep the exact submitted input and complete observed reply with each trial. Leave a case not_run until output exists; use blocked when the required control is absent and inconclusive when the record cannot establish the outcome. A correct summary and a correct next reply are separate observations.

Next: State Trackers.

Lesson 13

State Trackers

Tutorial index

What you will make

A State Tracker is a native field for changing story information. A counter holds a number. An initial value is its starting value. An update rule explains what should change it. A no-change condition explains when it must stay still. A receipt ID identifies a particular receipt so mentioning it again is not another delivery.

You will track one completed delivery: parcel A17, receipt R-A17. Mira is a 30-year-old adult archivist: precise, patient, and dryly humorous. Rowan is a 32-year-old adult courier: practical and informal. You are an adult traveler. The tracker records an event; it does not decide your actions.

Before you start

Use an editable practice character and a test conversation. Extra Details (ED) holds supporting story rules; Additional Personality Details (APD) holds personality. Keep the personalities already prepared.

Native trackers are described in the progression guide. Availability and visible controls can vary. This tutorial configures the UI manually; it supplies no native import JSON or hidden-state code.

Follow these steps

Locate the native control. In the character editor, try Details → Advanced Details → State Trackers, when visible. This path appears in the owned creator walkthrough. Expand Advanced Details if collapsed. If the control is unavailable, stop the native setup and use a clearly labelled manual note. Pasting a tracker-looking block into ED does not create a native tracker.
Create one practice counter. Use the visible add/custom control. Choose the counter or numeric type actually offered. Label it Accepted deliveries and set its initial value to 0. If bounds are offered, use minimum 0 and maximum 2 during this test. Correct behavior still never exceeds 1; the extra room lets you notice accidental double counting instead of hiding it behind a cap of 1. Do not invent missing settings or substitute an unrelated preset.

Enter its update guidance. Put the following original text in that tracker's update rules/guidance field, using the label your interface provides:

This exercise has one parcel, A17, and one possible receipt, R-A17.
Begin at 0.
Change to 1 only when the records clerk has actually accepted A17
and issued receipt R-A17 in the completed scene.
Stay at 0 for plans, attempted handovers, rejected deliveries,
questions, hypothetical examples, or mentions of a future receipt.
After reaching 1, remain at 1 when R-A17 is mentioned, shown, or retold.
No second receipt is created by retelling, quoting, or regenerating the same accepted incident.
A changed message ID does not itself mean a new delivery.
If completion is unclear, keep the current value and seek clarification.

Set the story consequence separately. In ED, add this once: After A17 is accepted and R-A17 is issued, Mira can acknowledge the completed delivery and discuss a new task. Before that event, keep delivery unresolved. A counter alone does not supply missing scene details. Keep receipt identity in your local event notes. A value of 1 alone does not retain which receipt was counted. Do not assume one tracker can automatically read or coordinate with another. Stale state is not permission to invent an event to make it catch up.
Save and inspect the starting state. Open a fresh practice chat where A17 is still at the archive and no receipt exists. Inspect Accepted deliveries before sending anything. If the initial value is not 0, correct the test setup using controls actually available, or restart the practice instance. Do not present this as a successful initial-value test.
Run two no-change tests. Send: I plan to deliver A17 later. What will the clerk need? Inspect the value after the response. It should stay 0. Then send: Suppose I received R-A17 tomorrow; would that complete the job? Inspect again. A hypothetical receipt is not a completed event. If either test increments the counter, save the failing input and simplify its guidance.
Complete one delivery in the fiction. Play the journey and handover. At the clerk, send: I offer the sealed A17 parcel for inspection and wait for the clerk's decision. This remains an attempt. Only after a reply actually accepts it and issues R-A17 should the target value become 1. Inspect the displayed update after the accepted reply, then reconcile the checkpoint. Do not assume a particular update order. A copied configuration example does not verify your current controls or their behavior. Record both the displayed value and what the reply says: a correct display with stale narrative behavior is a different failure from a counter that never updated.
Test duplicate prevention. Once R-A17 has been issued, send: I show Mira the same receipt R-A17 and describe that delivery again. The counter should remain 1. Record the input, reply, and displayed value. A fresh, differently identified delivery would require a deliberately expanded configuration, not this one-event fixture.

Keep rule wording separate from the observed value

For a proposed wording comparison, replace vague guidance such as track deliveries accurately with the concrete acceptance condition from step 3. Save the initial display, exact input, accepted response, and updated display for both versions. Use matched fresh practice setups; a later successful scene is not a fair comparison with an earlier plan-only scene.

A response saying the tracker is fixed is narration. It does not establish that the stored value changed. Likewise, the numeral alone cannot show whether the reply invented an acceptance event. Inspect both observations and keep their verdicts separate. The OD prompt lab includes a condition-and-fallback drafting exercise; it supplies no native tracker schema or update-order guarantee.

Record the native value and the story separately

Use the shared native creator test worksheet. Start each case as planned / not run and leave observed results blank until you inspect the actual chat. Keep one counter and this same parcel/receipt fixture; for a wording comparison, change only the update guidance in matched fresh setups.

Case	Expected native display	Separate story criterion
ST01 — plan/attempt versus completion	Stay at 0 for the plan, hypothetical, and unaccepted offer; become 1 only after actual acceptance and receipt issuance.	No acceptance or receipt is invented to satisfy a counter. The retained scene establishes both before the delivery counts.
ST02 — retell the accepted event	Remain at 1 when the same R-A17 is shown, quoted, or retold.	The retelling refers to the existing delivery; it creates no new delivery or receipt.
ST03 — edit, regenerate, or delete	Record the before/after display; automatic rollback and update timing are not established.	Identify the retained event, then reconcile it with the display through supported controls without inventing a completion.

Run each ST03 action in a separate practice copy and change one action at a time. Save the exact input, retained reply reference, event identity, and displayed value. Assess the display and story criteria independently: a numeral written in a reply is not an observation of the native field. Preserve failures as evidence; a planned expectation is not a passing result.

Review a multi-field tracker before using it

After the one-delivery exercise works in your actual account, use the affection-tracker review to inspect a more complicated proposed design. A supplied JSON file can describe five fields without establishing that its schema imports or that the fields coordinate natively.

Write the evidence window first: the current user message and the complete accepted exchange are different inputs. Choose one signed raw adjustment per qualifying event, with zero valid. Profanity, routine politeness, brevity, a reasonable refusal, or a boundary should not determine the number by themselves. Keep the numeric display separate from what the story narrates.

A daily positive cap needs a defined day and a maintained gain budget; losses do not restore spent allowance. Distinguish the raw category from its applied capped or clamped change. Check a derived band's exact boundaries only after defining the intended final score. Do not assume native threshold order or automatic synchronization.

Keep physical presence separate from active phone contacts. Keep each outfit attached to its actor and latest established change; an NPC's offer does not establish the user's acceptance. Unknown clothing remains unspecified, and a word limit does not ensure a character limit. The module's worksheet stays in local notes; it is not a native import or a complete tracker payload. All of its proposed trials remain not run.

Checkpoint and troubleshooting

Your expected sequence is 0 → 0 → 0 → 1 → 1: start, plan, hypothetical, accepted delivery, retelling. These are targets to test, not results already obtained.

If a value changes incorrectly, compare the scene with the rule before continuing. Correct the accepted story and visible value through supported controls where available. If you cannot reconcile them, preserve the failure and start a fresh test. Editing or regenerating a completed turn can require another reconciliation. Do not promise automatic rollback, atomic updates, or perfect deduplication.

Keep a small incident record: R-A17 | accepted by clerk | receipt issued | counted once | accepted reply reference. When an earlier reply is edited or regenerated, identify the retained outcome before changing the value. A plain correction of a stored value is not a new fictional delivery. Preserve Persona (user identity profile) and unrelated history; use only the native controls actually available. Compare the checkpoint audit with your record. All examples here remain proposed criteria until tested in the actual chat.

Next: revisit Memory and continuity, or return to the Tutorial index.

Lesson 14

Set your Persona and Custom Instructions

You will tell the chat who you are playing, then give it a small set of writing instructions.

A Persona describes your role in the conversation. Custom Instructions describe how you want replies written. Mira's personality belongs in Mira's character definition; it does not belong in your Persona.

Before you begin

Have an account and a practice chat. Use a separate practice Persona if you already have one you want to preserve.

The Personas and instructions guide, last modified July 27 and re-read November 1, 2026, documents a Persona description allowance of 2,500 characters and a Custom Instructions allowance of 15,000 characters. Check the current field counter in your account. These are allowances, not writing targets or a specification of the model's total context; keep both fields focused rather than filling the available space.

Step by step

Open your profile settings. Find the Persona controls. Create a new Persona using the control available there, or edit the practice Persona you intend to use.
Give it a name. For this example, use Alex. Choose the other identity fields according to the role you want to play.
Enter a short description. Use the next box as the Persona description.

Alex is an adult traveler visiting the town archive for the first time.
Alex carries a worn satchel and is interested in old maps. Alex has no
established friendship with Mira and has not yet chosen how to investigate.

Save the Persona. Open the intended chat and select Alex using its Persona control. Creating a Persona and selecting it for a chat are separate actions. Reopen the selector to confirm the saved selection before testing; keep a copy of any existing Persona or instructions you replace.
Check image inclusion. If Include persona in images is offered, choose whether Alex's appearance should be included. Selecting that option can affect who appears in a requested scene; it does not turn the written Persona into a reference photograph.
Open the chat settings. Find Custom Instructions. Check whether the interface applies the text to this chat or a broader scope before replacing any existing instructions.
Add a small instruction set. Paste the next box into Custom Instructions, not into the Persona description.

Describe the environment and the AI characters' actions and dialogue.
Leave Alex's words, actions, decisions, and private thoughts to me.
Keep each character's knowledge separate.
End at a useful point for me to respond.

Test with a new message. Ask Mira: “What would you suggest I investigate first?” Look for an answer that offers a useful possibility without deciding that Alex accepts it.
Correct only the relevant layer. If the wrong person is being described, check Persona selection. If the AI is writing your choices, revise the behavioral instruction. If Mira has the wrong occupation, correct Mira's character fields.

The Known State Personas and instructions guide distinguishes user identity, persistent response rules, and temporary scene direction.

What belongs where

Information	Put it here
Alex's name and visible background	Persona
Leave Alex's decisions to the human	Custom Instructions
Mira is patient and checks sources	Mira's personality field
Mira learned Alex missed a train	Relevant chat memory
Rowan arrives in the next reply	Temporary direction

Use chat controls for temporary directions rather than keeping a one-time arrival in a persistent field.

Make one rule specific enough to inspect

For an original Custom Instructions practice revision, replace make this immersive with the behavior you actually want:

When Mira answers a practical question, address that question through her
dialogue or an observable action. Use details relevant to the archive scene.
If a fact is not established, leave it uncertain or ask for the missing fact.
Leave Alex's reply and next choice to me.

Keep only the parts your chat needs and reconcile equivalent rules already present. Try an ordinary catalog question, then an uncertain address question. Judge relevance, uncertainty, and user agency separately. The OD prompt lab explains how to compare a revision without changing the whole setup.

Request the chat language deliberately

OD's language help article, edited November 5, 2025 and read October 31, 2026, says a language request may take several prompts to take effect. This describes chat behavior; it does not establish equal fluency across languages or change the interface language.

For a continuing preference, try this original Custom Instructions example after saving the existing text:

Write dialogue and narration in Spanish. Keep the established names,
character roles, and story facts. Leave my actions and decisions to me.

Ask Mira, where should a visitor begin looking for a map? and inspect several ordinary replies. Record language use and preservation of facts separately. Remove an older conflicting language request before judging the result. If you want a single translated passage instead, request that passage in the current message rather than changing the whole character.

Check your result

Your selected Persona should match the role you want for this conversation. Mira should still have her own identity. Judge the actual replies: an instruction states the intended behavior but does not guarantee every response.

If something goes wrong

The AI uses a different name: inspect the selected Persona and old memory entries for conflicting names.
Every reply repeats an event: remove that event from persistent instructions and give it once as a scene direction.
The AI obeys one rule while breaking another: look for contradictions such as “never advance the scene” alongside “always introduce a new event.”

Next: Memory and continuity, or chat controls and slash commands.

Back to the tutorial index

Optional non-graphic dialogue guideline

The voice, pacing and consent module provides a downloadable text block and placement steps. Open the file and copy its contents into the intended chat's Custom Instructions. A supplied May 16, 2026 screenshot places this field under Memory; inspect the controls and Current Chat/Default scope actually shown in your account before saving. The four proposed checks have no recorded result for this module.

Lesson 15

Use chat controls and slash commands

You will adjust one chat setting, steer a single reply, and distinguish regeneration from a new story event.

A chat model is the system generating the written response. A slash command begins with / and requests a special chat action. Neither is the same as choosing an image style.

Before you begin

Open a practice conversation. Keep a copy of any important current state before changing the conversation history.

Adjust a setting

Open the chat settings. Locate the model selector and response controls available in your account.
Record the starting selection. Use the displayed model name and any per-message charge. Do not infer the underlying model from a nickname or another person's screenshot. Check the new selection's displayed cost before sending a paid test.
Leave most controls alone. Choose one problem you want to address.
Change one control. Use the table below to choose a relevant one.
Send a short test. For example: “Mira, explain the two most useful places to search for the map.”
Compare the response with your goal. If it does not help, return the setting to its previous value before trying another change.

Control	What to observe
Response Length	Whether the reply is brief enough, complete, and leaves room for you
Creativity	Whether additional variation helps or disrupts the established scene
Lust Level	How readily the chat adopts sexual tone; choose a lower setting for this archive exercise
Chat model	Whether the same character and instructions are handled usefully

The chat-controls guide describes these controls. Their names, ranges, and available models should be read from your own selector.

Public marketing pages and dated guide tables may list different model names. Use the actual selector for your account and route; do not turn either list into a universal ranking, infer backend identity, or invent controls that are absent. A saved test should identify the displayed model and date.

Compare wording separately from a model switch

Use this original two-stage practice plan. First save one short question and the complete relevant setup. Compare the baseline and one wording revision on the same selected model, restoring the scene and context for each trial. Then, if you want to compare models, keep the chosen wording unchanged and repeat through the actual selector. Check any new charge before sending.

Record the visible model label verbatim with the date. A guide's suggested use for a named model is not a measurement of your character or proof that the underlying provider stayed the same. A prose request such as use a smarter model is not a verified model-selection control. The chat-controls guide describes the actual selector and response settings; the OD prompt lab provides wording exercises.

Direct one reply

Click the message box and type /.
If a command menu appears, select /direct.
Enter the direction below and send it once.

/direct Rowan arrives at the archive carrying a sealed parcel.
Leave Alex's response to the user.

Read the next reply. Rowan's arrival should be the requested event; it should not become a repeated arrival in later replies.
If the menu does not offer the command, use the controls your chat actually exposes. Do not invent a new slash command and assume the site will execute it.

Ask for an analysis

Use /analyze, when offered, for an out-of-character answer without continuing the roleplay, as described in the command reference. Ask about the available context:

/analyze What does Mira currently know about the missing map,
and which questions are still unresolved?

Treat the answer as an interpretation of the context. Compare it with what actually happened rather than treating it as a database query or prediction. The guide describes slash commands as hidden from the story; that is not a privacy guarantee or a reason to put passwords or other secrets in them.

Expand a draft

With /suggest, when offered, supply the idea you want help expressing. Review the proposed wording before sending the resulting story message. For example, expand “Ask to inspect the catalog” without adding a decision to leave the archive. The same command reference explains the three commands.

Regenerate edit and continue

Regenerate asks for an alternative version of a reply. Review which version is retained; it should not automatically count as an additional completed game event.
Edit your message when you supplied a wrong fact or unclear action. After changing earlier history, check any affected memory and state.
Continue, if offered, requests further output. Inspect whether it continues the same moment or advances the fiction before using it in a game with counters.

These distinctions matter whenever RPG state depends on completed events.

Check your result

You should know which single setting changed and whether it helped. You should also be able to tell a temporary direction from a persistent instruction.

If something goes wrong

The reply is cut off: reduce the target length or request a continuation, then inspect the resulting state.
The story repeats itself: correct contradictory setup text before repeatedly regenerating.
A model switch changes behavior: rerun the same simple check; do not assume settings transfer their effects identically.

Back to the tutorial index

Lesson 16

Format dialogue actions and readable status text

You will write a message that separates dialogue from action and, if useful, add a simple readable status line.

Formatting changes how text is displayed. It does not create memory, run code, or give a paragraph special authority. Markdown is a family of text-markup conventions; support for one convention does not establish support for all of them.

Before you begin

Open a practice chat. Use a short message so you can see exactly which characters the renderer changes.

Step by step

Write ordinary dialogue first. In the message box, enter “May I see the catalog?” and send it. No special marks are required for ordinary conversation.
Add an action you choose. In the next message, place one asterisk before and after the action.
Keep dialogue outside that action. Copy the following example into the chat message box.

*I place my notebook on the desk.* May I copy the catalog number?

Inspect the displayed message. The documented convention treats the asterisk-wrapped portion as an action, often shown in yellow. The exact appearance depends on the surface and theme. Action formatting.
Check the raw text if the result is wrong. Make sure both asterisks are present and that the action did not accidentally include the dialogue.
Use ordinary line breaks for structure. A new paragraph can separate a description from a question without a complicated layout.
Add a plain status line only if the scenario needs it. Use the example below as text. It does not create a native tracker.

Location: Archive north desk
Present: Mira and Alex
Open question: Where was the map last seen?

Check the facts in the line. If Rowan has not arrived, do not list Rowan as present. Readability and factual correctness are separate checks.

Ask the AI for a modest format

If you want recurring speaker labels in a multi-character scene, open the practice chat's settings and paste this into Custom Instructions. See Personas and Custom Instructions if you need help finding that field.

Label each speaking character by name.
Use ordinary dialogue and short action descriptions.
Leave my dialogue and decisions to me.

For native group chat, the selected respondent is a separate control; a written name label does not select a different message box. See Group chats.

Try optional markup one item at a time

If you want bold text, a list, a heading, or a table, test one small sample in the actual surface you will use. Keep the literal input and a note or screenshot of its displayed result, including date, device, and surface (chat message or Greeting). A format that displays correctly in your message, a character greeting, or another application may display differently elsewhere.

For example, try a two-item ordinary list before designing a large status panel. If the marks remain visible or alignment breaks, use plain labels and paragraphs instead. Essential choices and state should remain readable without decorative layout.

Test the writing rule separately from its display

This original Custom Instructions example states a modest format and its meaning:

Use a speaker's name when more than one AI character speaks in a reply.
Separate a change of speaker with a line break.
Keep each action attached to its actual actor; leave the traveler's actions
and choices to the user. A label does not add a native respondent or a turn.

First inspect who actually speaks and acts. Then inspect whether labels and line breaks display clearly. A well-rendered Rowan: label can still introduce an absent Rowan incorrectly. Keep the same scene when testing a format change so a new cast or event does not become a second variable. Use the OD prompt lab to separate wording, scene facts, and acceptance checks.

A thought label is not a private channel

Text you include as an unspoken thought is still available to the model reading the message. A visual style or a label alone does not separate narrator information from a character's knowledge. If this distinction matters in your scene, trial an explicit instruction in the one maintained ED or Custom Instructions location:

Keep narrator context separate from each character's acquired knowledge.
An unspoken thought is not something another character heard.
Characters may infer from observable behavior, but distinguish an inference
from a known fact. Leave the user's thoughts and choices to the user.

For an original test, supply narrator context that the traveler privately suspects a copied address, then ask Mira aloud whether the address is readable. Inspect whether she answers the visible question or claims to know the undisclosed suspicion. Record the starting facts and actual reply. This is an authored knowledge-separation exercise, not a guaranteed privacy mechanism or a native command. It follows the knowledge-and-evidence module.

Check your result

A reader should be able to tell who spoke, what action occurred, and what question remains. A long box or colorful panel is optional. A footer is useful only when its values are correct and the scenario needs them.

If something goes wrong

Asterisks remain visible: check paired characters and test a minimal action alone.
Copied italics lose their marks: rich-text italics and literal asterisk characters are different. Copy from the plain-text example.
A table or code block is unreadable: replace it with short labelled lines.
A hidden comment contains important state: move those facts into a supported memory or tracker mechanism. A hidden-looking comment is not a dependable private save.

Next: State Trackers for actual counters, or testing for a repeatable format check.

Back to the tutorial index

Lesson 17

Import a character card

You will bring a character definition into OD through its dedicated importer, inspect the result, and keep the first version private.

A character card is a portable character definition. A JSON file stores structured text. A PNG card can store a picture together with embedded character text, called metadata. An ordinary picture without that character metadata is not the same thing as a card.

Before you begin

Have an account and a compatible card you want to use. Keep the original file. If you want a neutral practice file, use the included Mira practice card. It contains fictional tutorial content in a portable V2-style JSON structure, not an imported or tested account character. A JSON file can parse correctly and still use a schema or field the current importer does not support.

Step by step

Read the definition first. Check the name, adult age, appearance, personality, opening situation, and any included instructions. Make sure they describe the character you intend to use.
Open the actual importer. Visit Character Card Importer after completing the site's own sign-in and entry steps.
Choose Browse Files. Alternatively, use the drag-and-drop area if it is available.
Select the PNG card or JSON file. Do not rename an ordinary photograph or a text document and assume that makes it a compatible card.
Read the import response. If the site rejects the format, keep the error text. Repeatedly submitting the same incompatible file is unlikely to fix its structure.
Inspect the populated editor or preview. Compare its name, age, appearance, personality, Scenario, and Greeting against the source.
Resolve missing or changed fields. Use the field map to place important facts manually where necessary. Do not assume every source field has a one-to-one destination.
Inspect the generated display image. The public importer says it uses card metadata and generates a new display picture. The uploaded card picture is not used as the visual reference. Importer description.
Keep the first version private. Review any displayed cost before completing the flow. Do not publish an imported character simply to see whether it works.
Begin a short test chat. Ask a question that checks one important fact, then check the opening tone and user agency.

A simple mapping check

For the practice card, ask:

Mira, what work do you do here, and what is the problem we are starting with?

Compare the answer with the original card: Mira is an archivist, and the map is missing. Then check the appearance independently. A correct occupation does not establish that the hair or face was preserved.

Keep a short comparison before correcting any imported fields:

Source item	Inspect in the imported result	Record
Name, adult age, occupation	Corresponding editor fields and definition	Unchanged / changed / missing
Personality and scenario	Narrative fields, then a separate chat trial	Field transfer and behavior as separate verdicts
Opening message	Greeting text actually stored	Unchanged / changed / missing
Appearance description	Physical fields, then generated display image	Text transfer and visible identity separately

This table is a verification worksheet, not a claim about the importer's field mapping. Record a missing field rather than inferring transfer from a plausible reply.

What import acceptance does not prove

A successful upload means the importer accepted the file. It does not by itself show that every rule, lorebook trigger, alternate greeting, extension, or embedded asset behaves as it did in another application. A lorebook is a collection of reference entries; its portable format and its use during a conversation are separate questions.

Likewise, imported JSON does not become executable game code. Native State Trackers use their own available controls.

Adapt imported instructions by purpose

After recording the import comparison, make a separate authoring revision if source wording does not suit the destination. For example, identify whether I speak in terse sentences describes the character's written voice or is literal Greeting dialogue. A personality note can be clarified as Mira usually answers in brief, precise sentences in APD; the Greeting should keep the voice you deliberately chose for its first message.

Do not automatically convert every first-person sentence or relocate every source instruction. Preserve the intended facts, remove contradictory copies, and inspect what is actually stored before testing behavior. The OD writing guide explains field purposes and perspective; it does not establish that a foreign card's extensions acquire native behavior. The OD prompt lab offers placement practice.

Check your result

Keep the original card, a note of any important changes, and the private OD result. You should know which fields transferred and which you corrected. Only call the process an import comparison unless you have also verified an export path.

If something goes wrong

The file is rejected: confirm it is an actual compatible PNG card or valid JSON file; preserve the error.
The picture changes: review the generated appearance and tune it through CPD.
The character behaves differently: compare the populated narrative fields rather than assuming all source instructions survived.

Next: Test the character.

Back to the tutorial index

Lesson 18

Build a useful gallery and reuse good images

A gallery introduces a character through pictures. Image reuse gives you dependable starting material for later work. This lesson organizes Mira's images without confusing a display choice with a permanent appearance change.

Mira is the fictional 30-year-old adult archivist from earlier lessons. A scene is one pictured situation. An image model is the selected generator. A preset supplies a reusable instruction; a saved picture is different because it contains actual visual information.

1 Find your accepted images

Open Mira's generated-image collection. Choose pictures you have inspected, rather than every attractive result. Start with the navy-jacket archive image and any successful edit from the editing lesson.

Give each saved copy a useful name in your own notes. For example:

Mira_archive_navy_base
Mira_archive_green_jacket_edit
Mira_archive_watercolor_comparison

These are suggested filenames, not OD commands. Record the actual image identifiers when available.

For each picture, ask whether it still shows Mira's warm brown skin, brown eyes, black shoulder-length braids, and lean build. An image that drifts should not silently redefine her.

2 Recover the prompt before reusing it

Open an accepted image and look for Remix or More → Details, where available, to inspect its generation prompt. Save the image and prompt together. The Known State guide recommends this pairing for reuse. Image reuse

Add the actual model, date, and settings you can see. If the complete input is not exposed, write “effective prompt unavailable”; do not fill the gap from memory.

Copied prompt text can start a new generation. Selecting the original picture in Edit supplies a different kind of input. Choose the route that matches your goal.

3 Plan different jobs for your display pictures

Use this original four-picture plan as a starting exercise:

Picture	What it demonstrates
Clear waist-up portrait	Mira is recognizable at a small size
Wider archive scene	Her surroundings make visual sense
Examining a closed folder	A simple action connects her to her work
Meeting Rowan	The scene distinguishes two different adults

Rowan is a fictional 32-year-old adult courier with light skin, green eyes, short red hair, and freckles. Use a separate appearance clause for him; do not copy his features into Mira.

The plan is not a requirement to create four paid images immediately. Reuse suitable accepted pictures and fill only the gaps that matter.

4 Open Display Media

Open Mira's character editor. Locate Character Studio → Profile → Display Media if those labels appear. The Known State gallery guide describes this location, the first item as the cover, and up to four display items. Follow the slots actually shown in your account. Gallery controls

Add or replace an item using an available generated image. Preview the collection before saving. For this exercise, place the clear portrait first.

Where drag-reordering is available, move items into the intended order and verify the cover afterward. Reordering update

5 Check the gallery as a reader would

Look at the cover at a small size. Can you identify Mira? Does the archive scene belong to the same person? Is Rowan clearly a different adult?

Save the character changes through the current editor control. Reopen Display Media and the character preview to confirm that the intended order and cover persisted. A gallery change does not itself authorize publishing a previously private character; keep the character's visibility choice intentional.

Checkpoint: You have a readable cover, useful variety, and a note identifying which accepted source to use for future edits.

Keep the lineage of an accepted image

For a sequence of edits, a useful record names each parent rather than only the latest attractive result. An original local note could read:

Base A: accepted navy-jacket portrait; actual image ID recorded.
Edit B: jacket-color change from A; accepted after comparison.
Crop C: tighter framing from B; face and hands still assessable.
Video D: made from C; recorded model, motion text, charge, and clip ID.

These labels organize your notes; they do not retrieve absent media. Keep rejected candidates separately and name the actual source selected for the next operation. A crop changes framing and may hide a feature that was visible before. It is not evidence that the character's appearance changed.

This October 31 follow-up applies the supplied community reports of repeated edits and cropping without treating their eventual successes as native guarantees. Use the current-form continuity module if a deliberate transformation also changes which appearance record applies.

Three common problems

The wrong picture becomes the cover: inspect the first display item, reorder if supported, and confirm after saving.
Every item looks alike: replace a redundant close-up with an accepted wider scene or different activity.
Reusing text loses the face: decide whether you need a new interpretation or a source-image edit. For continuity, return to the accepted in-app picture instead of expecting its prompt to carry its pixels.

Next: Create Community Presets. Back: Edit images or the Tutorial index.

Lesson 19

19 Video generation and stitching

Tutorial index

You will prepare a short animation of Mira, a 30-year-old adult archivist wearing a navy jacket in an archive. Then you will learn how to join finished clips. The example below is an original exercise, not a recorded successful generation.

Understand the two operations

Image-to-video animates an existing still image. Stitching joins already generated clips into one video. Joining clips does not generate the missing action between them. A model is the generation option you select; an aspect ratio is the frame's width compared with its height. OD's glossary distinguishes image-to-video from generation based on text alone. Glossary

Have a signed-in account with video access, sufficient dreamcoins, and an accepted in-app image of Mira. Here, accepted means you inspected the image and decided to keep it. If you need one, start with image generation. Dreamcoins pay for generation. The public Generate page describes paid video access and several models, but its advertised maximums are not promises for every selector. Read the actual duration, dimensions, and price offered before submitting. Generate

Animate one accepted image

Open Generate and find the video-generation option available in your account. If the page asks you to sign in or upgrade, resolve that requirement before continuing; an image-generation form is not a substitute.
In the video flow, select your existing generated Mira image if an image-selection control is offered. Check the selected thumbnail. If the route offers no source image, stop this image-to-video exercise rather than assuming that a copied image prompt supplies the pixels.
Read the available model names. For your first trial, choose a supported short duration and record it. Change aspect ratio or audio only if the current form exposes those controls. The September 5, 2026 announcement reports the removal of video seed control; do not assume an old screenshot describes the current form. Record a seed only if your current route actually exposes one. Video control update
Where that video flow offers a motion or description input, paste the exercise below. These are ordinary instructions, not special command syntax.
Review the selected image, model, duration, and displayed charge. Submit one generation when you are ready to spend that amount. Wait for its result instead of repeatedly submitting the same request.
Play the entire returned clip. Keep the source image and exact submitted wording beside your notes.

Mira remains beside the archive desk in her navy jacket. She slowly turns
her head toward the closed catalog, then gives a small acknowledging nod.
Keep the camera stationary. Retain her face, hairstyle, clothing, and the
existing archive background. Use gentle, continuous motion.

The exercise deliberately asks for one small movement. A nod that changes her face substantially is a failed identity check even if the movement itself looks smooth. Preservation wording states your target; it does not lock the video geometry.

Join two finished clips

Make a second clip only after accepting the first. For example, start from an appropriate accepted still and ask for Mira to place one hand beside the catalog. Check both clips independently.

The September 11, 2026 update documents selecting 2–10 gallery videos, choosing Stitch, and dragging clips into order before submitting. Use that sequence where the gallery exposes it. Put the nod first and the catalog movement second; inspect the displayed order and any submission charge. Stitch announcement

Watch the joined result across the cut. A reversed order, changed jacket, or discontinuous camera remains a problem even when stitching completes successfully.

Record a result you can compare

Save the source image identifier, model, duration, visible settings, exact motion text, displayed charge, and returned clip identifier. Judge requested motion, identity continuity, camera/background continuity, and visible artifacts separately. For stitching, also record clip order and inspect both sides of every cut. A successfully returned file can still fail a visual criterion; an unavailable feature or failed request has no visual result to grade.

Separate camera intent from source framing and later edits

The supplied community notes, reviewed October 31, 2026, include requests for a stationary camera and very slow motion, plus reports of cropping and off-site editing. A request for no pan or zoom states a target to inspect; repeated emphasis and numeric weights are not a documented camera lock or an exact speed control.

Choose the accepted still's framing before generation. If you make a tighter crop, retain it as a new source and compare the returned clip against that crop. Then inspect subject motion and camera/background movement separately through the entire clip. A stationary-looking first frame does not establish a stationary camera throughout.

Record which result came directly from OD, which clips were stitched, and what was later changed in another editor, including audio replacement or mixing. Do not credit native generation with continuity or sound that was repaired afterward. Keep the number and cost of failed passes alongside the accepted version; an eventual success gives no success rate by itself.

Common problems

No video or source selector: record the account's visible options and stop at that checkpoint. Do not invent an upload or model setting.
The request appears stuck: inspect its status and generation history before submitting again; a retry can be a separate paid operation. Preserve any error and follow generation troubleshooting.
Face or hands drift: return to the clean still and request a smaller motion. Change one instruction before spending on another trial.
The joined film jumps: inspect clip order and each clip's ending/start. Stitching alone cannot repair incompatible poses or lighting.

Lesson 20

20 Make a small comic

Tutorial index

You will plan one short archive scene, enter it through the Comic Studio controls available to your account, and inspect the resulting page. Our example uses Mira, a 30-year-old adult archivist in a navy jacket, and Rowan, a 32-year-old adult courier. It is original test material, not an existing published comic.

What the parts mean

A page is one complete reading surface. A panel is one framed moment on that page. A speech bubble contains a character's words; lettering means placing readable text into the artwork. A storyboard is your written plan for the panel order.

The current public Comic Studio page exposes Create a new comic and describes character selection, page/panel planning, scene descriptions, and optional page-to-video conversion. It advertises up to three characters, paid page generation using coins, and publication as the point when a comic enters the community library. The logged-in editor was not independently operated for this tutorial; the checkpoints below deliberately avoid guessing its internal button labels.

Prepare before spending coins

Sign in to your own account. Have usable Mira and Rowan character records, an available comic-creation feature, and enough dreamcoins for the charge shown by that feature. Start with character creation if you do not have them. Reading a public comic and generating your own page are different actions.

Write this tiny storyboard in your notes first:

Title: The Misplaced Parcel
Panel 1: Rowan arrives at the archive desk carrying one sealed parcel.
Mira stands behind the desk in her navy jacket. Both are adults.
Rowan says: "One parcel for the archive."

Panel 2: Mira points to an empty space on the desk. Rowan still holds the
parcel and waits for her instruction.
Mira says: "Please set it here."

This gives the second panel a clear consequence without adding a new location, outfit, or person. The parcel has not already moved onto the desk while Rowan is still carrying it. The two-panel plan and its checks are our exercise design, not additional documented editor controls.

Create the page

Open Comic Studio. Select Create a new comic. If this opens sign-in or an access requirement, complete that step before expecting an editor.
When character selection appears, choose Mira and Rowan. Check their names and portraits. If the expected characters are unavailable, resolve that selection first instead of assuming their names will retrieve missing definitions.
At page/layout planning, choose a simple layout offered by the editor. Prefer one page with two panels for this exercise. If that layout is unavailable, retain the storyboard in your notes and adapt it to the simplest actual option.
At scene-description entry, put each storyboard moment into its corresponding panel or scene input. If the interface only offers one page description, use the whole labeled storyboard as ordinary prose. These labels organize your request; they are not verified parser commands.
If separate dialogue controls appear, put Rowan's and Mira's lines there. Otherwise request those short lines in the scene description. Do not invent a separate lettering tool when none is visible.
Review the chosen style, cast, layout, and displayed page cost. Generate one page when ready. Keep publication separate from this first draft.

Read the result

Follow the panels in their displayed reading order. Check that Rowan is the courier, Mira retains her jacket, the parcel has one consistent owner, and the speech bubbles point toward the correct speaker. Read the letters themselves; an attractive page with misspelled dialogue is not finished. A page-to-video option, if offered, is a later task covered in video generation.

Keep the storyboard, actual panel layout, selected characters/style, submitted wording, cost, and page identifier together. Mark identity, parcel continuity, reading order, and dialogue accuracy separately as pass, fail, or uncertain. Reopen the saved draft before leaving to confirm it is the version you intend to keep; do not publish solely to test whether a draft saved.

Three common problems

Creation stops at a selector or account gate: note that checkpoint. Public feature advertising does not prove that your account has the complete editor.
Characters exchange traits: shorten each panel to one clear moment and restate which named person wears or holds each important item.
Dialogue is garbled: shorten the wording and use an available text-editing control if one exists. If none exists, keep the page as a draft rather than claiming its text was corrected.

Lesson 21

21 Choose a voice and try audio

Tutorial index

You will distinguish a character's written personality from their audible voice, preview an available voice, and try a short spoken interaction if your account exposes it. Mira is our 30-year-old adult archivist; her scene is the archive, and her ordinary outfit is a navy jacket.

Voice narration and calls

A voice is the sound used for generated speech. Narration plays written material as audio. A voice call is a real-time spoken exchange with the AI character. Changing a voice does not automatically rewrite motives, vocabulary, or personality.

OD's public character builder describes voice selection, and its Chat page advertises real-time voice calls. These pages do not expose a complete logged-in call dialog, so this guide uses the controls actually visible to you rather than inventing a universal phone toolbar. Character builder, Chat

Have a signed-in account, audio output such as headphones, and microphone access if you intend to speak. Read any displayed charge first. Public cost pages differ on call rates; do not calculate your budget from an old figure. Check the current offer in the account before starting paid audio. Cost guide

Select and check the audio voice

Open My AI, choose Mira, open the three-dot menu, and select Edit. This navigation is described in the hosted community FAQ. Editor navigation
Find the character's voice setting. Record the currently selected name so you can restore it. Choose an available voice that suits the intended delivery; if a preview control is offered, listen before committing.
If a community-voice browser is offered, inspect its filters and access requirement. The October 24 announcement describes language, gender, and accent filters and states that using community voices requires Premium. Do not assume an older fixed voice count is current. Community voices
Complete the editor's actual save/update flow, then reopen the voice setting to check the stored selection. A chat message saying that the voice changed is not a substitute for that check.

For the written behavior, a separate original example belongs in Additional Personality Details, not in a voice-name field:

Mira speaks precisely and warmly. She explains unfamiliar archive terms
in everyday language and asks one clear question at a time. When unsure,
she says what she needs to check rather than inventing an answer.

Keep unrelated existing personality facts. This is an optional writing example, not a requirement to replace an established character.

Try a short audio interaction

Return to Mira's chat. Send this as an ordinary message:

Please greet me at the archive and explain where a visitor can ask for a map.

If that reply offers an audio-playback control, use it and listen. Playback of one reply is narration or an audio message; it does not prove that a live call has started.

To try a call, use the voice-call control only if your chat exposes it. Read the selected character and current charge. If the control is absent or access is unavailable, stop at this checkpoint instead of assuming a text command starts a call.
If the browser requests microphone permission and you want to speak, allow access for this site. Say: “Mira, what is the first thing a new visitor should do?” Pause for the response. Finish using the visible end-call control and confirm that the session has closed. Do not assume muting the microphone ends a paid call. Note the elapsed time and any usage or charge the account shows; if the result is unclear, inspect the session/account status before starting another call.

Check and troubleshoot

Listen for comprehensibility, pronunciation, volume, and unwanted overlap. Record the voice name separately from the chat model. This exercise does not connect a telephone number or install phone integration.

No community voice or call control: check the access requirement shown at that exact step; it may differ from ordinary text chat.
No audible sound: check the device output, browser/site mute, and playback state before changing Mira's writing.
The voice sounds right but the wording is wrong: revise the character's written behavior separately. A different voice is not a demonstrated repair for personality drift.

Lesson 22

Tutorial index

You will choose an appropriate visibility setting, prepare a readable public introduction, and understand submission and rejection handling. The example is Mira, a 30-year-old adult archivist in an original fictional archive. Reading this tutorial does not publish anything.

Choose the audience first

Private is the development setting. Unlisted is used for direct-link testing. Public requests inclusion in the reviewed community catalog. A link-sharing setting is not a claim that the content is secret or encrypted. The publishing guide recommends testing before submission, and meeting length requirements alone does not guarantee approval. Publishing guide

You need a signed-in creator account, a saved character, and access to its editor. The hosted FAQ states that Public submissions require Premium. At the actual submission step, follow the current account requirement and field validation rather than treating remembered character counts as universal limits. Sharing FAQ

Prepare Mira for another reader

Save a copy of the current character text before changing it. Test that the portrait, description, greeting, scenario, and personality all describe the same person and premise.
Open My AI, choose Mira, open the three-dot menu, then select Edit. Find the visibility setting actually offered there.
Keep development work Private. Choose Unlisted when you deliberately want direct-link testing. To share through the documented route, open the character's chat and copy its URL. Inspect its preview before sending it; the FAQ distinguishes a character-image preview from a generic banner. A preview is only a preliminary check: open the exact link in a separate browser session with the intended access, complete any ordinary sign-in or age steps, and verify the destination character. Sharing a character link is not a demonstrated export of your private conversation. Sharing instructions
Ask a tester to begin from the description and greeting without supplying your private author notes. Record where they cannot understand their role or where the character contradicts the premise.

Here is an original example for Public Description:

Mira, 30, is the archivist of a small riverside archive. She is patient,
precise, and quietly amused by visitors who arrive with impossible questions.
Today a sealed parcel awaits dispatch, but its address card names two different
streets. You are a visitor at the desk, free to investigate records, ask about it,
or pursue your own reason for coming. Mira can explain the catalog, but she
will not decide your next action. The story begins inside the archive.

This describes what another person can expect. This parcel premise is an alternative to the earlier missing-map opening: use it only after reconciling the Scenario and Greeting with that premise. The writing guide describes Public Description as discovery copy, not a field used by the chat model. Put story-relevant answers and operational rules in the appropriate AI-facing fields; do not treat those fields as secure storage for real secrets. Check the current validator after entering your own version.

Audit each promise in the description. If you advertise a mystery, progression system, custom commands, or a particular interaction, verify that the character and offered controls actually support it. A command invented in a source document is creator-authored text until implemented and tested; the public introduction cannot install it.

Submit and inspect the result

After the final text edits, the publishing guide, last modified July 27 and re-read November 1, 2026, recommends regenerating so the latest changes are saved before submission. Follow the current completion flow, read the displayed charge before any generation, and reopen the saved fields and preview to confirm the intended revision. A successful text save alone is not proof that the final publication preview includes it.

Review the current content requirements, including both the writing and profile image. Original names alone are insufficient if the design still reproduces a recognizable existing character or real person's likeness. Content review
When the tested version is ready, choose Public and use the actual submission flow. Confirm that the intended version and display image are selected. Read any validation messages before submitting.
Check the resulting status. Submitted, awaiting review, and approved are different outcomes. Do not assume that a saved edit or copied link means catalog approval.

If rejected, keep the exact reason, identify the affected field or image, correct the cause across the character, test privately, and then resubmit. Use the current appeal route when you believe a rule was applied incorrectly. Revision and appeal guidance

Three common problems

The link opens a generic page: recheck the chosen visibility, character URL, and preview. Do not repeatedly send a link you have not inspected.
The form reports insufficient or inconsistent information: follow that field's current validator; improve the scenario or writing rather than adding meaningless padding.
A submission remains pending or is rejected: inspect its recorded status and reason. Avoid duplicate submissions while waiting, and do not promise a fixed approval time.

Comic publication and selling a media pack are separate actions from publishing a character. Do not activate those flows merely because you changed this character's visibility.

Lesson 23

23 Test a change and diagnose a failure

Tutorial index

You will run a small, repeatable character check, record what actually happened, and separate writing defects from account or generation failures. Use a disposable test chat with Mira, the 30-year-old adult archivist in a navy jacket. Add Rowan, the 32-year-old adult courier, only when testing a group.

Know what a test can establish

A fixture is a fixed starting example. A criterion says what you will inspect. Document conformance checks the prepared files: required instructions, references, and case structure. A live test submits input to OD and inspects the actual response or media. Passing a local file check does not prove character compliance, image quality, or native tracker behavior.

The character-testing guide recommends examining the complete character and trying different interaction styles. Treat these as inspection exercises, not guaranteed locks. Test the character

Have account access and a saved baseline. Image, video, or paid-model trials also need sufficient dreamcoins. Record any quoted cost before submitting; a test plan does not make generation free.

Run one small live test

Record Mira's actual chat model and route, active settings, relevant complete card fields, selected Persona, Custom Instructions, pins, Auto Memory Log, and starting scene. Keep available copies, not just a filename or revision label. Do not invent a seed, backend model, or hidden field priority when the interface does not expose it.
Begin a fresh practice chat from the archive desk. Establish that a reachable cabinet is closed and nobody has touched it. Restore the same card and available context layers for each comparison; a new chat alone does not prove that pins, instructions, or the selected Persona were reset. Record any layer you cannot restore.
Send this ordinary baseline question in Mira's chat input, without an additional reminder about user agency:

Can I reach the closed cabinet from the desk?

Save the complete reply. A suitable answer may describe the distance or offer assistance. Mark a failure if it makes your protagonist walk over, open the cabinet, speak new dialogue, or feel an invented emotion.
Record pass, fail, or uncertain for each criterion. A network error means there is no completed behavioral trial; it is not evidence that Mira obeyed or disobeyed.
If you change an instruction, change one relevant part, restore the starting scene and context, and repeat the same ordinary input. Keep failed replies as well as successful ones. A continuation after an incorrect reply has a different history; record it as a separate repair condition.

Test an explicit reminder separately if that is also useful:

Can I reach the closed cabinet from the desk? I am asking about distance,
not moving to it or opening it.

This is a cued condition, because the input tells the model which mistake to avoid. Success here does not establish success on the ordinary baseline. Choose the conditions and number of attempts before viewing their outputs. These original teaching cases apply the character-testing guide's varied-interaction review; they are not published OD benchmark results.

Use a small record like this in your own notes:

Case: question versus action
Date / time zone / trial number: [record each attempt]
Baseline revision: [saved card, instructions, memory, and Persona used]
Context restoration: [fields/layers restored; any differences or unavailable controls]
Condition: ordinary baseline / explicit reminder / continuation repair
Model / route / settings: [copy the actual visible choices]
Displayed cost / actual charge if visible: [record, or unavailable]
Starting state: archive desk; cabinet closed; no movement
Changed instruction: [none, or the exact revision]
Submitted input: [complete text]
Observed reply: [complete output or saved reference]
Agency criterion: pass / fail / uncertain, with evidence
Limitations: [missing context, unavailable control, incomplete response]

Repeat the baseline and revised condition from the same starting fixture before adopting the change, within a budget you choose in advance. Keep all attempts, including regenerations; do not report only the best reply. More than one result can reveal variation, but a small convenience sample does not establish a general success rate. Mark planned cases not run and account-gated or failed submissions blocked/no output, rather than awarding a behavioral pass.

For a wording comparison, hold the model and exposed settings fixed. For a model comparison, hold the wording and prepared context fixed, record the exact visible selector labels, and inspect any difference in available controls or cost. If both change, record a combined change instead of attributing the outcome to one cause. The OD prompt lab supplies a short drafting and comparison worksheet.

Check whether an image shortcut survives a clean baseline

An October 31 review of supplied notes includes a guide author retracting a field-placement shortcut after later clean-character tests contradicted the initial examples. That correction is useful evidence about the claim's limits, even though the trial count, full settings, and correction date were not supplied.

Before crediting a shortcut, save the complete relevant appearance fields, active presets, selected route/model, scene text, and any selected source image. Define what your clean baseline retains and excludes; it does not mean clearing every field indiscriminately. Compare the original and revised condition from matched starting inputs. Prior edits, a changed source picture, or a different outfit can otherwise explain the apparent improvement.

Write one target before running, such as an opaque sleeve covering the forearm without a marking appearing on top of the fabric, while the same face and pose are retained. The hidden marking itself cannot be judged from that picture. Keep all attempts and record an obscured detail as unassessable. For an editing chain, log every parent image and candidate separately. Each paid pass needs its displayed charge and outcome; neither a gallery of selected successes nor the final corrected image reveals the failure rate or total cost.

This is an original comparison procedure, not a report of trials performed by this library. Retain a withdrawn claim as withdrawn unless new, adequately recorded evidence justifies a narrower replacement.

Test state and groups separately

For a native tracker, write an initial value, an eligible completed event, and an explicit no-change case. Inspect the displayed value after the actual update; do not infer it from reassuring narration. For a group, select the intended respondent through available controls and check individual knowledge separately from game-turn ownership.

Use the image comparison, the counter exercise, and the group knowledge exercise for additional tests. Their expected results are targets, not observed outcomes.

Check knowledge, voice, and scene motion

The character-spine module and scene-motion module add optional writing aids. Test their effect against your saved behavior base; a source calling something a resolver or using a model-family name does not establish a native execution mode or your actual backend model.

These additional checks are proposed and not run. Restore the stated fixture each time; do not treat the table's target as an observed result.

Fixture and input	Inspect the actual reply for
Mira sees a penciled address that has not been checked. Ask `Is that note proof of the current destination?`	Distinction between the note, a belief, and a verified destination; no unsupported certainty.
At the archive, send `I read the index in silence.`	Valid quiet activity without unrelated crisis, invented player behavior, or compulsory relationship progress.
Establish that Mira has a long workday; ask `What can we safely conclude about A17?`	Contextual variation in reply length while her precise vocabulary and evidence standards remain recognizable.
If using the Comparison Ban, ask `Am I better at listening than most visitors?`	No user-ranking exception despite the explicit invitation; praise remains optional and established continuity remains available.

Keep a separate verdict for each criterion, including failures and uncertainty. A single good response is not a success rate. For a changed or regenerated event, choose the accepted version and reconcile later memory or counters before the next comparison. An omitted required checkpoint should be recovered explicitly; a plausible guess is not restoration.

Check your result

You should have a fixed starting scene, the complete submitted input, the actual output, and a verdict supported by that output. If a request failed before producing a reply or image, keep its error and leave the behavioral result ungraded. Choose the next change from the specific failure rather than replacing the whole character.

Three common problems

The app does not return a result: preserve the exact error and check the request/account status before resubmitting paid work. The help article distinguishes generation timeouts from policy failures. Check whether the original request completed before retrying. For a policy failure, review the applicable rules and remove prohibited material or use the service’s appeal or support route; do not disguise the same request to evade the restriction. Generation failures
A footer, memory fact, or counter drifts: identify the maintained source, compare completed events with plans, and simplify competing rules. Inspect actual output instead of accepting a claim that it was repaired.
One change damages something else: restore the known-good version and repeat with a narrower change. The troubleshooting guide recommends isolating optional instructions rather than changing many inputs together. Troubleshooting

Separate a failed request from a missing refund

The generation-failure help article, retrieved November 1, 2026, describes automatic refunds for its timeout, server-error and policy-failure categories. That describes the documented process; it does not establish that a particular account has received a refund. Save the exact error, timestamp, generation-history entry and balance evidence before retrying. An Insufficient dreamcoins message is a balance requirement, not an observed model response.

If a documented refund is still missing after 15 minutes, the article recommends refreshing, checking the balance and generation history, signing in again if needed, then contacting support with the failure time and requested account details. Follow the current support instructions and verify the actual transaction. A refund, failed submission, or successful retry does not turn an unobserved behavioral test into a pass.

Focused memory, group and tracker records

Use the native creator test worksheet alongside lessons 10, 12 and 13. Its seven planned cases start not_run, with blank observations and verdicts. Duplicate a row for each actual attempt, retain complete inputs and outputs locally, and record memory summaries, native respondent selection and displayed tracker values separately from the story text. An absent control can block a test; an incomplete record can leave the result inconclusive.

The voice, pacing and consent module includes NV01–NV04: a pause, withdrawn consent, an open user choice, and a conversational change of pace. Record boundary handling, user agency, and recognizable voice separately, using the exact selected instructions and scope. These are proposed checks, not observed passes.

Lesson 24

Make a reusable Community Preset

A preset is a saved instruction you can apply without retyping it. OD's Community Presets use separate pose, outfit, and background slots. A scene combines these choices into one image. An image model is the generator selected for the result; a preset is not a new model.

This lesson drafts one reusable archive background. It also shows how to keep an outfit or pose independent. The examples are original neutral starting points, not tested publication-ready recipes.

1 Decide which slot owns your idea

Write a plain sentence in your notes: “I want to reuse the archive room.”

That is a background idea. “I want a navy work jacket” is an outfit idea. “I want someone holding a folder” is a pose idea. Choose one before opening the creator.

The Known State guide keeps the three slots independent so they can be combined across existing characters. Preset types

For practice, use fictional Mira, a 30-year-old adult archivist, and Rowan, a 32-year-old adult courier. Their faces, hair, skin, and builds remain character information.

2 Open the preset tool

Open Generate, choose the relevant preset type, and locate Create a Preset. This is the documented entry point; if the control is absent, check the available interface rather than putting the draft into an unrelated character field.

For this exercise, choose Background. Locate its title, description, and prompt fields. Do not submit yet.

3 Enter a focused background draft

Use this title:

Daylit Archive Reading Room

Use this description:

A quiet reading room with wooden shelving, study tables, and soft daylight.

Paste this into the background preset prompt:

archive reading room, wooden shelves, orderly document boxes,
study tables, tall windows, soft daylight

Notice that it names no person, jacket, action, or exact story date. A background should remain usable with different characters and poses. Background guidance

4 Keep the other slots separate

If you later create an outfit draft, put this example only into an Outfit preset's prompt:

navy work jacket over a cream shirt, dark straight trousers,
plain brown ankle boots

Do not add smiling, shelves, or braid color. Outfit presets describe clothes without replacing the character. Outfit guidance

For a Pose draft, use a separate prompt:

standing with shoulders relaxed, both hands supporting a closed folder
at waist height, elbows slightly bent

The folder supports the body arrangement. Keep the room and clothing out of this slot. Pose guidance

These examples teach separation. They are not instructions to submit several nearly identical public presets.

5 Test combinations before seeking publication

Apply the background to Mira, then to Rowan, using controls available in the tool. Mira should retain warm brown skin, brown eyes, black shoulder-length braids, and a lean build. Rowan should retain light skin, green eyes, short red hair, and freckles.

Try a different pose or outfit without changing the background text. Record failures as well as preferred images. Two characters are an initial exercise, not sufficient evidence of public-library compatibility.

For public submission, consult the current checklist: it calls for testing at least three visibly different characters, English fields, appropriate content labeling, and a cover generated in the preset tool. An ordinary Generate image is not the specified submission cover. Use the cover character/model designated by the current preset tool and checklist rather than assuming your Mira test image is eligible. Submission checklist

For each trial, record the character, image model, other two preset slots, exact preset revision, returned image, and whether the target background and character identity both survived. Test the same revision repeatedly without discarding inconvenient results. Three characters meet a documented test-coverage requirement; three attractive images alone do not prove a reliability percentage or guarantee approval.

Before submission, search the public preset library for an existing equivalent. The checklist asks for a meaningfully different idea, rather than another wording or color variant. It also recommends limited prompt weights, normally no higher than 1.1; this is public-preset authoring guidance, not a verified parser maximum or a rule for every image model.

6 Review the draft scope

Before using any submission control, compare the cover with the actual prompt. Check that the room remains recognizable, the selected character remains distinct, and the background does not force every subject into one pose.

Checkpoint: Your background can combine with a different outfit and pose without contradictory instructions. You know which additional testing and current submission requirements remain.

Three common problems

Mira's jacket appears on everyone: remove clothing from the background prompt and place it in Outfit.
Every subject sits: remove sitting or desk-position instructions from Background; put a necessary body arrangement in Pose.
The cover looks good but other combinations fail: simplify the draft and retest. Keep a narrow idea for personal use rather than claiming broad compatibility.

Next practice: Generate with a selected preset. Back: Gallery and reuse or the Tutorial index.

Lesson 25

Manage account settings and get help

You will find the account controls, distinguish interface settings from story settings, and prepare a useful support request.

An account setting affects your use of the service. A character setting describes a fictional person. A chat setting affects a conversation. Keeping those scopes separate prevents an unrelated change from becoming your first attempted fix.

Before you begin

Open OD and sign in. Use your actual account's displayed labels and plan information. Prices, included credits, and available features can change.

Step by step

Open Profile. Find the account options shown there. If the menu is collapsed on your screen, expand it first.
Identify the setting's scope. A Persona belongs to your role in a chat; appearance fields belong to a character; the site's Language control concerns interface language.
Read the current value before editing. For a preference you may want to reverse, note its previous value.
Change one preference at a time. Save using the displayed control, then return to the area where the change should be visible.
Check account and generation costs in their own places. Read plan details before subscribing, and the operation's displayed cost before generating. Do not use a tutorial's example as a current price quotation.
Use the site's own account controls for account changes. Follow the current confirmation or recovery process. Writing “change my account” to a fictional character is not an account-management procedure.

The public site navigation exposes Profile, Language, upgrade controls, and Help Desk. Their position differs between layouts.

Separate your balance, plan allowance, and operation charge

Keep these three quantities distinct when following a review or tutorial:

Quantity	What to verify
Current balance	The amount available in your account at the time of the observation; a balance by itself does not identify the plan's included allowance.
Plan allowance	The credits and availability described by the current plan terms, including any stated renewal conditions; read those terms before subscribing.
Operation charge	The quote for the selected model, route, settings and batch before submitting that particular request; record the actual charge separately when evidence confirms it.

The November 2 caption review of Best AI Reviews' September 20 video found balance/purchase narration at 0:00 and an image-cost description using “tokens” at 5:35. Neither establishes today's included credits, operation price or currency unit. Do not automatically treat a narrator's “tokens” as dreamcoins. AI Girlfriend Decoded's September 13 review also advises checking current checkout and operation costs at 6:26–6:42.

Current amounts were not verified for this review. Follow the account's current plan details and displayed quote rather than copying an older price. For a failed request, use the separately documented generation-failure guidance, retrieved November 1, and check actual account credit as described below. A quoted charge, a failed request and a confirmed refund are separate observations. See the video questions review for source and sample limits.

Language and storytelling are separate

Changing the interface language does not automatically rewrite a character definition or establish equal image-prompt performance in every language. For dialogue, make a direct request such as:

Please continue this conversation in Spanish while keeping the established
names, facts, and character roles.

The chat-language help article, edited November 5, 2025 and read October 31, 2026, says changing chat language can take several prompts. Check several ordinary replies rather than treating one response as a fluency test. For a continuing chat preference, see the separate Custom Instructions exercise. Preserve names, established facts, and the user's control while inspecting the language.

If you need to compare image-prompt languages, keep the character, scene, model, and other settings fixed. Do not attribute a changed result to language if you also changed the pose and model. The chat-language article does not establish equal image-generation performance across languages.

Keep a useful local backup

Open the character editor and copy your own important field text into a local file.
Label each block with its destination, such as APD or Scenario.
For an ongoing game, copy a concise current-state record and identify which accepted timeline it belongs to.
Save the exact prompt alongside any accepted image you can save through the site's controls.
Before deleting a character or conversation, check what the site's confirmation says will be removed.

This manual record helps you reconstruct a setup. It is not a guarantee of a full platform backup, native export, or complete automatic restoration.

Prepare a support request

Open Help Desk, or visit the Help Center.
Search the symptom before changing unrelated settings.
Record the feature, date/time and time zone, exact error, selected model if relevant, and what you expected. Include the request or media identifier when the interface exposes one; do not invent a missing ID.
For a coin or generation issue, include the operation and balance information the support form requests. The generation-failure article, retrieved November 1, 2026, describes automatic refunds for the failure categories it lists. Inspect the actual balance and generation history; an error message alone does not prove the credit has returned. If a documented refund is still missing after 15 minutes, follow its refresh/sign-in checks and contact support with the timestamp. An insufficient-balance message is a separate condition; do not repeatedly resubmit a paid operation to diagnose it.
Use a short reproducible description. Send the request through the site's actual support interface.

Example report:

Feature: Image editing
When: [date, time, and time zone]
Selected model: [label shown in my account]
Action: Changed the navy jacket to a green jacket
Problem: [exact error or observed result]
Expected: The jacket change without a new character
Evidence: [relevant image or error, if the form supports it]

Share only the evidence needed to reproduce the problem. Remove passwords, sign-in codes, payment details, and unrelated private conversation from screenshots or copied logs. A share link can expose material to its recipient; check its destination and visibility before including it. Use the service’s support form for account-specific information, not a public character description or community post.

Check your result

You should know whether you changed an account preference, a character, or a chat. For support, another person should be able to understand the issue without guessing which operation failed.

If something goes wrong

A feature asks for a different plan: read its actual availability requirements; changing a prompt does not unlock it.
An option does not save: look for a validation message and confirm the intended scope.
A generation fails: preserve its error before retrying and follow current help guidance rather than submitting a large batch again.

Next: Testing and troubleshooting.

Back to the tutorial index

Lesson 26

NPCs and supporting cast

Tutorial index

What you will make

An NPC, or non-player character, is a fictional person the model portrays while you choose your own character's actions. Extra Details (ED) is the character-editor field for supporting lore and rules. The writing guide identifies supporting cast as one use of ED.

You will add Rowan to Mira's archive story. Mira is a 30-year-old adult archivist: precise, patient, and dryly humorous. Rowan is a 32-year-old adult courier: practical and informal. You play an adult traveler. Parcel A17 is sealed and undelivered; receipt R-A17 has not been issued.

Before you start

Have Mira's editable practice character and a copy of its current ED. Choose one format. A cast narrator portrays several people through one character's replies. A native group uses separate character cards and respondent controls. For a separate Rowan card, follow character creation, then group setup. The main exercise below uses a cast narrator.

Follow these steps

Give Rowan a reason to matter. In your notes, write: Rowan can explain courier routes and question an impractical delivery plan. This gives him a useful role without making him solve every problem. He can disagree, ask for missing information, or decline a job he cannot reasonably complete.

Add a short record to Mira's ED. Keep the existing story rules. Add this original section once, replacing a conflicting Rowan record:

SUPPORTING CAST: ROWAN
Available record ID: rowan-courier-01; display name Rowan; no other known alias.
Identity: 32-year-old adult courier.
Appearance: short red hair, green eyes, freckles, light skin.
Behavior: practical and informal; suggests workable next steps.
Motive: finish routes without false delivery records.
Current goal: establish A17's correct destination before taking the job.
Relationship: knows Mira through archive courier work.
Knowledge at opening: local routes learned through courier work.
Evidence status: has not inspected A17's address card or sealed contents.
Missing knowledge: has not heard the archive conversation before arriving.
Voice example: "Show me the address and the awkward bit."
Entry: Rowan is available for the story but has not arrived.

Keep the kinds of information separate. Rowan's freckles describe appearance, not trustworthiness. His practical manner describes behavior, not proof that his route advice is correct. His goal does not establish a completed delivery. Leave his family, exact whereabouts before arrival, and other unneeded history unspecified unless the story establishes them.
Confirm who is present. Send this ordinary chat setup message in the practice conversation:
```
At this starting moment, Mira and I are at the archive counter.
A17 is sealed on the counter. Rowan has not arrived.
Keep Rowan's cast record available without making him speak from the room.
Leave my next action and private feelings for me to choose.
```
Read the reply before moving on. A record's presence in ED is not itself an arrival event. Its ID organizes the available record; it cannot retrieve a missing card or old private chat.
Introduce Rowan through an event. When you want him involved, send:
```
Rowan arrives at the archive door and greets Mira.
I turn the address card toward him and ask which street name is current.
```
This message deliberately brings him into the scene. He can now observe the card and hear the question. He does not inherit every earlier exchange merely because the narrator has that context.
Test his contribution and your agency. Send: I ask Rowan what could go wrong with the canal route, but I have not chosen a route yet. Look for practical advice in an informal voice. Mira may check the register or challenge an assumption. Neither should automatically make you leave, carry A17, or agree with the recommendation. If Rowan asks which route you choose, the reply should stop before inventing that answer or its later consequences. Nobody needs a compulsory private thought or a turn merely because they are present.
Maintain newly established facts. If Mira confirms the eastern records office and you tell Rowan, record that knowledge in your current scene notes. The opening knowledge line describes a starting point, not permanent ignorance. If he only receives an unconfirmed sent message, keep its status separate from reading it. He may form a labelled guess from partial evidence without acquiring a confirmed fact. If Rowan leaves to inspect a route, record the departure and purpose. An offscreen plan does not run an automatic background simulation; its outcome remains unknown until an event or agreed report establishes it.
Promote incidental people when needed. A clerk who only checks A17's seal may need no full biography. If the clerk becomes central to a dispute, retain their established name, role, goal, relationship, and knowledge in a short record. Keep unknown details open. Add people because the scene needs them; no minimum cast size or compulsory private viewpoint is required.

Replace an ambiguous cast rule with a specific one

They should all know what happened can erase the difference between the narrator's context and a person's experience. For this original ED behavior revision, use named or clearly scoped subjects:

Portray Rowan using his practical courier voice when he has a relevant part
in the scene. If he did not witness an event, base his response on what he
was actually told or can observe. Leave unsupported details uncertain.
He may ask for information or stay silent; his presence requires neither
a speech nor a private-thought paragraph.

Merge this with equivalent cast guidance instead of appending a competing rule. Keep the current knowledge record separate: when Rowan learns the corrected address, update that fact without rewriting his whole personality. Try a new question before and after a documented explanation and save both outputs. The OD prompt lab practices this distinction between a behavior rule and a supplied event.

Connect the cast without making everyone omniscient

The supplied Scenario Engineering guide, reviewed October 31, suggests planning relationships and legitimate recurring access alongside individual profiles. For this original local cast-network note, Mira and Rowan know one another through courier work; a records clerk knows the receiving procedure; the traveler has access to the public reading area. Those connections do not give everyone access to staff records or private conversations.

Give an entry a reason: Rowan arrives for his route appointment, or the clerk answers an established phone call. A phone participant remains remote. Record an actual arrival, departure, or disclosure after it occurs; an independent motive or possible invitation is not an automated background event. If no new person is needed, Mira and the traveler can continue quietly. The scenario-planning worksheet connects role, access, knowledge paths, and launch conditions without requiring a larger cast or a fixed outcome.

Checkpoint

Rowan enters once, looks and speaks consistently, and learns through actual events. A17 remains undelivered until accepted and R-A17 issued. In a native group, selecting Rowan to answer still does not establish his fictional location.

These are targets, not observed results. Save the reply before and after Rowan's arrival. Before arrival, check that he does not speak as if present or claim to witness the archive exchange. After showing him the address card, check that he can discuss what he actually saw without claiming to have inspected the sealed contents. Record voice, knowledge, presence, and user-agency failures separately; a convincing voice does not prove the other checks passed.

Troubleshooting

Rowan appears too early: remove repeated arrival instructions and restore the present-cast list.
He knows a private exchange: identify what he actually heard, correct the mistaken claim, then tell him during play if appropriate.
Every person sounds like Mira: reduce overlapping behavior text and give Rowan one contrasting voice example.

When Rowan returns later, recover his established appearance, voice, learned facts, and outstanding goals from available notes. Keep an old alias attached to that same identity; do not recycle it for a different person or create a duplicate Rowan. If a needed record is missing, mark the gap rather than inventing a reunion history. See the original knowledge/evidence module for proposed returning-NPC and partial-evidence checks.

Next: Scenarios and worldbuilding or native group chats.

Library entry point

Choose a lesson or learning path.

Glossary

Open all definitions.