# State Trackers

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

> **November 1 source check:** The progression and systems guide was re-read and still displays July 27, 2026 as its modification date. It supports configuring and inspecting native trackers; it does not verify a supplied JSON schema, exact update timing, or rollback behavior. No new native tracker trial was run.

[ Tutorial index](README.md)

## 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](https://guide.ourdream.ai/characters/progression-and-systems). 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

1. **Locate the native control.** In the character editor, try **Details → Advanced Details → State Trackers**, when visible. This path appears in the owned [creator walkthrough](https://main.ourdream.ai/sex-chat/create-custom-ai-character). 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.

2. **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.

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

   ```text
   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.
   ```

4. **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.

5. **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.

6. **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.

7. **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.

8. **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](../modules/ourdream-prompt-lab.html) 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](examples/Native_Creator_Test_Log.csv). 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](../modules/affection-tracker-review.html) 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](../modules/checkpoint-audit.html) with your record. All examples here remain proposed criteria until tested in the actual chat.

Next: revisit [Memory and continuity](12_Memory_and_Continuity.md), or return to the [ Tutorial index](README.md).