The continuity desk · Independent notes on branching stories

Continuity check / 04

Make findings reproducible

A warning is the beginning of a report

The model noticed a possible contradiction. The next task is not to make that warning sound more certain. It is to give another person enough evidence to investigate it independently.

A concise ticket protects review time and makes room for a different interpretation.

A narrative issue combines an observation with a claim about what should happen. Keep those parts separate. The observation may be repeatable even when the expected behaviour still needs a design decision.

Name the observable mismatch

Use a title that helps a reviewer locate the problem: “Gatekeeper addresses player as key holder after transfer to Mara” is better than “AI found a plot hole.” The first identifies the speaker, state and symptom. The second identifies the detection method but says little about the game.

Record the build, platform, language and relevant content configuration. Attach a starting save where permitted, or describe a reliable path from a supported checkpoint. Include stable scene and line identifiers rather than relying on page numbers that may change with the next script export.

Reduce the reproduction without losing the cause

Begin with the full failing trace, then remove actions that are not needed. Replay the shortened route rather than assuming removed choices were irrelevant. A conversation that looked optional may have set a hidden flag, and a location visit may have advanced a timer.

The minimal reproduction should preserve the state that triggers the problem. If a debug command creates that state, label it clearly and also say whether a normal player route has been confirmed. An impossible debug combination may still reveal brittle logic, but it has a different production impact from a routinely reachable state.

Illustrative reproduction steps1. Load a supported courtyard save with key_owner=player. 2. Select “Give Mara the brass key.” 3. Confirm the transfer action completes. 4. Enter north_gate without any return-key action. 5. Speak to the gatekeeper. 6. Observe GATE_042 and capture the current key_owner value.

Cite the expected behaviour

Link the expectation to a design rule, accepted script note, quest specification or approved prior decision. If none exists, write a question rather than inventing a requirement. “Should this line be conditional on player ownership?” invites a useful answer. “This must be rewritten” assumes a resolution before the cause is known.

For an AI-assisted finding, include the exact candidate warning and enough information to identify the model configuration used. Where available, record the model identifier, prompt revision and input selection. Do not invent deterministic reproducibility: an external model can change, and repeated generation can differ even with similar settings.

Separate three levels of confidence

First, an automated candidate is an unverified concern raised by a model or rule. Second, an observed mismatch has supporting runtime evidence but may still need interpretation. Third, a confirmed defect has been assessed against an agreed expectation. Teams can use different status labels; the important point is that the transitions are explicit.

A percentage produced by a language model is not automatically a calibrated probability. Avoid displaying it as a measured likelihood of a bug. More useful confidence information names what is known: the trace was replayed, the state was inspected, the design rule was confirmed, or the excerpt remains incomplete.

Prioritise player impact, not rhetorical certainty

Severity depends on consequence. A blocked main quest, a prematurely revealed mystery and an awkward optional line are not interchangeable. Explain whether the issue prevents progress, invalidates a consequential choice, undermines a central reveal or merely changes tone. Frequency and affected routes should be reported separately from severity.

Do not infer frequency from the number of AI warnings. Ten warnings may describe one faulty condition repeated across ten lines. Group related symptoms under a shared cause when the evidence supports it, but retain each affected line so the eventual fix can be checked thoroughly.

Handle duplicates and intentional exceptions

Before opening another ticket, search by line ID, quest flag and symptom. Existing reports may use a different narrative description for the same failure. A duplicate link is valuable because it preserves additional paths without creating parallel resolution histories.

If the writer confirms deliberate ambiguity, record that decision with a bounded explanation. The disposition should help future reviewers understand why this specific line is acceptable. It should not instruct automation to ignore every apparent knowledge gap or every statement made by that character.

Verify the change and the neighbouring paths

After a fix, replay the original reproduction on the target build. Then test the nearest contrasting route, such as retaining the key instead of transferring it. Inspect related subtitles, journal entries and voiced variations when the change affects line selection. A correct script edit can still be missing from the packaged content.

Close the ticket with the verified build and the checks performed. If a test could not be run, say so. Clear closure notes prevent a successful narrow check from being mistaken for complete story certification.

Protect unpublished material

Issue evidence can contain spoilers, personal information or confidential production assets. Use the project's approved tracker and access controls. Before sending excerpts to an external AI service, review its retention, training and contractual terms with the responsible team. Redaction must preserve the relevant conditions; otherwise the resulting warning may no longer describe the actual story.

This site provides editorial methods, not a hosted analysis service. The local note tool can prepare general feedback about these guides, but it does not test scripts, upload attachments or submit an issue to your production tracker.