A story variable is not the story itself. It is a compact agreement between design, code and prose. Testing becomes easier when that agreement is written down before an automated reviewer starts guessing what a flag means.
Write the smallest useful contract
For this example, define one authoritative field: key_owner, with permitted values player, Mara and gatekeeper. The transfer action changes ownership from player to Mara. The rule is not simply that “the key disappears.” It is that this unique object has one owner at a time, and dialogue that asserts possession must refer to the current owner.
A single enumerated field is often easier to reason about than three independent possession flags. Existing projects may already use those flags, however. In that case, encode the relationship explicitly: exactly one relevant ownership flag should be true after a completed transfer. Do not redesign production state merely to make a demonstration neat.
Record transitions, not just snapshots
A screenshot of the wrong line shows the symptom. A transition trace helps locate the cause. Capture the state before the choice, the action taken, the immediate result and the state when the disputed line is selected. Include any scene-entry logic that runs between those points.
| Moment | Expected state | Evidence to collect |
|---|---|---|
| Before transfer | key_owner = player | Save and debug snapshot |
| After give_key | key_owner = Mara | Action log and assignment |
| Gate dialogue | Player-possession line excluded | Line ID and evaluated guard |
Watch for a reset on scene entry, a cached dialogue condition or a restored checkpoint that overwrites the transfer. The script may be correct while the integration is wrong. Conversely, the runtime may accurately execute a faulty authored condition. Keep those explanations separate until the trace rules one out.
Use AI to propose checks, not establish truth
A language model can read a bounded excerpt and suggest that an ownership assertion needs a guard. Give it the variable definitions, the relevant actions and the intended rule. Ask it to identify unsupported assumptions and quote the line identifiers behind each candidate concern. A confident explanation without a trace is still a hypothesis.
Do not let the model silently invent a second key, an off-screen transfer or a hidden quest rule. Those may be legitimate design possibilities, but they need an authored source. A useful review prompt asks for three distinct outputs: observed text, inferred conflict and missing context. That separation makes editorial disagreement productive.
Connect checks to the actual runtime
In ink, investigate variables, conditions and the host integration together. In Yarn Spinner, inspect variable storage and commands as well as dialogue selection. Unity and Unreal Engine projects can keep important quest state outside the narrative file, so a script export may describe only part of the system.
Property-based testing can generate action sequences and check an invariant after each completed action. Hypothesis is one general-purpose option when a Python harness can drive the relevant model. It does not automatically understand ink, Yarn Spinner or your game's inventory. Someone must define the adapter, valid actions and expected properties.
Include saves, resets and delayed effects
Test the transfer across a save-and-load boundary. Check whether leaving and returning to the location restores stale ownership. If an animation or asynchronous command completes the transfer later, specify when the invariant must hold. A temporary intermediate state may be valid; a dialogue query that observes it too early may still be a defect.
Also test the inverse path: keeping the key should not accidentally suppress the legitimate possession line. A repair that removes every reference to the object can hide the original symptom while damaging a valid branch. Compare nearby choices, not only the one trace that first failed.
Decide what the finding actually proves
If the transfer trace shows Mara owns the key and the game plays a line whose documented condition requires player ownership, you have strong evidence of a defect. If the expected rule is undocumented, retain the finding as a design question. The distinction protects both the writer's intent and the QA record.
Attach the minimal save, build identifier, line ID and transition log. State which paths were checked and which were not. One verified example establishes that a problem exists; it does not establish its frequency or prove the rest of the story consistent.