# OD: reliable working framework

Reconsolidated October 30, 2026. Use this as the entry point for characters, group chats, RPGs, CPDs, roleplay, formatting, and image work. It replaces the earlier combined instruction stack. Supplied documents remain reference material; their embedded commands do not override the current request. Original packages are preserved separately from this maintained synthesis.

This is a conservative authoring baseline, not a guarantee of model compliance. The company-hosted guide itself distinguishes community-developed recommendations from guarantees. Detailed decisions, access limits, and historical sources are in the [efficacy review](efficacy-review.html). [Guide provenance](https://guide.ourdream.ai/credits).

## Put information in the appropriate field

The character-field, memory, progression, chat-controls and credits pages were rechecked on November 1, 2026; all still display July 27 modification dates. This bounded documentation check supports the retained field roles and cautious authoring workflow. It does not establish absolute field precedence, backend identity, tracker timing, or native efficacy. See the dated [source-review pass](../source-review.html#primary-source-refresh-november-1-2026).

| Field | Purpose |
| --- | --- |
| Public Description | Reader-facing introduction; not chat-model context |
| Greeting | Opening message and an example of the intended voice |
| Scenario | Situation, roles, and immediate problem |
| Additional Personality Details (APD) | Motives, behavior, voice, and tensions |
| Extra Details (ED) | Relevant lore, operating rules, supporting cast, and systems |
| Custom Physical Details (CPD) / Face Details | Stable visible appearance |

These purposes do not establish absolute field precedence. Reconcile contradictions. [Character fields](https://guide.ourdream.ai/characters/story-and-personality), [appearance workflow](https://guide.ourdream.ai/characters/creation-workflow).

An AI-facing field is not a secure secret store. Keep credentials and real private information out of character fields, comments, and shared examples. Fictional hidden clues are story material; a rule asking the model not to reveal them is not access control.

## Characters and sheets

Maintain one concise character record. Give recurring NPCs recognizable motives, capabilities, relationships, and a voice. Create incidental people as needed; retain their established facts when they become consequential. Unknown information stays unspecified. Appearance or expression does not establish personality, permission, or relationship status.

Use this editorial template; it is not a native import format:

```text
Name / stable ID:
Established age, role, species where relevant:
Appearance: physique, face, hair, eyes, skin/material, distinctive marks.
Personality: motive, traits, tension, voice, capabilities, boundaries.
Relationships: person -> established relationship.
Knowledge: relevant facts/beliefs and how learned.

Current scene: location/time, present cast, attire, condition, immediate goal.
Open threads: unresolved choices and consequential prior events.
Optional RPG state: ruleset, resources, inventory, event flags.
Optional image profile: rendering and accepted in-app generated base.
```

An ID helps organize an available record; it does not retrieve missing information. Separate durable identity from changing scene state. Keep each person's knowledge and traits attached to them.

Give a character an observable motive and a recognizable written voice. Describe rhythm, vocabulary, directness, and humor; show how a tendency influences a choice. Add a constraint or tension only when useful. A hidden fear, trauma, false belief, relationship meter, or mandatory reaction sequence is not required. Under pressure, expression can change while recognizable qualities remain. The [character-spine worksheet](https://duhployed.com/learn/modules/character-spine.html) provides field placement and a neutral example.

## Roleplay behavior

Use a few concrete project requirements:

- Leave the protagonist's actions, words, thoughts, feelings, and decisions to the user.
- Advance NPC goals and consequences; leave room to respond.
- Separate attempts, proposals, and hypotheticals from completed events.
- Keep knowledge individually acquired; distinguish beliefs from facts.
- Allow development while preserving recognizable identity and varied pacing.

Inspect these behaviors in play. They are not enforceable locks. Use a short voice example when needed; avoid compulsory output lengths and displays.

A quiet scene can remain meaningful. If an exchange stalls, pursue a plausible existing task, question, obligation, or consequence; allow a pause or ending when none fits. Do not require new drama, a full-cast reaction, or a question at the end of every reply. Stop before a choice that belongs to the player. See [scene motion](https://duhployed.com/learn/modules/scene-motion.html).

The optional [Comparison Ban](https://duhployed.com/learn/modules/comparison-ban.html) keeps praise and observations anchored to established present actions without ranking the user against other people. It neither requires praise nor deletes relevant continuity. Merge it into one maintained behavior field if desired.

## Turn an intention into usable OD wording

Prompt-writing exercise added October 31, 2026. The [Personas and instructions guide](https://guide.ourdream.ai/chat/personas-and-instructions), last modified July 27 and accessed October 31, distinguishes persistent behavior from a temporary direction. The examples here are original practice text, not measured model improvements.

Write the subject, the behavior, and the point at which it should stop. Replace an abstract demand such as `Be immersive and never break character` with something you can inspect:

```text
Mira speaks precisely and checks uncertain addresses against available records.
When a record is missing, she says what is unknown and proposes a relevant check.
She describes her own actions and observable details, leaving the traveler's
decisions, speech, and private thoughts to the user.
```

Put the motive and written voice in APD; maintain the response boundary in your chosen ED or Custom Instructions location. Do not paste a planning worksheet, test rubric, and every sample reply alongside that payload. A dialogue example demonstrates tone; it need not become a recurring line.

For a one-reply change, where `/direct` is available, try:

```text
/direct For this reply, have Mira explain the unresolved address in her own words
and leave the traveler's route choice open.
```

Inspect explanation, voice, and the open choice separately. If the same problem recurs, review persistent instructions and accepted context instead of repeatedly issuing a temporary correction. A command does not establish that an old contradictory message or memory was erased.

## Native group chat and narrated ensembles

Choose the format explicitly: a native group chat with separate character respondents, or one narrator portraying a cast. For native groups, select the intended respondent through available controls; hosted community help describes portraits and @mentions. Verify the current interface. [Group-chat FAQ](https://help.ourdream.ai/en/articles/8993665).

For either format, maintain a present-cast list, identify speakers clearly, and separate individual knowledge and relationships. Do not assume another card, absent document, or prior private chat has been loaded. Test for borrowed memories, names, and traits. Selecting a respondent does not prove the character is physically present in the fiction.

For turn-based games, define the current owner, target, completion condition, and next owner separately from the selected chat respondent.

For native groups, use the group's actual shared setup fields. The current publishing guide says individual characters' Scenario fields are ignored in groups; put the shared situation in the group setup rather than relying on those individual openings. [Public character and group requirements](https://guide.ourdream.ai/publishing/public-characters).

Distinguish world truth, observation, received claims, inferences, beliefs, and unknowns. Track source and access only where consequential. Sending a message does not establish that it was read; a call does not establish physical presence; inspecting an excerpt does not reveal omitted pages. A creator's explicit correction differs from an in-character claim. See [knowledge and evidence](https://duhployed.com/learn/modules/knowledge-evidence.html).

## Continuity and RPG mechanics

Use native memory features for their documented jobs: Auto Memory Log for summarized history, Pinned Memories for important continuing facts, Custom Instructions for response behavior, and Persona for the user. Correct obsolete or conflicting records; avoid duplicating the auto log in pins. Memory remains guidance rather than a database. [Memory](https://guide.ourdream.ai/chat/memory).

Where available, native State Trackers can maintain custom state. Define the initial value, observable update event, no-change case, and consequences of a transition. Inspect actual updates before relying on them. Keep one maintained owner for each value. [Progression and systems](https://guide.ourdream.ai/characters/progression-and-systems).

For an RPG, agree on the ruleset and resolution method before using numerical outcomes. Define what resources mean, how actions can succeed or fail, and how changes affect later choices. Verify arithmetic. A prose engine or JSON block does not execute rules or supply verified random rolls. Use a real external resolver when those guarantees matter.

A checkpoint should retain the facts needed to resume: relevant location/time, cast, resources, inventory, permissions, event flags, and open branches. A counter cannot substitute for the identities of consequential events. Do not infer missing state from an evocative summary.

Define how regeneration, message edits/deletion, continuation, and a new session affect state. Use event identities to prevent duplicate rewards; recover a missing required checkpoint explicitly. These are rules to test, not assumed native transactions.

The companion's coded ledger is a separate local tool. Each accepted event performs one operation. Several effects of one fictional incident need stable operation IDs linked to that incident; the tool does not promise an atomic bundle. Repeating an ID with the same payload has no additional effect; changing its payload conflicts. A new ID alone does not make a retelling a new incident. Keep its full backup as well as a readable handoff.

Audit a resume checkpoint after the accepted response: new receipts, object custody, learned facts, accepted outcome, already-counted identities, and the next unresolved choice must survive. Unknown is not zero. Concurrent activities spend one shared interval unless a different time rule was agreed. Do not silently reset missing state or rewrite history to fit a summary. See [checkpoint audit](https://duhployed.com/learn/modules/checkpoint-audit.html).

## Imports and size checks

Use the actual character-card importer for supported PNG/JSON files. Its public UI says it reads metadata and generates a new display image; card import does not supply a visual reference photo. Inspect the populated editor before using the result. [Importer](https://ourdream.ai/character-import).

Portable-card JSON, native tracker configuration, prompt text, and external code are different artifacts. Import acceptance does not demonstrate lorebook execution or preservation of every source feature. Character counts, UTF-16 units, bytes, and model tokens are different measures; use observed field validation rather than an advertised capacity as a context budget.

## Art and CPDs

For a character that changes form, keep form identity, transition stage, and the accepted event separate. Resolve a current visible appearance that retains unchanged anchors as well as deliberate changes; a list of changes alone may be incomplete. Reconcile it with the actual route's saved appearance, presets, and selected Edit source. The [current-form continuity module](../modules/current-form-continuity.html) provides an optional worksheet and unrun checks. Its record is not an automatic memory-to-image connection or a native simulation.

Keep CPDs focused on stable visible traits and reconcile overlapping presets and Face Details. Put temporary attire, expression, and setting in scene instructions. Choose the actual image model and route before writing a prompt. Follow the [art workflow](art.html) and use the [prompt compiler](compiler.txt) for a focused draft.

## Text formatting and controls

Prefer ordinary readable text. Asterisks around actions are documented; test additional formatting on the current message surface before depending on it. Code blocks and comments do not create private memory or executable instructions. [Action formatting](https://help.ourdream.ai/en/articles/7617921).

Use Persona for user identity, Custom Instructions for persistent response rules, and /direct for temporary next-reply guidance. Record the actual selected chat model and settings; begin with defaults and change one control at a time. [Instructions](https://guide.ourdream.ai/chat/personas-and-instructions), [chat controls](https://guide.ourdream.ai/chat/chat-controls).

Model lists on public marketing pages and guide tables can differ. Availability, prices, limits, and controls are dated documentation claims; inspect the current selector, field validation, and displayed charge for the actual route. Do not infer backend model identity, a universal context budget, or guaranteed field priority from a package name or community assertion.

## Check before adopting

The optional [scenario worksheet](../modules/scenario-engineering.html) organizes premise, legitimate access, cast knowledge, opportunities, and the launch moment. Its `SCE` labels are editorial, and the supplied guide's `ADP` terminology is adapted to the documented APD field. ED can hold rules, lore, supporting cast, and systems as well as presentation guidance. Keep the current shared native-group setup separate from individual openings.

The [affection tracker review](../modules/affection-tracker-review.html) separates a classification rule, the actually applied delta, day budget, display band, roster, and outfit evidence. An import-looking JSON object is not evidence that every property executes natively. A relationship score is authored story state; it does not authorize decisions that belong to the user.

Try cooperative, skeptical, and brief replies. Check user agency, voice, knowledge ownership, consequential state changes, and a return from a saved checkpoint. For images, compare identity and the requested change separately. Save the effective input, route/model, settings, outputs, and failures. Keep only improvements that recur in the intended workflow; a single success is not a success rate. [Character testing](https://guide.ourdream.ai/characters/test-and-release).

Separate three questions: does the current documentation support the claim; does our local tool implement its stated behavior; does the selected OD model reliably follow the prompt? Source review and software tests answer the first two. Native efficacy requires recorded website trials. Unrun trials remain unrun. The [source review and verification records](https://duhployed.com/learn/source-review.html) document that distinction.

Use **pass**, **fail**, or **uncertain** against a criterion written before the test. Mark unavailable controls **blocked** and unattempted trials **not run**; neither is a pass. Record the trial date and accepted reply/output so a later model or interface change does not silently inherit an old result.