How to Build a Question-Driven Character Contact List Without Leaking Hidden Scenes
A question-driven contact list works when every answer has a clear source, a discovery condition, and a visibility rule. For each character, record what they personally observed, what someone told them, what they can reasonably infer, and what they do not know yet. Then route ordinary story questions to the characters whose knowledge supports an answer. This makes the list useful while keeping future scenes and undiscovered facts out of dialogue.
Start with questions readers might actually ask
Choose a narrow set of ordinary questions tied to the story: Who has the spare key? Where did Mira leave the sketchbook? Who agreed to bring the folding chairs? These are easier to route than broad prompts such as “What is happening?” or “Tell me about the town.” A good question has an answer that can be traced to an event, an object, a conversation, or a clearly marked inference.
Write each question in a question ledger with four fields: the answer, the source event, the earliest point at which it can be answered, and which characters are allowed to answer. For example, “Who has the spare key?” might be answered by Jo after she receives it in the opening scene. Until then, the list should say “not established” rather than guessing. This distinction keeps a missing fact from turning into accidental canon.
Give every fact a source and a knowledge type
Treat story facts as evidence records, not as a shared pool that every character can draw from. A compact record might look like this:
Fact: Jo has the spare key; Source: Jo takes it from the hook in Scene 2; Knowledge type: Observed / possessed; Earliest discovery: After Scene 2; Visibility: Jo; anyone she tells
Fact: The hall is booked for Saturday; Source: Confirmation note on the noticeboard; Knowledge type: Read; Earliest discovery: After a character sees the note; Visibility: Characters who read it
Fact: The chairs will fit in the van; Source: Jo compares their sizes; Knowledge type: Inference; Earliest discovery: After she checks both; Visibility: Jo, phrased as an estimate
Use a small, consistent set of knowledge types. “Observed” means the character was present and could perceive the event. “Told” means another character passed on the information. “Read” means they encountered a note, message, sign, or other record. “Inferred” means they drew a conclusion from evidence, which should be phrased as a belief or estimate rather than a confirmed fact. “Unknown” means the story has not given them a route to the information.
This structure is an editorial design rule, not a feature guaranteed by any writing tool. It follows from a practical distinction: state tracking can record changes, but the writer still decides what the state means. Ink’s documentation describes flexible state tracking while noting that it does not provide a complete world-modeling system; Twine’s documentation likewise distinguishes globally available story variables from local temporary variables. Those mechanics can help represent a story’s state, but neither automatically determines what a character should know. (Ink: Writing With Ink, Twine Cookbook: Variables)
Add discovery gates instead of revealing by convenience
A discovery gate states what must happen before a fact becomes available. Keep it observable and specific: “after Jo reads the noticeboard,” “after Lee tells Pat,” or “after the group opens the supply box.” Avoid gates such as “once the story is ready,” which are difficult to apply consistently.
Separate the event that makes a fact true from the event that makes a character know it. The hall can be booked before Jo reads the confirmation. Lee can move the spare key without telling anyone. When a gate opens, update only the characters who had access to that particular route. If a character misses a conversation, do not silently grant them the information because the reader saw it.
For interactive stories, gates can be represented with variables and conditional passages. The Twine Cookbook explains that SugarCube’s <<if>> and <<else>> sections show content according to a condition; Ink also supports state changes and branching choices. These are implementation options for showing or withholding a line. The story still needs a clear rule for setting the condition—for example, recording that a specific character read the notice. (Twine Cookbook: “Conditional Statements”: SugarCube, Ink: Writing With Ink)
Track shared facts without making them universally visible
A fact can be shared with a group, a pair, or nobody beyond its source. Record the audience explicitly: “Jo and Lee heard the plan,” “all three characters were present,” or “only Pat has seen the note.” Do not use “everyone knows” as shorthand unless the story includes a moment when everyone learns it.
A useful rule is to model each transfer as its own event. If Lee tells Jo that the chairs are in the shed, Jo gains a told-source record; Pat does not. If Jo later texts the group, the story can update the recipients named in that message. If the message is merely drafted or sent to one person, it should not become common knowledge by implication.
Also distinguish shared truth from shared interpretation. Several characters may know that the hall is booked for Saturday while disagreeing about whether the space is large enough. The factual record can be common; the estimate belongs to the people who made it. This keeps dialogue varied without changing the underlying event.
Route each contact-list answer through a simple check
Before a character answers, run the question through this sequence:
Identify the exact fact the question requests. Split compound questions into separate facts if needed.
Find the source event that establishes each fact. If there is no source, mark the answer unknown or not yet established.
Check whether this character observed, was told, read, or inferred the fact.
Check whether the relevant discovery gate has opened at this point in the story.
Match the wording to the knowledge type: a direct answer for confirmed knowledge, an attributed answer for hearsay, or qualified wording for an inference.
Remove details that come from a later scene, a private viewpoint, or a source the character has not encountered.
For the key example, Jo can say, “I have the spare key,” after taking it. Lee can say, “Jo told me she has it,” after that conversation. Pat, who has not seen or heard about the key, should not answer with certainty. If Pat guesses from an empty hook, the answer should sound like a guess and remain marked as such. The contact list can therefore be responsive without becoming an all-knowing narrator.
Test the boundaries with missing and partial knowledge
Test ordinary questions against several story moments: before the source event, immediately after it, after one character shares it, and after the wider group receives it. The answer should change only when the relevant gate changes. Include a question whose answer is genuinely unknown; a reliable list needs a safe way to say “the story has not established that yet.”
Check partial facts too. A character may know the delivery is due Saturday but not know the time. They may have seen a sketchbook on a table without knowing who left it there. Preserve the known portion and leave the rest open instead of filling gaps with plausible invention. If the story uses scene headings, keep the source scene identifiable; Fountain’s syntax guidance describes scene headings as a distinct script element, which can provide a convenient reference label in a screenplay workflow. (Fountain: Syntax)
When a response fails the check, revise the source record, the discovery gate, or the answer text—whichever is actually wrong. Do not patch a leak by making every character forget the same fact. A small, explicit knowledge ledger gives each contact a believable boundary and lets readers ask useful questions without learning hidden scene information early.