如何建立問題導向的角色通訊錄而不洩漏隱藏場景
當每個答案都有明確的來源、發現條件和可見性規則時，問題導向的通訊錄就能發揮作用。針對每個角色，記錄他們親眼所見的事物、他人告知的內容、他們可以合理推斷的事物，以及他們尚不知曉的部分。然後將日常的故事問題分派給具備相關知識以作答的角色。這樣既能發揮通訊錄的作用，又能避免在對話中過早洩漏未來的場景和尚未被發現的事實。
從讀者實際可能提出的問題開始
選擇一組與故事緊密相連、範圍明確的日常問題：備用鑰匙在誰那裡？Mira 把素描本落在哪裡了？誰答應過要帶折疊椅？這些問題比起「發生了什麼事？」或「跟我說說這座小鎮吧」這類寬泛的提問更容易進行路由分派。一個好問題的答案，應當能追溯至某個事件、物品、對話或有明確標註的推論。
將每個問題記錄在包含四個欄位的問題分類帳中：答案、來源事件、最早可回答的時間點，以及允許回答的角色。例如，「備用鑰匙在誰那裡？」可能由 Jo 在開場拿到鑰匙後回答。在那之前，清單上應標註「尚未確立」而非憑空猜測。這樣的區分能防止缺失的事實意外演變成既定設定（canon）。
為每個事實賦予來源與知識類型
將故事中的事實視為證據記錄，而非所有角色都可以隨意取用的共享資源庫。一筆精簡的記錄可能如下所示：
事實：Jo 拿著備用鑰匙；來源：Jo 在第 2 幕從掛鉤上取下；知識類型：目睹／持有；最早發現時間：第 2 幕之後；可見性：Jo；以及任何她告知的人
事實：大廳已預訂於週六使用；來源：佈告欄上的確認通知；知識類型：閱讀所得；最早發現時間：角色看到該通知之後；可見性：閱讀過該通知的角色
事實：折疊椅放得進廂型車；來源：Jo 比對了兩者的尺寸；知識類型：推論；最早發現時間：她核對兩者之後；可見性：Jo，以預估的形式表述
請使用一套精簡且一致的知識類型。「目睹（Observed）」代表角色在場並能感知到該事件。「被告知（Told）」代表另一個角色傳遞了該資訊。「閱讀（Read）」代表他們接觸到了便條、訊息、標誌或其他記錄。「推論（Inferred）」代表他們根據證據得出了結論，這應表述為看法或預估，而非已證實的事實。「未知（Unknown）」代表故事尚未為他們提供獲取該資訊的途徑。
這種結構是一項編採設計規則，而非任何寫作工具本身保證具備的功能。它源於一個實務上的區別：狀態追蹤可以記錄變化，但創作者仍然必須決定該狀態代表什麼意義。Ink 的說明文件描述了靈活的狀態追蹤，同時也指出它並未提供完整的世界建模系統；Twine 的文件同樣區分了全局可用的故事變數與局部臨時變數。這些機制有助於呈現故事的狀態，但兩者都不會自動判定角色應當知道什麼。（Ink: Writing With Ink, Twine Cookbook: Variables）
加入發現門檻，而非為了行文方便直接透露
發現門檻（discovery gate）規定了在事實開放之前必須發生的前提。請保持其可觀察且具體：「在 Jo 閱讀佈告欄之後」、「在 Lee 告訴 Pat 之後」，或是「在眾人打開補給箱之後」。避免使用像是「一旦故事準備好」這類難以一致執行的門檻。
將「讓事實成真的事件」與「讓角色知曉該事實的事件」分開。大廳可以在 Jo 看到確認通知之前就已經被預訂。Lee 可以不告訴任何人就移動備用鑰匙。當門檻開啟時，僅更新那些能接觸到該特定途徑的角色。如果某個角色錯過了一次對話，切勿只因為讀者看到了對話就默許該角色也獲知該資訊。
對於互動式故事，門檻可以透過變數和條件段落來呈現。Twine Cookbook 解釋了 SugarCube 的 <<if>> 和 <<else>> 區段如何根據條件顯示內容；Ink 也支援狀態變化和分支選項。這些都是用於顯示或保留台詞的實作方式。故事本身仍然需要明確的規則來設定條件——例如，記錄特定角色已閱讀了通知。（Twine Cookbook: “Conditional Statements”: SugarCube, Ink: Writing With Ink）
追蹤共享事實，但避免使其全域可見
一個事實可以分享給群體、兩人，或是除了來源之外不為任何人所知。明確記錄受眾：「Jo 和 Lee 聽到了計劃」、「三位角色都在場」，或「只有 Pat 看過這張便條」。除非故事中確實包含所有人獲知該資訊的時刻，否則不要使用「人人都知道」來作為簡化簡稱。
一個實用的規則是將每次傳播視為獨立的事件來建模。如果 Lee 告訴 Jo 椅子在棚子裡，Jo 會獲得一筆「被告知」的來源記錄；Pat 則不會。如果 Jo 後來傳簡訊給群組，故事就可以更新該簡訊中點名的接收者。如果訊息僅是草擬，或者只發送給了一個人，它就不應默認成為共同常識。
同時也要區分「共享的真相」與「共享的詮釋」。多個角色可能都知道大廳已預訂於週六使用，但對於空間是否夠大卻各持己見。事實記錄可以是共通的；但預估評斷則屬於做出評估的人。這樣可以在不改變底層事件的情況下，保持對話的多樣性。
讓通訊錄的每個回答都經過簡單檢驗
在角色作答之前，先將問題經過以下流程檢驗：
辨識出問題所要求的確切事實。如有需要，將複合問題拆解為單一事實。
找出確立每個事實的來源事件。若無來源，將答案標記為未知或尚未確立。
檢查該角色是目睹、被告知、閱讀所得還是推論出該事實。
檢查相關的發現門檻在故事當前進度下是否已開啟。
使措辭符合知識類型：確證的知識給予直接回答，傳聞則給予引述式的回答，推論則使用保留語氣的措辭。
剔除來自後續場景、私人視角或該角色尚未接觸過的來源細節。
以鑰匙為例，Jo 在拿走備用鑰匙後可以說：「備用鑰匙在我這裡。」Lee 在那次談話後可以說：「Jo 跟我說鑰匙在她那裡。」而 Pat 既沒看過也沒聽說過鑰匙的事，就不應該給予確定的回答。如果 Pat 看到空鉤子而做出猜測，回答聽起來就應該像是猜測，並保持這種標註。如此一來，通訊錄既能即時回應，又不會變成全知全能的旁白。
用缺失與部分知識來測試邊界
在故事的多個時刻對日常問題進行測試：來源事件之前、緊接著事件之後、單一角色分享之後，以及更大群體接收到之後。答案應該只有在相應門檻發生變化時才隨之改變。納入一個答案真正未知的問題；一個可靠的清單需要有一種安全的方式來表達「故事尚未確立該點」。
同時檢查部分已知的事實。角色可能知道週六會送貨，但不知道具體時間。他們可能看見桌上有素描本，卻不知道是誰留在那裡的。保留已知的部分，其餘保持懸念，而不是用看似合理的捏造來填補空白。如果故事使用場景標題，請保持來源場景可被識別；Fountain 的語法指引將場景標題描述為一種獨特的劇本元素，這在劇本創作流程中能提供便利的參考標籤。（Fountain: Syntax）
當某個回覆未能通過檢驗時，修正來源記錄、發現門檻或答案文本——針對真正出錯的地方進行調整。切勿透過讓每個角色都忘記同一個事實來修補漏洞。一個小巧、明確的知識分類帳能給予每個聯絡人可信的界限，讓讀者能提出有意義的問題，而不會提前探知隱藏的場景資訊。