Memory and continuity

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 memory guide was re-read and still displays July 27, 2026 as its modification date. The approximate cadence, documented pin capacity, and separately dated October 2 announcement below remain distinct. No new recall or memory-edit trial was run.

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.