世界給出了一個答案，但作者還想知道為什麼
故事寫到第三十八章。
作者點開 Rowan。
Inspector 告訴他：
Rowan 現在是軌道站指揮官。
他位於 Europa 前哨站。
他持有一枚白色通行核心。
他是緊急議會的成員。
他和 Ilya 的關係已經變成敵對。
他的壓力值目前是 7。
這些答案都是正確的。
但作者接下來想問的，不是 Rowan 現在是誰。
而是他為什麼會變成現在這樣。
Rowan 原本就是指揮官嗎？
他什麼時候抵達 Europa 前哨站？
白色通行核心是由誰交給他的？
他為什麼加入緊急議會？
他和 Ilya 的敵對關係始於哪一次事件？
壓力值又是從哪些經歷逐步累積到 7？
如果世界只能顯示最新狀態，這些問題就必須重新回到全文裡尋找。
作者知道答案存在於前面的三十七章。
卻不知道它們分別藏在哪裡。
世界能夠回答「現在是什麼」很重要。
但一個真正可以被信任的世界，還應該回答：
這個現在，是怎麼形成的？
最新資料保存結果，事件歷史保存來處
一般資料頁很擅長保存最新結果。
角色目前的職業。
角色現在的位置。
物品當前的持有人。
人物關係目前的狀態。
組織現在的領袖與成員。
這些資訊能讓作者快速掌握世界走到哪裡。
但如果最新狀態只是被直接覆蓋，舊狀態就會逐漸消失。
角色資料原本寫著工程師。
升職後改成指揮官。
再過一段時間，他退出組織，資料又被改成自由航行員。
最後一份資料可以正確顯示他現在是自由航行員。
卻無法回答他曾經何時擔任工程師、何時成為指揮官，以及什麼事件讓他離開原本的職位。
只保存最新答案，世界就像一張不斷被擦掉重寫的表格。
每一次修改都讓現在更準確。
也讓過去更難被看見。
InkWeave 的世界狀態不是靠直接覆蓋所有舊答案形成。
角色移動、物品轉手、屬性改變、人物關係變化、身分轉換與組織異動，都可以成為正文時間線裡的事件。
最新狀態是這些事件重播後的結果。
事件歷史則保留這個結果一路如何形成。
所以作者看見 Rowan 現在是指揮官時，不只得到一個職業名稱。
他還能回到真正讓 Rowan 成為指揮官的那一刻。
一個角色不只有一條歷史
我們經常把角色歷史理解成一段人物生平。
出生在哪裡。
經歷過什麼。
遇見過誰。
最後成為什麼樣的人。
這種敘述很適合讓人理解角色。
但世界模擬需要把其中不同種類的改變分開。
Rowan 有移動歷史。
他從地球研究中心前往軌道站，之後才抵達 Europa 前哨站。
他有狀態歷史。
他可能曾經失蹤、恢復活動，也可能在另一條世界線裡死亡。
他有屬性歷史。
壓力、傷勢、信任或其他自訂數值，會隨事件增加與減少。
他有種族與職業歷史。
他可能從工程師成為指揮官，也可能因為改造、契約或世界規則而改變身分類型。
他有人物關係歷史。
合作、信任、敵對與其他關係，不一定從角色第一次出場就保持不變。
他有物品歷史。
取得過什麼、失去過什麼、把什麼交給別人，都會改變後續行動能力。
他也有陣營歷史。
何時加入緊急議會、擔任什麼位置、是否退出，都屬於另一條組織時間線。
這些歷史共同構成同一個人。
卻不能被壓成一條模糊的「角色曾經發生過很多事」。
因為作者追問的位置不同，需要的答案也不同。
想知道 Rowan 為什麼在 Europa，要查看移動歷史。
想知道他為什麼能進入控制室，要查看通行核心的流轉與相關資格。
想知道緊急議會為什麼承認他，則要查看身分與陣營事件。
一個角色的現在，是多條歷史在同一刻交會的結果。
歷史不是每隔一段時間保存一張角色卡
作者當然可以替角色保存不同版本。
第十章的 Rowan。
第二十章的 Rowan。
第三十八章的 Rowan。
每隔一段時間複製一次角色卡，就能保留部分過去。
但這種方式很快會產生新的問題。
應該在哪一章建立版本？
兩張角色卡之間發生的細小變化由誰保存？
如果第十六章的一次事件被修改，作者要重新更新後面多少張角色卡？
哪一張才是目前可信的版本？
更重要的是，快照只能告訴作者某一刻的結果。
它不一定能說明兩張快照之間究竟發生了什麼。
InkWeave 不需要作者手動保存每一個階段的完整角色副本。
正文裡的事件本身就是歷史來源。
第十二章，Rowan 從工程師轉為指揮官。
第十七章，他移動到 Europa 前哨站。
第十九章，他取得白色通行核心。
第三十章，他加入緊急議會。
第三十四章，他和 Ilya 的關係轉為敵對。
因果律引擎沿著這些事件重播，便能推導不同時刻的世界切片。
游標停在第十章，世界仍然看見工程師 Rowan。
停在第二十章，世界承認他已經成為指揮官，也已經抵達 Europa。
停在第三十八章，後面更多事件的結果才會一起出現。
快照保存的是幾個被選中的現在。
事件歷史則讓每一個現在都能重新被推導。
壓力值是 7，不代表歷史只需要記住 7
Rowan 的壓力值目前是 7。
如果角色資料只保存這個數字，作者可以知道他現在承受多少壓力。
卻不知道 7 是怎麼來的。
第十四章的設備事故讓壓力增加 2。
第十八章抵達安全區後降低 1。
第二十三章失去一名隊員，再增加 3。
第三十四章遭到 Ilya 背叛，又增加 3。
這些事件共同把壓力推到現在的數值。
屬性歷史不只需要列出「曾經變更」。
它還要讓作者看見每次變動量，以及事件發生後的累計結果。
這樣作者才能回答：
哪一次事件讓壓力第一次超過危險門檻？
角色在第二十章時的壓力是多少？
如果刪除第十四章的事故，後面的數值會如何改變？
第三十四章的反應是否真的符合角色當時已經累積的狀態？
同樣的最終數值，也可以來自完全不同的歷史。
壓力值 7，可能是一次重大災難造成。
也可能是十幾次小事件逐步累積。
數字相同，不代表世界經歷過相同的事。
所以屬性歷史不能只保存最新答案。
它必須讓數值帶著自己的形成過程回來。
一件物品可以從不同視角追溯
白色通行核心現在由 Rowan 持有。
但這只是它目前的停留位置。
它在抵達 Rowan 手上以前，可能已經走過很長一段路。
最初，通行核心由軌道站系統配發給安全主管 Vera。
Vera 離開控制區以前，把它放進中央保管室。
前哨站遭到封鎖後，Ilya 從保管室取出核心。
幾章之後，Ilya 又把它交給 Rowan。
如果只看 Rowan 的持有物品，作者會知道他現在擁有通行核心。
但物品的完整歷史還能回答更多問題。
它最初由誰配發？
曾經經過哪些角色？
在哪些地點停留過？
是否曾經被放下、遺失或重新取得？
世界裡是否還存在另一枚同名核心？
InkWeave 可以從不同視角查詢物品歷史。
作者可以查看某件物品的系統分發紀錄。
可以查看這件物品完整的流動軌跡。
可以查看某名角色曾經取得或失去哪些物品。
也可以查看某個地點曾經接收或移走哪些物品。
需要時，還能從全域視角查看世界裡的系統分發事件。
同一筆轉交事件會同時影響角色、物品與地點。
但不同歷史視角會讓作者看見不同問題。
Rowan 的歷史回答他何時取得核心。
核心的完整軌跡回答它如何抵達 Rowan 手上。
中央保管室的歷史則回答它何時不再留在那裡。
世界只有一段歷史。
作者卻可以從不同實體的位置進入它。
地點現在沒有人，不代表從來沒有人來過
Europa 前哨站的實驗室目前是空的。
沒有角色停留。
重要設備也已經被移走。
如果只看當前狀態，這個地點可能像是一個沒有發生過任何事情的空房間。
但地點也有歷史。
Vera 曾經抵達這裡。
Ilya 在封鎖期間進入過。
Rowan 後來帶著通行核心來到這裡。
另一名角色可能曾經短暫停留，之後又離開。
地點訪客歷史讓作者知道誰曾經到過。
地點物品歷史則保存哪些東西曾經被放在這裡，又在什麼事件中被移走。
這種差別對調查、責任與敘事都很重要。
「目前沒有人在實驗室」只是一個當下答案。
「從來沒有人進入實驗室」則是一個完全不同的歷史判斷。
如果作者把兩者混在一起，就可能讓曾經發生過的事件被目前的空白洗掉。
一個地點不只由仍然留下的東西構成。
曾經來過又離開的人，也屬於它的世界歷史。
組織歷史不只保存主動發生的事
Rowan 加入緊急議會，是一次明確事件。
他取得指揮官職稱，也可以是一項明確的組織變化。
但組織裡不是每一個結果都由當事人主動發起。
假設安全主管 Vera 帶領兩名成員。
她退出組織時，創作者選擇讓整個下屬體系一起離開。
那兩名成員並沒有各自建立一筆主動退出事件。
但他們仍然受到 Vera 離開的結構性影響。
另一種情況下，Vera 離開後，下屬可能失去主管。
也可能向上重新連接到 Vera 原本的上級。
這些都是由離開政策推導出的衍生結果。
InkWeave 的陣營歷史可以從組織視角查看領袖、成員、職稱與上下級如何改變。
也可以從角色視角查看某個人何時加入或退出不同陣營。
當事件具有衍生影響時，歷史還需要保留：
這是直接事件，還是由另一件事推導出的結果？
影響源自哪個角色？
原本的主管是誰？
新的主管是誰？
使用了哪一種離開方式？
如果歷史只寫「成員已退出」，作者仍然不知道這個人為什麼離開。
當歷史能指出它源自 Vera 的級聯退出，組織現在的樣子才真正得到解釋。
歷史紀錄必須能帶作者回到正文
一份事件列表可以告訴作者：
第十九章，Rowan 取得白色通行核心。
但作者接下來可能想知道：
當時是誰交給他的？
那段文字究竟怎麼寫？
取得事件放在對話以前，還是對話以後？
是否應該修改數量、參與者或事件位置？
所以 InkWeave 的歷史紀錄不只保存事件摘要。
每筆歷史可以帶有章節、章節標題、來源、目標、變動量、累計結果與錨點識別。
作者可以從歷史面板直接跳到事件所在的章節與正文錨點。
如果想連續比較多筆紀錄，歷史面板也可以保持開啟。
作者查看第十九章的取得事件。
再跳到第二十二章的放置事件。
接著查看第二十九章的再次轉交。
他不是先抄下章節名稱，再離開 Inspector 搜尋正文。
查詢歷史與回到歷史發生的位置，可以屬於同一段工作流程。
這很重要。
因為歷史真正有用的時刻，通常不是作者單純想回憶。
而是他發現目前狀態需要解釋、確認或修改。
一段不能回到來源的紀錄，只能告訴作者世界曾經改變。
能跳回正文錨點的紀錄，才能讓作者重新處理那次改變。
時間線回答先後，因果圖回答依賴
所有歷史都具有時間順序。
某個 Flag 先被設定。
後來改變狀態。
再被一個 REQ 檢查。
最後可能被回收。
把這些事件依章節排列，可以看見它們先後發生的順序。
但先後不一定等於依賴。
第十二章可能發生很多事。
真正支撐第二十七章 REQ 的，只有其中幾個特定 Flag。
InkWeave 的旗標與劇情因果圖，能把同一個 Flag 的前後變化連起來，也能把 Requirement 對 Flag 的依賴呈現出來。
作者因此不只看見：
這些事件發生在第二十七章以前。
還能進一步看見：
第二十七章的哪一項條件，正在由前面的哪條狀態變化支撐。
時間線回答事情何時發生。
因果圖回答後面的事件正在向哪些前因取得資格。
兩者不能互相取代。
只有順序，作者可能看見大量相鄰事件，卻不知道它們是否真正相關。
只有依賴，作者又可能失去事件如何沿著時間形成的過程。
世界的歷史需要先後。
世界的解釋還需要連線。
這不是 AI 替世界編寫一個合理解釋
當作者詢問 Rowan 為什麼是指揮官，InkWeave 不會把角色資料交給 AI，再生成一段聽起來合理的升職原因。
它會尋找正文時間線裡真正改變角色身分的事件。
當作者查看白色通行核心的去向，系統也不會根據附近文字猜測它可能經過誰的手。
它會重播明確建立的配發、取得、放置與轉交事件。
角色位置來自移動事件。
屬性數值來自每一次增減。
人物關係來自已確認的關係變化。
角色身分與職業來自轉換事件。
陣營狀態則來自加入、退出、領袖、職稱與組織關係事件。
InkWeave 使用的是自己自研的因果律引擎。
在作者已經建立的模型裡，事件順序、狀態轉移、數量變化、集合歸屬與關係連線都可以被確定性重播。
相同的事件歷史會得到相同的世界狀態。
歷史查詢也會回到真正參與推導的事件，而不是事後生成一個可能的解釋。
這是模型邊界內的數學保證。
不是 AI 審計。
如果作者只在普通文字裡寫了一場升職，卻沒有建立身分變化事件，因果律引擎不會假裝知道那段文字應該如何改變角色資料。
如果人物內心已經原諒對方，卻沒有建立需要追蹤的關係變化，系統也不會擅自改寫關係。
InkWeave 能解釋的是作者真正交給世界的歷史。
不是所有可能藏在語言裡的意義。
真實世界需要來處，架空世界也一樣
世界狀態的可追溯性不只適用於小說角色。
公司現在認定某台筆電由一名員工保管。
那台筆電是何時配發的？
是否曾經交給另一個人？
離職交接時又經過哪一次轉交？
製作現場判斷演員在某場戲裡應該穿著特定服裝。
那套服裝從哪個場景開始出現？
中間是否已經損壞、更換或留在另一個地點？
調查人員發現一份證物位於倉庫。
它最初在哪裡？
由誰帶走？
經過哪些地點後才抵達倉庫？
一個組織現在由新的主管領導。
前任何時離開？
下屬如何重新連接？
新主管又是透過哪一次事件取得位置？
InkWeave 不是資產管理系統、製片管理系統或企業人資系統。
但它能模擬這些情境共同擁有的骨架：
世界目前有一個狀態。
這個狀態由過去事件形成。
每一次改變都應該能回到它真正發生的位置。
如果這套骨架能承擔真實世界裡的人員、物品與責任流轉，它也能承擔架空世界裡更複雜的歷史。
一名將軍為什麼掌握軍隊。
一件聖物為什麼出現在敵國。
一座城市為什麼仍然封鎖。
一個角色為什麼不再信任昔日盟友。
一個古老組織為什麼失去了原本的領袖。
這些答案不能只因為作者在資料頁上如此設定，就被世界接受。
它們需要來處。
一個可信的現在，應該帶著自己的歷史
世界狀態不是一組被更新到最新的欄位。
它是過去仍然留在現在裡的方式。
Rowan 是指揮官，因為某次身分變化曾經發生。
他位於 Europa，因為他曾經移動到那裡，之後也沒有離開。
他持有通行核心，因為那件物品沿著角色與地點一路流轉到他手上。
他和 Ilya 敵對，因為某次事件改變了原本的關係。
他的壓力值是 7，因為前面的增加與減少共同留下了這個結果。
Inspector 可以讓作者看見現在。
歷史面板讓作者知道現在從哪裡來。
因果圖則讓作者看見某些後續條件正在依賴哪些前因。
它們共同回答的，不只是世界目前長什麼樣。
而是世界憑什麼成為現在這個樣子。
一個答案如果找不到來處，就只能依賴作者記憶或資料頁上的宣告。
一個能夠回到事件的答案，才真正屬於這段世界歷史。
當下告訴你答案。
歷史告訴你，這個答案為什麼成立。