23 Test a change and diagnose a failure

Review scope: Linked public documentation checked October 30, 2026. Examples are proposed checks, not recorded OD results; use your account's current controls.

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

1. 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.
2. 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.
3. 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?

4. 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.
5. 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.
6. 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.

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.

Check non-graphic voice, pacing and consent

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.