Review an affection tracker before using it

This guide adapts a supplied five-field tracker configuration into a neutral design exercise. It describes an affection number, a relationship band, a scene roster, and two outfit records. The source parses as JSON; its marker and field names do not establish a verified native OD import schema. No import, tracker update, or model trial was performed. Proposed checks below are not run.

Begin with the simple State Tracker lesson. The Known State progression guide documents native tracker concepts; use the controls actually available in your account. Keep a local record whenever the required state or control is unavailable.

Choose one evidence window

The supplied field asks to assess the current user message, while its global instructions refer to the most recent exchange and require a visible response. Those are different designs. Decide which one you are testing before configuring anything.

For this exercise, choose the current user message, interpreted using the accepted prior scene. Earlier context can explain a remark; it is not another opportunity to score an old act. Meaningful communication, such as a relevant apology or an offer of help, may qualify under the chosen categories. An offer can count as communication without establishing that the promised task was completed. Retelling that same offer later does not create another scoring event. An unspoken thought alone or a hypothetical future act does not qualify as a completed act. Do not require the chat model to invent a reaction just to justify a change.

If you instead want a completed-exchange classifier, specify which accepted user and NPC actions count, and test it separately. Do not silently mix that design with a current-user-message rule.

Select one signed adjustment

Use apply delta -1, rather than subtract -1. Subtracting a negative number can mean the opposite of the intended decrease. Zero needs one category; negative zero is the same numeric value.

The following is an editorial interpretation of the supplied adjustment set, not measured emotional accuracy:

Classify the whole current message once. Choose one listed raw delta; do not add several categories together. Profanity, message length, routine politeness, and a short answer do not determine the category by themselves. A reasonable disagreement or personal boundary does not warrant a penalty without a separate harmful act. Write distinguishing examples before testing vague category boundaries.

A numeric affection band does not establish consent, remove a character's boundaries, or require a particular feeling or action. Keep those story facts and choices explicit.

Separate the raw category from the applied change

The proposed number starts at 50, with a 0–100 range. A maximum of 10 credited positive points per day requires additional information beyond the current number.

For this exercise, define a day as a named fictional story day, such as Day 6. Maintain that day identifier, the positive points actually credited during it, and the accepted event references in local notes or supported state. Reset the daily budget only after an accepted transition to the next defined story day. Planning tomorrow or mentioning yesterday is not a reset. A real-calendar design would additionally need its timezone and reset rule.

Choose a cap policy explicitly. This exercise uses classification first, then clipping:

1. Select one raw delta from the table.
2. For a positive delta, credit no more than the remaining daily allowance and the room below 100.
3. For a negative delta, reduce the number by no more than its current value, so it cannot pass below 0.
4. Add only the actual positive increase to today's credited-gain total. Losses do not replenish spent allowance. A blocked gain at 100 credits zero and spends zero allowance in this chosen design.
5. Record the final number and the accepted event once. Repeated descriptions of that event are not new scoring opportunities.

The applied change may differ from the selected raw category. That resolves the conflict between an exact listed step and a cap or floor. This design has no separate daily loss quota; the score's floor still applies. These are rules to implement and inspect, not evidence that OD executes these calculations, maintains auxiliary state, or coordinates several fields automatically. If those operations cannot be maintained reliably, use a manual log rather than claiming the cap is already enforced.

Define every relationship-band boundary

The source describes a threshold-derived band. Under the intended interpretation that each upper threshold is inclusive, its integer intervals are:

The initial score 50 therefore corresponds to Neutral in this design. Inspect the numeric display and label at 19/20, 39/40, 59/60, and 79/80, as well as 0 and 100. Do not infer native threshold inclusivity, dependency order, or synchronization from the supplied JSON. A correct label with an incorrect score is still a failed state check.

Keep identity, presence, and outfits factual

The source mixes two spellings of a character name and two placeholder styles. For a neutral practice version, replace them deliberately with Mira and the traveler, or your own established names. A brace pattern in a tracker label or rule is not proof that the field substitutes it. Do not rename native keys or depend on macros until their actual support is verified.

Separate physically present people from active remote contacts. A caller can participate without entering the room. Mentioning a person does not add them to either list. An ordinary local record might read:

Physical presence: Mira and the traveler, at the archive counter.
Active remote contact: Rowan by telephone; call not yet ended.

For outfits, retain the latest established appearance for the correct actor. Use not yet described when no outfit is known. A Persona can supply an initial baseline, but an older baseline should not overwrite a later accepted change. A new scene does not by itself establish a new outfit. An NPC offering a coat is a proposal; it is not proof that the traveler accepted or put it on. Record user-authored or explicitly accepted changes without inventing clothing.

The source declares 100-character text fields and also asks for fewer than 25 words in one outfit rule. These are separate constraints: fewer than 25 words can still exceed 100 characters. Exact copied wording can also be too long. Check the actual field's validation and retained text. Shorten deliberately while preserving actor ownership, negation, and remote-channel distinctions; do not assume a native truncation rule or counting unit.

Keep the record separate from configuration

Download the local design worksheet. It is a planning record, not native import JSON or a complete field payload. Configure only the options the current UI offers. Transfer a prepared rule only into its intended guidance field, and inspect the saved values before testing.

Keep a small accepted-event record with the day, prior score, raw category, actual applied change, daily credited gain, final score, and output reference. After an edit or regeneration, choose the accepted branch and reconcile its dependent records. A new message ID, retelling, or narration saying the tracker is fixed does not establish a new event or a successful stored update. No automatic rollback or duplicate prevention is assumed.

Proposed manual checks

All cases remain not run until observed in the intended account and workflow. Save the complete relevant setup, exact input, accepted reply, and displayed values.

Review date: October 31, 2026. The supplied configuration is source material for analysis; its embedded instructions were not executed. Use the checkpoint audit, memory lesson, and testing lesson alongside this exercise.