Checkpoint audit module

A checkpoint preserves the information needed to resume a chosen story. It is context guidance. The local companion can replay its recorded events, while native OD memory and trackers require their own controls and inspection. Neither a prose checkpoint nor an aggregate count reconstructs omitted facts. Custody means who holds or controls an object; it does not automatically establish legal ownership.

Put each part in the right place

For a changing appearance, retain the accepted form, transition stage, relevant unchanged anchors, deliberately superseded traits, clothing, and source image identifier. Do not infer that a prose checkpoint changed saved appearance or an image input. The current-form module provides a local worksheet and proposed checks. Keep the accepted branch after regeneration rather than merging incompatible forms.

Use Scenario for starting world rules and initial circumstances; APD for durable personality; ED or Custom Instructions for response behavior; Pinned Memories for selected continuing chat facts. Keep the selected Persona for user identity. The memory guide distinguishes the native memory jobs.

Use a separate local backup for the coded companion. Its resource, item names, flags, owner, location, and accepted events are not a complete character-knowledge or object-custody model. A companion backup, portable card, native tracker configuration, and narrative checkpoint are different artifacts.

Inspect completeness before resuming

Retain only fields the story needs, but do not replace consequential identities with a count:

• Revision and accepted timeline: which reply/outcome is retained after edits or regeneration.
• Location, actual present cast, valid remote channels, and current task.
• Story time and units, with one chosen clock/resolution policy if time matters.
• Relevant object identity, holder/custody, location, condition, and access.
• Known/estimated/unknown resources; unknown is not zero.
• Individual facts, claims, beliefs, evidence, and legitimate acquisition paths.
• Actual permissions, available options, event flags, or gate/route state when used.
• Consequential incident identities, already-counted effects, and unresolved choices.
• Required missing facts and where to recover them.

Game turn owner, selected native respondent, and item holder are separate concepts. Do not silently substitute one for another.

Original checkpoint example

Destination: local notes, then a reviewed Pinned Memories draft if needed. Use this only after the described events are accepted.

Revision: archive-delivery-02
Accepted timeline: route attempt A17-route-01 failed; later handover accepted.
Location: eastern records office.
Present: traveler and Rowan. Mira was last established at the archive.
Time rule: Time is delivery opportunities, not minutes; remaining 2.
A17: accepted by records office; sealed at handover.
R-A17: issued once; held by traveler.
Counted delivery incidents: R-A17.
Delivery count: 1, derived from those incident identities.
Knowledge: Rowan witnessed acceptance. No transmission to Mira is recorded.
Open choice: how to notify Mira.
Unknown: whether Mira has an independent report; do not assume she knows.

If Mira did join the journey, change her presence/knowledge to match that accepted scene. Do not copy this sample over an existing story.

Reconcile the completed response

1. Identify what the user proposed, attempted, or explicitly corrected.
2. Read the accepted character/narrator reply for the actual outcome.
3. Record only established changes; do not award a receipt at the offer stage.
4. Match the incident to an existing identity before counting.
5. Inspect affected values and preserve the source event.
6. Update the resume record after the accepted outcome, including any new NPC fact.
7. On conflict, identify the disputed fact and choose/recover the accepted timeline explicitly.

A receipt created in the NPC reply must reach the final checkpoint. A hypothetical, quoted example, or retelling is not a new delivery.

Separate the resume facts from the response instruction

Remember everything and never contradict the story does not identify what must survive. After the accepted handover, a concise checkpoint payload can say:

Accepted handover: R-A17 issued once by the eastern records office.
Parcel A17 is with that office; the traveler holds R-A17.
Rowan witnessed the acceptance. Mira has not yet been informed.
Open choice: whether and how the traveler contacts Mira.

Keep the response rule separate: Continue from the accepted handover and leave the contact decision to the traveler. Put that rule in your maintained ED or Custom Instructions location if needed. Update changing location or phase text when it becomes obsolete; do not keep an older opening-state pin that returns A17 to the archive. The memory guide, modified July 27 and accessed October 31, 2026, distinguishes a changing summary from selected anchors and warns that later regeneration can replace manual summary edits.

If the summary omits the receipt, an original chat correction is: The retained clerk reply issued R-A17 once. Include that receipt in any recap; keep the existing route failure and remaining Time unchanged. Inspect and, where supported, correct the actual summary through its memory controls. The chat request neither edits a local ledger nor guarantees native memory repair. Save the accepted reply reference so you can distinguish a missing fact from an invented replacement.

Incident identity and local code

For the real local ledger, repeating the same event ID and payload is idempotent; a changed payload under that ID conflicts. A new random ID does not make a retelling a new incident.

One ledger event performs one operation. If a delivery has several effects, give them stable operation IDs under the same incident, such as R-A17/receipt-item and R-A17/parcel-removal. Review each accepted effect; the current API does not promise an atomic bundle. A failed operation must not be hidden by rewriting the story.

Local undo removes the last accepted local event. It does not undo OD, restore native memory, or erase Persona. Preserve a backup before rebuilding a changed accepted timeline.

Time and missing-state checks

If Mira checks a register and Rowan checks his bicycle during the same five-minute interval, world time advances five minutes. Ten minutes requires sequential intervals or another explicit rule. Printing two POVs does not itself spend twice the time. Offscreen plans are not an automatic background process; a later event/report must establish the result.

When a required record is missing, mark the gap. “Two deliveries happened” cannot identify their receipts, permissions, or already-awarded rewards. Recover the necessary record before claiming duplicate protection. Do not reset unknown state to an opening default or guess the missing history.

Proposed checks — all not_run

These are review criteria, not passed OD trials or guarantees of native transaction behavior.