What Can a Missing Character’s AI Assistant Really Know in a Mystery Game?
For a fictional mystery game, an AI assistant should know only the story records the author has made available to it—and only from the point in the story when those records become accessible. Give every fact a source, a time it became known, and an access rule. This lets the assistant help players connect clues without quietly becoming an all-knowing narrator.
Separate the story’s records from the assistant’s access
Start with a complete author-facing record of the story: events, character statements, objects, messages, and the order in which they enter play. Then define a smaller view for the assistant. A fact can exist in the story bible without being available to the assistant yet. That distinction is the foundation of a fair mystery: the author may know what happened, while the assistant can only use records its fictional role permits it to see.
Interactive-fiction tools such as Twine organize stories into passages and can use variables and conditional logic to change what a player sees. That provides a useful design analogy: treat each authored record as a discrete unit, and make access to it conditional on the relevant passage, event, or choice. Twine’s basic concepts
For example, suppose a fictional character named Mara is preparing a community garden display. The assistant might have access to a planning note she shared, a schedule posted to the group board, and a later message she sends about moving painted signs indoors. It should not infer where Mara is from merely knowing she enjoys gardening, and it should not see a private draft that was never shared with it. Those limits come from the story’s authored access rules, not from a claim about what real AI systems can access.
Give each fact a source and a known-at time
A useful fact record answers at least four questions: what is being claimed, who or what supplied it, when it became available to the assistant, and whether it is direct or inferred. The W3C provenance model describes the origins of information in terms of entities, activities, and agents; it also allows records to describe how one item was derived from another. That is a practical framework for fictional records, even if a game uses simple labels instead of the formal model. W3C PROV Model Primer
A compact record might look like this:
Claim: Mara planned to paint the garden signs; Source: Shared planning note; Known to assistant from: Monday, 10:00; Kind: Direct statement
Claim: The signs were moved indoors; Source: Group-board update; Known to assistant from: Tuesday, 16:30; Kind: Direct update
Claim: Mara may have moved them because rain was forecast; Source: Weather note plus update; Known to assistant from: Tuesday, 16:30; Kind: Inference; unconfirmed
The example times are illustrative. The important distinction is between when an event happened and when the assistant learned about it. If a note created Monday is shared Tuesday, the assistant’s knowledge begins Tuesday unless the story explicitly gives it earlier access. Preserve both timestamps when they differ.
Keep observation, report, and inference distinct
A source does not automatically make its contents certain. A character may describe what they saw; a note may be incomplete; a schedule may record a plan rather than an action that actually occurred. Labeling the record type helps the assistant phrase its response accurately: “The board says the signs were moved” is different from “Mara moved the signs,” and both differ from “She probably moved them because of the weather.”
Use a small vocabulary consistently: direct observation, character report, authored record, and inference. An inference should point back to its supporting records and remain marked as an inference. W3C PROV explicitly models agents’ responsibility for activities and the derivation of one entity from another; applying that distinction to dialogue helps a game show where a conclusion came from instead of presenting it as a fresh fact. W3C PROV-O
This also creates a useful authoring test: can a player trace a confident assistant statement to a record it was allowed to access? If not, revise the answer, add the missing authored record, or have the assistant say it does not have enough information.
Define access in story time, not just by character
For every record, specify the event that unlocks assistant access. A shared message might be available as soon as it is sent; a notice pinned to a board might be available when the assistant checks the board; a conversation might become available only after the player chooses to ask about it. Avoid relying on vague labels such as “the assistant knows everything in the archive” unless the story establishes what that archive contains and when it is updated.
A practical access rule has three parts: the record’s audience, its availability trigger, and any delay. For instance: “The assistant can read group-board posts after the player opens the board; it cannot read personal drafts.” The delay matters in branching stories. If a player has not visited the board, the assistant should not behave as if it has seen the latest post just because that post exists elsewhere in the author’s files.
In Twine, story variables can be available across passages, while temporary variables are limited to the current passage in Harlowe and SugarCube. That difference illustrates why authors should decide deliberately whether a fact persists across the whole story or belongs only to a particular scene. The exact implementation depends on the story format, so treat the rule as a design model rather than code instructions. Twine Cookbook: Variables
Make uncertainty useful to the player
When a record is missing, old, or ambiguous, let the assistant describe the gap in concrete terms. It can say it has the Monday plan but no later confirmation, or that one character reported moving the signs while the board contains no update. This gives the player a meaningful next step: check another authored source, revisit a character conversation, or decide that the clue remains unresolved.
That approach supports mystery without arbitrary omniscience. Research on interactive narrative has examined how limited knowledge can shape player behavior, including a study using the interactive fiction *Anchorhead* to explore player models. For an authored assistant, the design implication is modest: what the player and assistant have learned can affect their next choices, so track those knowledge states explicitly. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”
A quick audit before writing assistant dialogue
Before drafting a response, check these points for each consequential claim:
Is the claim present in an authored record, or is it labeled as an inference?
Does the record name its source and distinguish a plan, report, observation, or later confirmation?
At what story time did the assistant gain access to it?
Does the assistant’s fictional role permit access to that source?
If the record is incomplete or conflicting, does the dialogue preserve that uncertainty?
If the answer to any of these is unclear, narrow the assistant’s statement until it matches the available record. The resulting character can still be helpful: it can summarize what it has seen, identify what remains unconfirmed, and point the player toward the next authored clue. Its reliability comes from a visible boundary between the story’s full record and the information it has actually received.