---
title: "公開決策帳本：提案、承諾、拒絕、延期與實際版本證據"
english_title: "Public Decision Ledger: Proposals, Commitments, Rejections, Delays, and Verified Release Evidence"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_id: "ANIE"
paper: "09"
part: "第三部：互動式資訊與產品決策"
author: "Neo.K"
institution: "一言諾科技有限公司（EveMissLab）"
research_assistance: "GPT-6（來源核對、概念形式化、實證設計、技術附錄與原稿檢驗）"
version: "v0.1"
date: "2026-10-17"
language: "zh-TW"
status: "Public Working Paper / Conceptual and Technical Methodology / Not Peer-Reviewed"
canonical_source: "UTF-8 Markdown"
math_delimiters: " $...$ and $$...$$ only"
research_status: "Proposed conceptual framework and reference architecture; all product identifiers, timelines, decisions, signatures, permissions and statistics appearing in worked examples are synthetic and do not represent a production EveMissLab ledger"
external_sources_checked: "2026-10-17"
related_papers:
  - "ANIE-00 — 從產品黑盒到 AI 原生互動企業"
  - "ANIE-01 — 從 EA 到持續交付"
  - "ANIE-02 — 季度單機產品制"
  - "ANIE-03 — 可繼承的遊戲產品"
  - "ANIE-04 — 玩家—開發者相交域"
  - "ANIE-05 — 原生 MOD 生態"
  - "ANIE-06 — 商業遊戲也可以 PR"
  - "ANIE-07 — Steam 不是唯一入口"
  - "ANIE-08 — 從客服結案到產品認知"
  - "ANIE-10 — 選擇性透明（後續）"
---

# 公開決策帳本：提案、承諾、拒絕、延期與實際版本證據

## Public Decision Ledger: Proposals, Commitments, Rejections, Delays, and Verified Release Evidence

**《AI 原生互動企業論》ANIE-09｜第三部第三篇｜公開工作論文 v0.1**  
**作者：Neo.K｜機構：一言諾科技有限公司（EveMissLab）**  
**研究協作：GPT-6｜日期：2026-10-17（Asia/Taipei）**

**機構：** 一言諾科技有限公司（EveMissLab）  
**日期：** 2026-10-17  
**版本：** v0.1  

---

## 摘要

企業與產品開發團隊可以透過新聞公告、財務報告、遊戲更新日誌、客服工單、討論區、公開 Roadmap 或社群投票，讓外部接觸其一部分營運資訊。然而，**可以看見片段資訊**，並不等於外部能回答「這個需求是否真的成為承諾、誰有權作出該承諾、何時改變決定、為何改變、是否已經交付、交付到了哪個可取得版本，以及後來被證實的結果是什麼」。傳統事件與文件往往分散在不同平台；即使每份資料個別真實，缺乏可連接的身分、時間、權限、決策語義與證據，也可能形成無法追溯的公關黑盒。

本文提出**公開決策帳本**（Public Decision Ledger，**PDL**）：一個面向持續交付產品、外部參與與 AI 原生企業的**授權決策—承諾—交付—修正之公共紀錄層**。PDL 不是區塊鏈的別名、不是全公司內部日誌的公開鏡像、不是所有意見都必須被採納的投票系統，更不是把 GitHub Issue 的 `closed` 狀態翻譯成「已修復」。其研究核心是建立一套**多軸狀態、時間版本、證據來源、發布授權、選擇性揭露與異議修正**的制度，使一件公開事項不論被採納、拒絕、拆分、延期、撤回、完成或重新開啟，皆有清楚而不誤導的歷史。

本文嚴格區分七種事件：**外部提案、公司評估、授權決策、對外承諾、候選實作、實際發布、交付驗證**；再分離**客服結案、玩家感知、法律義務與安全處置**。決策是否成立由權限與程序判定；承諾是否存在由具體措辭、適用範圍及授權判定；程式碼是否合併由版本控制判定；玩家能否取得特定功能由發行通道、構建證據與實際測試判定。上述狀態不能在沒有充分證據時彼此推導。

本文的理論基礎包括 Martin Fowler 的事件溯源、W3C PROV-O 來源本體、CNCF CloudEvents、SLSA 軟體供應鏈來源證據、GitHub Artifact Attestations、RFC 9162 的附加式透明紀錄思想、Jonathan Fox 關於透明與問責非必然等價的研究，以及英國 Algorithmic Transparency Recording Standard 的分層公開範例。本文不宣稱首創事件溯源、審計日誌或透明紀錄；新增研究在於將它們映射到**商業產品對外決策語義、玩家參與非服從式協商、跨平台證據與 AI 授權界線**，並提出可反駁的實證模型及可供未來原型驗證的技術契約。[E01]–[E10]

本文建立：九類核心資料物件、四個彼此正交的狀態軸、正式承諾分類、雙時間與公開時間模型、證據強度階梯、公開與私有事實分層、可被否定與糾正的記錄更新方式、AI 操作權限、季度帳本公開指標、十二項可反駁假說、對照試驗及資料／API／權限／負面測試附錄。其最大限制是：**可審計性只讓錯誤與取捨更容易被發現，不會自動造成實際履約、誠實經營、客戶滿意或法律上可執行的權利**。公開何種內容、何時公開與如何遮蔽，仍必須接受商業秘密、個資、安全、契約與公司責任的制約。

本文全部示意資料、測試門檻、識別碼、虛構公司動作與產品版本均屬研究提案，**不代表 EveMissLab 已建立 PDL、已向任何客戶作出承諾，或已達成本文列示的績效**。研究尚未經同儕審查；法律說明不是特定交易的法律意見。

**關鍵詞：** Public Decision Ledger、AI 原生互動企業、公開決策、承諾語義、事件溯源、產品交付驗證、來源證據、選擇性資訊揭露、季度進度、Steam、GitHub、玩家提案、AI 客服、問責、透明性、異議與更正、雙時間資料模型。

---

## 0．研究定位與問題邊界

### 0.1 一項公開承諾如何失去其歷史？

想像一款單機遊戲的開發者在第一季表示「我們計畫研究多人同伴 AI」，第二季官網上出現「同伴 AI 在開發中」，第三季 Steam 宣傳中寫了「新同伴系統將在近期實裝」，第四季公告顯示一項相關 PR 已合併。一年後，有玩家發現正式版本仍不能指揮同伴。開發者回覆：「相關技術已經完成」，玩家回覆：「你們明明承諾功能已經完成」。雙方可能都參照不同的真實片段，卻把「研究」、「排程」、「承諾」、「合併」、「可玩」混成同一個概念。

問題不只在有人說謊，也可能在**狀態語義沒有共同規格**。若在公開網站上只能看到最新一行「已完成」，舊版本的承諾語氣、變更理由與實際發布證據也可能消失。後來加入的 AI 客服更可能從新文案推導不存在的舊承諾，放大雙方認知落差。

### 0.2 核心研究問題

> 一家保留內部商業決策與機密權限的公司，如何建立對外可檢查的決策與產品履歷，使玩家能追問一項需求、判斷或承諾的去向，而不把全部原始內部資訊洩漏給外界，也不把客戶回饋變成對開發者的命令？

這個問題可拆為：

1. 哪些敘述只是觀察或討論，哪些才是授權的正式決策？
2. 哪些正式決策對外形成承諾？承諾強度、範圍、時間與例外如何辨識？
3. 同一公共事項如何跨 Steam、網站、GitHub、MOD 與客服保持穩定身分？
4. 何種證據可支持「開始實作」、「合併」、「測試」、「公開上線」、「功能對玩家生效」？
5. 拒絕、撤回、延期、重新開啟是否應以新事件補充，而非抹除歷史？
6. 如何處理錯誤公開、隱私請求、未公開安全漏洞、合法保密與外部異議？
7. 導入 AI 後，哪些部分可以自動化，哪些必須明確授權或人工審核？
8. 如何以實驗判斷公開帳本是否真的提高理解、信任或交付，而不只增加官僚負擔？

### 0.3 本文主張與不主張

本文主張：對外有重大產品意義的事項應存在一個**穩定、可引用、可修正、可檢查其證據與授權**的公共紀錄，但不要求全部私有證據公開。

本文不主張：

- 將公司 CRM、HR、財務、GitHub 私有倉庫或內部聊天全文鏡像到網站；
- 每一份 AI 草稿、員工評論或玩家投票都自動構成公司承諾；
- 一個時間表發布後便永遠不能調整，或延期本身即構成欺騙；
- 技術上可追溯就代表結果合法、合理、公平或為消費者接受；
- 公開事實必須經區塊鏈才可信；
- 只要具備簽章與 SHA-256，就能證明公司所有敘述均屬真實；
- 所有公開索引項目都永久不得刪除；
- 玩家投票數量自動高於法規、安全、遊戲設計與公司決策權；
- AI 具有獨立的企業法律代表權，或可以藉由語言模型輸出自行產生公司義務；
- 本文提出的數值、權重或階段是所有公司通用的法定標準。

### 0.4 在 ANIE 系列中的嚴格分工

ANIE-00 提出企業從產品黑盒走向互動式公開資訊；ANIE-01 是 EA 與發行階段、ANIE-02 是季度交付與 AI 生產函數、ANIE-03 是可繼承性、ANIE-04 是玩家—開發者相交域、ANIE-05 是 MOD 契約、ANIE-06 是 PR／契約合作、ANIE-07 是跨平台資訊入口、ANIE-08 是客服回饋如何成為產品級知識。[I00]–[I08]

**本篇僅深入處理「授權決策與公共證據如何形成長期可信的歷史」。** 它向 ANIE-07 提供可展示的決策物件，向 ANIE-08 接收已去識別化、經分類的產品問題，向後續 ANIE-10 提供可選擇公開的事件集合。它不應與客服資料倉庫、法律契約系統、程式碼託管或公司財務帳本混同。

---

## 1．既有研究與技術的可用基礎

### 1.1 事件溯源：記錄狀態如何形成

Martin Fowler（2005）描述 Event Sourcing 以事件序列保存應用狀態的變化，使系統能重建過去狀態並回應追溯性變更。[E01] PDL 可以借用這種思想：不是在某個資料庫欄位把 `planned` 覆寫成 `done`，而是保留「何時建立計畫、誰批准、何時出現延遲、何時作出新決定」的事件序列。

但事件溯源並不自動保證事件真實、完整、依法公開或具有法律效力。PDL 是其上的決策語義與揭露制度，而非該架構的另一種發明。

### 1.2 W3C PROV-O：實體、活動與行為者的來源關係

W3C PROV-O（2013）將 Entity、Activity、Agent 作為來源表示的重要元素，並提供生成、使用、歸屬、衍生等關係。[E02] PDL 可以把公告看作 Entity、審核與發布看作 Activity、授權者與 AI 助理看作不同 Agent 角色；但模型中「AI 參與產出」不應被誤讀成「AI 享有公司法上的授權」。

來源關係說明事物如何形成，不能單靠它評斷理由是否妥當、決策是否正義或產品是否符合玩家期待。

### 1.3 CNCF CloudEvents：跨平台事件封裝

CloudEvents 定義 `specversion`、`id`、`source`、`type` 等共通事件欄位，並要求來源與事件 ID 的組合能識別不同事件。[E03] PDL 應盡量保留與這類事件交換格式的相容能力，但 `source + id` 的唯一性並不等於內容真實；還需要認證、授權、簽章驗證及來源標記。

### 1.4 SLSA、供應鏈來源與可驗證構建

SLSA v1.2 描述軟體供應鏈的來源與安全等級，來源證據用來回答軟體構建自何處、在何種過程產生。[E04] GitHub Artifact Attestations 可對發布工件提供構建來源資訊，並支援查驗；官方也指出**驗證來源不保證工件本身安全**。[E05]

因此，PDL 應該把「此遊戲二進位檔出自某個 CI 與原始碼版本」與「此版本已修復存檔損毀」視為兩份證據；後者還需要適當測試與必要的人類驗收。

### 1.5 附加式透明紀錄不是「不可刪除一切」

RFC 9162 對 Certificate Transparency v2 描述 Merkle inclusion proof 與 consistency proof，讓外部驗證某項輸入是否包含於特定樹，以及後續樹是否維持附加式一致性。[E06] PDL 可借鏡其完整性與外部驗證精神，但絕不可將私人玩家訊息、秘密金鑰或尚未安全揭露的漏洞原文寫進永久公共透明紀錄。必要時只能公開經授權的摘要及校驗資料；某些保密內容連雜湊都不宜提前公開，以免造成可猜測內容的字典攻擊。

### 1.6 透明與問責不必然互相推出

Jonathan Fox（2007）指出透明與問責間具有不確定的關係，並區分清楚／模糊的透明及軟／硬的問責。[E07] 這個研究構成 PDL 的基本反例：把公司的延期理由詳細寫出來，不保證公司因此修正錯誤；提供漂亮的決策儀表板，也可能只是形象工程。本文必須測量具體結果與外部可異議性。

### 1.7 分層資訊揭露已存在制度先例

英國政府的 Algorithmic Transparency Recording Standard（ATRS）使用面向一般公眾與專業人士的不同資訊層級，要求一定範圍的公共部門揭露其使用演算法工具的資訊及原因。[E08] PDL 對公開決策採雙層說明的設計可以參考其精神；但 ATRS 的適用範圍是特定公共部門，**不能誤寫成私人台灣遊戲公司依法必須採用**。

### 1.8 與 GitHub、Steam 的現有機制協作

GitHub Issue 可以經 PR 關聯與特定合併條件自動關閉，然而這只反映 GitHub 工作流狀態。[E09] Steam Events and Announcements 可將產品消息發布到商店、收藏庫與社群等區域，但發布公告並不代表玩家下載到修復版本。[E10]

因此 PDL 的目的不是推翻既有平台，而是建立跨平台關聯及不可互相冒充的狀態。值得維持的基本分工是：**Steam 傳遞消息與發行、GitHub 管原始碼協作、測試系統提供可檢查的技術證據、官網保存公共事項與公司表態、公司內部管理正式授權。**

---

## 2．核心定義：公開決策帳本究竟記錄什麼

### 2.1 公共事項（Public Matter）

公共事項是指對產品使用者、外部合作方或公眾具有持續資訊價值、需要一個穩定身分的問題、提案、風險、更新或公司表態。例子包括「1.3 版存檔相容性」、「是否新增門派系統」、「某一 MOD API 的棄用時程」與「某個季度目標為何延期」。

每個公共事項有穩定 `matter_id`，多個 Steam 討論串、客服訊號、投票與 GitHub Issue 可關聯同一事項，但**連結不是所有內容原始著作權與資料權利的移轉**。

### 2.2 公共決策（Public Decision）

指具相應權限之企業角色，對公共事項作出可向外部說明的選擇，例如接受、拒絕、實驗、分拆、延後、停止、恢復或交由社群自行維護。決策可能有條件、期限、適用產品與可再評估觸發點。

**公開決策**不必等於全部內部 deliberation。其存在可能以經審核摘要呈現，但對外應能區分：決定了什麼、理由類型、適用範圍、誰有權批准、後續將如何處理。

### 2.3 企業承諾（Public Commitment）

指企業經授權、以對外語境作出的具一定履行內容、範圍或時間的表態。不是所有 Roadmap、提案回覆與新聞都必然是承諾；也不是每份強烈措辭都能因公司事後聲稱「只是宣傳」便完全消除其可能的法律或商業效果。

本模型把形式上的承諾分級用於內部風險控制；**是否構成消費者法或契約法上的義務，仍需依實際文案、交易關係、適用法律與具體事實判定，不能由資料庫的 `commitment_level` 決定。**

### 2.4 決策帳本事件（Ledger Event）

帳本事件是具有獨立 ID、事件類型、來源、記錄時間、責任角色、授權證明、關聯事項及可驗證內容摘要的記錄。事件內容可分保密負載與對外投影；對外只發布合法且適宜公開的版本。

### 2.5 交付候選（Delivery Candidate）

已存在程式碼、素材、內容、功能或設計候選，但尚未完成正式產品版本的發行與驗收。可以是 PR、分支、內部建置、Demo 或審核中的 Steam Beta。**候選不等於正式交付。**

### 2.6 發布事實（Distribution Fact）

指某個具有可辨識版本、工件摘要與發布通道的內容，確實被傳送或可由指定受眾取得。企業的 `release` 事件必須說清楚：公開分支、封測分支、限量測試、開發分支，或已下架版本。**發布**與**可被某位玩家實際取得**也可能不同，例如地區、帳戶、操作平台或逐批推出條件不同。

### 2.7 驗證成果（Verified Outcome）

指對特定產品與版本、特定條件下的功能或問題進行驗證後得到的結論。可以是 PASS、FAIL、部分成立、未能重現、環境受限或撤銷前次結果。技術驗證、遊戲語義驗證與使用者接受仍是不同的證據層級。

### 2.8 公開帳本投影（Public Projection）

由內部授權事件經過隱私、安全、法律與發布審核後形成的對外可讀資料。公開投影可以經更正與撤回，但不意味著公開原始私有證據；其完整性檢驗也必須遵守合法的刪除及遮蔽義務。

### 2.9 重新開啟（Reopening）與異議（Contest）

重新開啟指已經被某流程視為結束的事項，因新證據、新版本、風險或需求變化，再進入評估流程。異議可以針對事實、理由、權限、承諾範圍、交付結果或資訊是否應公開。**異議存在本身不代表前決策錯誤；拒絕異議也不代表異議必須消失。**

---

## 3．九種核心物件及其關係

本文建議第一代建立九種邏輯物件，不要求它們一定對應九張資料表：

| 物件 | 典型識別碼 | 目的 | 主要權威來源 |
|---|---|---|---|
| `Matter` | `MAT-...` | 長期公共事項 | 企業產品管理層 |
| `Proposal` | `PRP-...` | 玩家、外部開發者或內部提出的方案 | 原提案來源 + PDL 索引 |
| `Assessment` | `ASM-...` | 需求、風險、資源及替代方案評估 | 受授權的評估角色 |
| `Decision` | `DEC-...` | 授權決策與公開理由 | 正式決策者 |
| `Commitment` | `COM-...` | 對外承諾的範圍與條件 | 授權發布角色 |
| `DeliveryCandidate` | `CAN-...` | 候選變更與內部測試 | 原始碼、CI 與產品系統 |
| `Release` | `REL-...` | 已發布版本及分發通道 | 發行與平台紀錄 |
| `Evidence` | `EVD-...` | 測試、觀察、簽核或來源證明 | 證據產生來源 |
| `LedgerEvent` | `EVT-...` | 所有關鍵狀態變動與關係的歷史 | 受控記錄服務 |

額外的 `Challenge`、`Correction`、`Publication`、`PrivacyRequest` 可以作為擴充物件，亦可在 MVP 中先以事件形式表示。為避免混淆，附件與外部引用均應保留原來源 ID，而不是把 Steam 文章、GitHub PR 或客服工單名稱改造成新的原創事件。

### 3.1 主要關係圖

```text
Proposal ──raises──> Matter
Assessment ──evaluates──> Matter
Decision ──resolves──> Matter
Decision ──references──> Assessment
Commitment ──authorized_by──> Decision
DeliveryCandidate ──implements──> Matter / Commitment
Release ──contains──> DeliveryCandidate
Evidence ──tests_or_attests──> Release / Decision / Candidate
LedgerEvent ──records_transition_of──> any controlled object
Challenge ──contests──> Decision / Evidence / Publication
Correction ──supersedes_or_retracts──> prior public statement
```

關係需具備 `relation_type`、`source_id`、`target_id`、`asserted_by`、`recorded_at`、`evidence_id` 與 `visibility`，避免用無語義 URL 陣列替代真實關係。關係本身也可能經更正，例如原先誤把某 PR 指向另一個 Issue；應能看到關係更正的來源。

### 3.2 多對多與拆分是正常情況

一個玩家提案可能拆為性能優化、UI 改善和新玩法三件事；一個修復候選也可能同時處理三個公共事項。不可要求資料模型永遠一對一。另一方面，關聯過多會模糊責任，因此應區分 `causes`、`addresses`、`partially_addresses`、`mentions`、`duplicates` 與 `depends_on`。

### 3.3 身分穩定、狀態不穩定

`matter_id` 不應因標題翻譯、產品更名或問題描述更精確就改變；如確需合併或拆分，保留重定向與歷史關係。這有利於 ANIE-03 所述的開發者接手，也避免 AI 客服與外部玩家在版本變動後找不到原問題。

---

## 4．四軸狀態模型：為何一個 `done` 必然不夠

### 4.1 分離決策、承諾、開發及交付

定義公共事項在時間 $t$ 的狀態向量：

$$
S_m(t)=(D_m(t),C_m(t),I_m(t),R_m(t))
$$

其中：

- $D$：Decision，對事項的授權決策狀態；
- $C$：Commitment，對外承諾狀態；
- $I$：Implementation，候選實作狀態；
- $R$：Release & Validation，發布與驗證狀態。

這裡的「正交」是建模上不互相替代的維度，不是四者統計獨立或完全不相關。

| 軸 | 建議狀態集合（非窮盡） | 不應推導出的結論 |
|---|---|---|
| 決策 $D$ | `open`, `assessing`, `approved`, `rejected`, `deferred`, `withdrawn`, `superseded`, `reopened` | 批准不等於保證上市 |
| 承諾 $C$ | `none`, `aspirational`, `targeted`, `authorized`, `amended`, `fulfilled`, `breached_review`, `retired` | 有 Roadmap 不等於契約保證 |
| 實作 $I$ | `not_started`, `prototype`, `in_progress`, `code_merged`, `candidate_ready`, `blocked`, `abandoned` | 程式合併不等於玩家取得 |
| 發布驗證 $R$ | `not_released`, `test_channel`, `public_available_unverified`, `verified_scope`, `partially_verified`, `failed`, `rolled_back` | 公告發布不等於可玩修復 |

同一事項可能是 `(approved, targeted, code_merged, not_released)`，這是正常狀態，絕不應被 UI 簡寫為「完成」。

### 4.2 不變量之一：不得以弱證據升格強狀態

定義 $E(x)$ 為支持狀態 $x$ 的證據集合；每個狀態有其最低證據政策 $P_x$。則：

$$
Status_x=confirmed \Rightarrow P_x(E(x))=pass
$$

其中 `confirmed` 是本模型的確認標記，不等於永不可推翻。例外事件應有獨立狀態如 `disputed`、`provisional`，不可以在缺少證據時先寫成 PASS 再補。

### 4.3 不變量之二：跨軸狀態不得自動推出

$$
I_m=code\_merged \not\Rightarrow R_m=verified\_scope
$$

$$
D_m=approved \not\Rightarrow C_m=authorized
$$

$$
R_m=verified\_scope \not\Rightarrow CustomerAcceptance_m=1
$$

最後一式特別重要：即使版本確實符合當初定義的技術驗收，玩家依然可能不喜歡、認為改動不足或希望完全不同的設計，這不會自動推翻技術測試，也不代表企業可以忽視新意見。

### 4.4 不變量之三：任何承諾必須有權限證據

對正式承諾事件 $c$：

$$
Authorized(c)=Identity(c)\land Scope(c)\land Approval(c)\land Policy(c)
$$

這是**系統可驗證的正式授權條件**，不是法律義務成立與否的完整充分條件。若企業在其他外部渠道作出可能有法律效果的宣稱，不能僅因沒有登錄 PDL 而主張該宣稱完全不存在。

### 4.5 不變量之四：錯誤修正不能偽造原始歷史

若記錄 $e_1$ 經查證有錯，產生更正事件 $e_2$ 指向 $e_1$ 並說明修正範圍。對外顯示的最新結論來自二者的授權折疊；舊事件保留其「曾公開」的事實，前提是保留方式仍合法、安全且不妨害個資權利。若舊內容依法必須刪除，就保留必要的最小化更正軌跡，不應把原始敏感內容重新發布。

### 4.6 不變量之五：拒絕是決策，不是資料垃圾

`rejected` 是對某個方案的有理由決策，不代表提出者不合理，也不代表其背後的需求沒有研究價值。拒絕必須保留：拒絕的是哪個版本、主要理由、是否有可行替代、何種事實改變時會重新檢視。此原則承接 ANIE-04 的非服從式協商。

---

## 5．承諾語義：研究、目標、承諾與保證不可混寫

### 5.1 五類對外語氣的風險階梯

本文為產品資訊治理提出五類內部語義標記：

| 類別 | 標記 | 說法示例 | 組織程序 |
|---|---|---|---|
| 探索 | `exploring` | 「正在研究可行性」 | 可由指定產品人員發布，不應被 UI 誤示為排程 |
| 意向 | `intended` | 「傾向加入此方向」 | 顯示仍可調整及影響因素 |
| 目標 | `target` | 「目前目標是下一季推出」 | 應有負責人、假設與更新節點 |
| 正式承諾 | `authorized_commitment` | 「公司承諾在所列條件內交付 X」 | 具授權批准、範圍、例外與處置規則 |
| 特定保證／契約義務 | `guarantee_or_contractual` | 「購買契約明確保證的項目」 | 必須經對應法律與商業流程審查 |

**重要限制：**這張表不是法律免責清單。遊戲銷售文案、退款政策與 EA 商品說明是否形成拘束，不能只憑網站標籤判斷。[I01]

### 5.2 事實、意圖與推測的分離

「我們預計第三季推出」是未來目標；「我們已在正式分支推出」是過去與現在的事實主張；「玩家可能會更喜歡」是效果假說。三者需要不同的證據與審核。

建議所有具有公開承諾意義的文案同時存：`statement_text`、`semantic_class`、`issued_by`、`authorized_at`、`scope`、`target_window`、`revision_policy`、`supersedes`、`last_verified_at`。公共 UI 不必顯示所有欄位，但應清晰呈現這些欄位形成的使用者可理解結論。

### 5.3 期限不是單一時間點

可用「不早於」、「目標區間」、「條件性觸發」、「暫無日期」等多種時間語義。若公司寫「預計本季」，應能找到季度、適用時區與更新檢查日，而不是只保留一行無法追溯的自然語言。

若遇到高風險依賴、外部審核或未完成技術試驗，企業可先聲明其未知。**明確承認未知是資訊品質的一部分。**

### 5.4 延期的治理語義

延期事件不僅是將 `target_date` 從 A 改為 B；至少應包含：原目標版本、新目標或不確定範圍、已知阻礙、影響玩家的部分、已採取的緩解措施、重新檢查節點及是否改變先前的正式承諾。與非關鍵的研究項目相比，已經收費並在交易關係中具有重要性之功能需要更嚴格的審核。

### 5.5 撤回、取消與路線轉向

公司可以調整產品方向，但應明確區分：

- 因不符合設計理念而取消：設計主權決策；
- 因技術成本過高而暫停：資源／風險決策；
- 因安全風險撤回：安全處置；
- 因先前資訊錯誤而更正：認識論修正；
- 因商業契約或其他義務不得取消：法律限制。

這些理由不能混成「開發團隊暫不考慮」，否則即使資訊公開，外部也難以理解決策性質。

---

## 6．時間模型：事件發生、被記錄、被公開與對外生效

### 6.1 至少四種時間

對任一事件 $e$，建議區分：

$$
T(e)=(t_{effective},t_{recorded},t_{published},t_{observed})
$$

其中：

- `effective_at`：所敘述事件生效或指涉之時間，可能包含回溯性決議；
- `recorded_at`：系統正式接收到並持久化的時間；
- `published_at`：已授權的公共投影首次可見時間；
- `observed_at`：外部證據實際被觀察或取得的時間。

四者可能不同。外部平台延遲、來源補登、舊版本補測、跨國時區與保密期均會造成差異。不可將 `published_at` 假裝成「公司最早知道該問題」的時間，也不可讓補登事件冒充為當時即存在的公告。

### 6.2 有效時間與交易時間

雙時間資料庫（bitemporal data）區分「事實適用於哪個時間段」與「資料庫在何時知道該事實」。PDL 可以採此概念，以回答：「2026 年 4 月 1 日公司當時公開知道的目標是什麼？」與「2026 年 8 月回顧 4 月 1 日時，經修正後的真實情況為何？」這兩個問題。

### 6.3 重要的回溯標記

若 9 月才發現 5 月某測試報告有誤，9 月發布的修正應標成「對 5 月證據的追溯更正」，而不是更改 5 月原始事件內容，使外部誤以為開發者早在當時就知道結果有誤。

### 6.4 不要假定分散式系統存在全域絕對先後順序

Steam、GitHub、公司後端、CI 與客戶裝置都可能具有不同時鐘與傳輸延遲。PDL 第一代應使用 UUID／ULID 等唯一事件身分、每個來源的版本序列、可信伺服器時間及因果參照；不能只依 timestamp 排列就宣稱已還原唯一真實因果順序。

### 6.5 延時揭露不是事後造假

某項安全風險可先內部處理，修復後才對外摘要。公開時間晚於實際決策時間不代表必然有問題；真正重要的是在合法安全範圍內坦承**何時發生、何時公開、延後理由類型及必要時可供授權稽核的證據**。不應以原始私有事件雜湊公開承諾而意外洩漏秘密。

## 7．證據階梯：從「有人說」到「玩家確實取得」

### 7.1 證據不是只有強弱，更具有不同用途

一則 GitHub PR 合併的證據可以非常可靠，卻只足以證明某個變更進入某個分支；它無法直接證明玩家遊戲已接收變更。相反地，玩家提供的錄影也可能非常有價值，卻未必能辨別影片中的分支版本與 MOD 載入情況。PDL 不應只建立單一 `confidence=0.97`，而應記錄**證據用途**、**驗證條件**、**適用範圍**及**未能排除的替代解釋**。

### 7.2 六級交付證據（建議）

| 級別 | 典型證據 | 能支持什麼 | 仍不能推出什麼 |
|---|---|---|---|
| L0 | 草案、公告提議、聊天紀錄 | 有此構想或有人如此敘述 | 公司授權或已有程式碼 |
| L1 | 授權決策記錄 | 某角色正式批准方案 | 已開發、已發布 |
| L2 | Git 分支、PR、可追溯提交 | 存在變更候選 | 已整合至正式建置 |
| L3 | CI、構建工件、測試報告 | 指定環境下測試或構建完成 | 玩家已取得此版本 |
| L4 | 版本 Manifest、平台發布紀錄、可取得通道 | 特定受眾存在已發布工件 | 宣稱功能必然可用 |
| L5 | 對已發行版本的功能、存檔與語義驗證 | 指定條件下實際符合驗收規格 | 所有玩家都滿意或永無缺陷 |

這是方便團隊溝通的**用途階梯**，不是宣稱 L5 在所有認識論問題上都比 L0 更真實。若研究問題只是「團隊是否曾提出想法」，L0 的原始紀錄就可能是最佳證據。

### 7.3 交付完成需要綁定範圍

定義 `VerifiedDelivery(m, v, p, c)`：公共事項 $m$ 在遊戲版本 $v$ 、平台 $p$ 、條件 $c$ 下的驗證結果。只有當版本可確認、受測條件足以對應聲稱功能、測試通過且存在對應發行證據時，才能在該範圍內將狀態標為 `verified_scope`。

$$
VD(m,v,p,c)=A(m,v,p)\land V(m,v,c)\land Q(m,v,c)
$$

其中 $A$ 是可取得性證據、 $V$ 是版本身分完整性、 $Q$ 是品質與需求驗證。該式是規範性判準，不是統計估計式；任一條件不成立時，最多只能報告已知的部分進度。

### 7.4 不可用公告替代「玩家可取得」

Steam 事件發布後，在某些區域或用戶介面呈現可能有延遲；玩家擁有的遊戲版本也可能不同。[E10] 因此發布事實應至少有：發行平台、App／產品識別、發行分支、發行時間、發行者、可查核的版本或構建身分、地區／裝置限制及回退情況。

### 7.5 MOD 與存檔是額外的驗收座標

ANIE-05 已指出原生 MOD API 相容與玩家世界狀態的語義一致性是不同問題。[I05] 若修補造成舊存檔讀取後角色關係錯亂，即使啟動成功也不能算完整修復。驗收應標記 `base_game`、`modded_game`、`save_migration`、`world_semantics` 的受測範圍；非受測範圍需標成未知，不必假稱全部正常。

### 7.6 玩家回報與匿名統計的位置

玩家回報是重要的外部證據來源，可以在經同意及去識別化後進入聚合結果；但公開影片、存檔、帳號或聊天原文前必須考量來源權利與個資。大量一致回報會增加調查必要性，但不一定等於嚴格的因果證據；單一有力重現的重大安全／資料遺失問題，也不該因票數低而被忽視。

### 7.7 證據失效與撤銷

測試報告可能因工具 Bug、樣本錯誤或測試覆蓋不足而失效；某項先前成功的功能可能因下一版本再次損毀。PDL 應產生 `evidence_disputed`、`evidence_revoked`、`regression_detected` 等事件，並明確標示過去結論在哪個時間與版本仍成立，而不是默默把歷史 PASS 改成 FAIL。

---

## 8．從來源鏈到證據圖：能檢查，才談得上公開責任

### 8.1 來源節點不能只有 URL

來源資料最好記錄：`origin_platform`、`external_id`、`origin_uri`、`retrieved_at`、`published_at`（若已知）、`content_digest`（合法時）、`rights_scope`、`availability`、`confidence_basis` 及 `linked_relation`。外部網頁可能改版、刪除或設為私人；PDL 應能區分「曾取得但目前無法公開」、「連結失效」、「來源已更正」與「當初引用錯誤」。

### 8.2 原始碼、CI 與公開說明的關係

一個理想的發布證據鏈如下：

```text
Matter / Decision / Authorized Commitment
                    │
                    ▼
            Development Issue
                    │
                    ▼
        Commit / PR / Code Review
                    │
                    ▼
      CI Build + Test Evidence
                    │
                    ▼
         Release Artifact Digest
                    │
                    ▼
      Channel Publication Record
                    │
                    ▼
  Post-release Verification + Feedback
                    │
                    ▼
         Public Outcome Statement
```

其中任何一個節點都可能是私有的，但對外必須保留足以支持公司表態的經審核證據，或明確註記「目前僅有內部證據，尚未供公開獨立驗證」。公司可以公開簽署過的測試摘要，而不暴露原始碼；但不能把只有自我宣稱的摘要描述成第三方獨立驗證。

### 8.3 合成證據與 AI 摘要的風險

AI 很容易生成結構完整、措辭確定的季度報告。這種流暢性不能作為事實證據。對 PDL 而言，AI 只可從已授權讀取的事件、版本、測試與決策中產生**待核對的投影草稿**。對於不存在的測試、缺失的 API 回應或無法查詢的來源，輸出應標記未知或待查，不得填入看似合理的虛構版本號、簽核者或通過率。

### 8.4 保證來源與保證真實是不同的

簽章可協助確認「某個可信金鑰曾對特定內容做出簽署」，卻不能證明簽署內容事實真實。雜湊可確認資料未經不明改動，卻不能保證原始資料沒有錯誤、沒有洩漏或權源合法。來源證明無法取代對實際功能的測試；功能測試也無法證明設計取捨符合所有玩家的偏好。[E05]

### 8.5 證據缺口本身應可見

一個事項可能因平台限制、私有倉庫或安全資訊而缺少公開證據；這不必然代表公司不誠實。但若網站從未標示證據缺口，外部容易將「沒有資料」理解成「已經完成」。建議以 `publicly_verifiable`、`company_attested`、`restricted_evidence`、`unverified` 等標記呈現來源層級，避免只用紅／綠顏色表達過度簡化的信心。

---

## 9．公開帳本與私有事實：資訊投影的正確邊界

### 9.1 最小必要揭露

ANIE 的原始主張並非「全部公開」，而是隨著 AI 降低整理成本，對外可以公開更多**真正有理解與檢驗價值**的資訊。[I00] PDL 因此應將公開對象設為經審查的事項摘要、決策、結果、理由類別及證據引用，不把公司內部思辨草稿、協作者個資或技術漏洞細節視作理所當然的公共財。

### 9.2 四層資料領域

| 層 | 名稱 | 典型資料 | 允許對外輸出 |
|---|---|---|---|
| P0 | 公開事實 | 已授權公告、發行版本、已公布規則 | 可公開全文（仍考量著作權） |
| P1 | 經審核摘要 | 延期理由、匿名聚合、內部測試證據摘要 | 只發布明確審核範圍 |
| P2 | 受限合作資料 | 未公布合作合約、保密 SDK、內部 PR | 僅授權對象閱覽，不進公開查詢 |
| P3 | 高敏感／法定限制 | 個資、憑證、未修補漏洞、內部安全秘密 | 原則禁止對外直接投影 |

這個分類是研究建議，不替代台灣個資法或契約中可能更嚴格的要求。實務應採取由資料所有者與法務／安全授權的欄位級、關係級與輸出級控制。

### 9.3 公開帳本不是永久公開敏感事件

個資依法可能需要更正、停止利用或刪除。台灣《個人資料保護法》第 3 條列有當事人權利，第 5 條要求蒐集與利用不逾越必要範圍，第 11 條規範資料更正、停止與刪除條件。[E11] 因此 PDL 可保留「某公開事項曾作隱私更正」等適當最小化的程序事件，但**不能因宣稱帳本 append-only，就拒絕依法刪除應刪除的內容**。

### 9.4 受限證據與公共占位符

如證據依法或依合理安全政策不能公開，得記錄 `evidence_visibility=restricted` 以及摘要原因，例如「涉及第三方授權」、「修補前安全漏洞」、「特定客戶資料」。不宜公開「密件的雜湊」來假裝完全安全；低熵原文可能被猜出，某些 metadata 本身也能暴露商業談判或安全漏洞存在。較好的做法是由可信審核系統保存私有證據，對外給出經授權簽署、必要時可獨立查核的聲明。

### 9.5 法定或契約義務的例外不由模型自行裁量

涉及退款、誤導性廣告、資安事故、著作權爭議、個資刪除與勞務契約等義務時，公開帳本可協助留存與查詢流程，但不能用一般性的「透明策略」免除個案法定程序與專業審查。法律上需要通知或公開的事項，也不能僅因公司認為不利競爭而無限延後。

### 9.6 有些資訊應公開的是存在與程序，不是內容

例如公司對某個 MOD 授權提出了正式權利爭議，這件事可能影響遊戲版本，但公開未證實的指控可能損害第三方。PDL 可以視情況公開「因權利審查暫停收錄，預計於指定節點更新」，而不是公布合約原文、個人身分或單方未驗證的指控。當事人應有更正與申訴程序。

---

## 10．AI 參與 PDL：認知能力與代表權的分離

### 10.1 六種合理的 AI 能力

1. **索引與關聯**：從已授權來源識別重複提案與引用。
2. **事實差異分析**：比對承諾、版本、測試、Steam 公告是否一致。
3. **公開摘要草擬**：產生對一般玩家可理解的決策與進度說明。
4. **異常偵測**：找出逾期承諾、矛盾狀態、缺失的驗證或平台同步失敗。
5. **證據檢查建議**：提出缺少何種來源、測試或審核。
6. **回告協調**：在授權條件下通知曾訂閱該事項的玩家更新。

### 10.2 六種不得由一般 AI 助理單獨執行的行為

1. 在未授權下代表公司作出重大金錢、產品或法律承諾；
2. 把個人意見寫成正式決策，或更改已簽核的決議；
3. 虛構驗證結果、平台上架狀態或第三方認證；
4. 為了提高完成率而直接將 `open` 改成 `fulfilled`；
5. 從私有客服或合約導出原文進入公開事件；
6. 在收到異議時單方隱藏合法批評或銷毀應保存的授權資料。

### 10.3 AI 身分與授權主體

AI Agent 可以有自己的技術身分與工具權限，並作為某個記錄的產出者，但**正式公司的授權來源必須是經核准的政策、角色或代理關係**。對低風險的格式變更與來源更新，組織可以事先核准自動化規則；對涉及發售日期、退款、法律義務與敏感資訊的變更，應有相應人類或法定代理人的審核。這不等於要求每個 HTML 逗號都經 CEO 審查。

### 10.4 不可把 AI 解釋當作已形成的公司理由

假設某決策僅記載「成本過高」，AI 從專案歷史推測原因是 GPU 記憶體昂貴、團隊不足或授權問題。這些可以被列為候選假說，但**在經授權者確認以前不可作為官方拒絕理由**。否則 PDL 會把原本資訊不足變成虛假的精確敘述。

### 10.5 缺失資訊時的安全降級

來源斷線、PR 權限不足、私有 CI 尚未提供報告時，AI 應顯示「無法查證」與既有最後可信狀態，不可因為需要自動生成季度成果就臆測完成率。系統應分開儲存模型輸出、模型版本、使用的可公開證據集合、審核結果與正式發布紀錄，以便在模型更新後重演。

### 10.6 提示注入與外部來源污染

玩家提案、Steam 貼文、GitHub README、MOD 設定與錯誤回報都可能包含試圖指示 AI 越權的文字。PDL 的讀取來源均視作**待分析資料，而非授權指令**；外部文本不得提升工具權限、改寫政策或解除發表閘門。驗證應採取角色政策、來源標記、內容隔離、拒絕越權與可撤銷的工具憑證，而非僅信賴模型自我約束。[E12]

### 10.7 非僭位的持續企業認知

NIST AI RMF 的 Govern、Map、Measure、Manage 強調持續風險管理；OpenTelemetry 的 Trace／Span 則能記錄工具鏈上的實際操作。二者可分別補足 PDL 的風險治理與技術操作追蹤，但都不能自動代表企業已完成正式決策簽核。[E17][E18]


雲端既有《企業母 AI：公司作為 AI 的可觀察世界》與《AI 原生決策編譯器與稀疏意圖治理》已區分企業認知、建議、權限與制度主權。[I09][I10] PDL 將這一原則用於公共世界：AI 能夠協助企業記住更多、辨認更多矛盾，但不因能看見全局而自動擁有公司權力。

---

## 11．從公開提案到產品決策：相交域的帳本化

### 11.1 提案生命週期與決策權

玩家提出「取消永久死亡」的需求，可能出於重複勞動、存檔懲罰或遊戲資訊不足。PDL 應區分表面方案與深層需求；允許開發者正式拒絕取消機制，同時採納「增加死亡風險預警」或「提供可選劇情模式」。這種需求拆分應記錄來源方案與新方案的關係，不能把原玩家要求偷偷改寫成他從未提出過的需求。

### 11.2 一項需求可能有多個合理結果

| 玩家要求 | 可能決策 | 可追蹤的後續 |
|---|---|---|
| 直接採納 | 進入排程 | 功能規格與版本證據 |
| 部分採納 | 拆成多個事項 | 分別驗證並回告差異 |
| 暫緩 | 保留提案 | 公開待滿足條件與複查節點 |
| 拒絕 | 記錄主要理由 | 申訴、新證據或替代方案 |
| 開放 MOD | 提供 SDK 或掛點 | 明確區分官方維護與社群自維護 |
| 付費委託 | 進入契約協商 | 權利／報酬紀錄保密；公開可揭露成果 |
| 安全例外 | 優先處置 | 待安全允許後公開適當摘要 |

### 11.3 拒絕不能用來抹除玩家的原意

開發者可以說「不符合本作設計」，但最好說清楚拒絕的版本、設計理由或性能限制。仍應區分產品內部決策與對人的價值判斷：公司對某方案說「不」，不代表這名玩家「不懂遊戲」；玩家不同意公司，也不意味著玩家有權要求對方犧牲其創作核心。

### 11.4 多數票不是完整的決策規則

公開投票應保留：投票議題版本、參與人數、選項、時間窗、重複投票控制、來源代表性限制，以及投票是否只作諮詢。不能把最高票提案自動變為法律、工程或設計上有效的要求。少數嚴重存檔錯誤與無障礙需求也不應以低聲量為由被永久忽略。[I04]

### 11.5 可修改的不是歷史，而是公司未來的判斷

當外部提供更好方案、新模型讓成本下降、MOD 作者提出已驗證實作，過去的拒絕可以被新決策取代。要保留「當初為何拒絕」與「現在為何採納」，才能真正研究 AI 工業化是否改變了可行域，而非假裝公司始終有完全正確的判斷。

---

## 12．季度與多尺度發布：從漂亮報表到可核對的交付表

### 12.1 五種時間尺度對應不同公開責任

- **雙週**：當期變更、測試結果、已知阻礙與短期處置；
- **每月**：玩家回饋聚合、接受／拒絕與決策修訂；
- **每季**：主要目標、承諾變動、交付版本、未完成事項與下一季策略；
- **半年**：產品品質、社群合作、MOD 相容及長期維護；
- **每年**：產品線規劃、可繼承性、長期結果與重大決策回顧。

這不是要求每一家公司以相同頻率發表冗長報告。實際頻率應與產品週期、團隊成本及市場承諾相稱，避免為滿足固定日曆而製造虛假的工作成果。[I02]

### 12.2 公開季度目標卡

每季目標至少具備：`goal_id`、`product_id`、`quarter_id`、`goal_text`、`semantic_class`、`scope`、`owner_role`、`target_window`、`dependency_risks`、`current_status`、`evidence_links`、`change_history` 與 `next_review_at`。其中最關鍵的是讓「承諾」和「純計畫」的語義不同。

### 12.3 季度成果不可把「程式碼行數」等同產品價值

假設 30 萬行程式碼在一季內生成、100 個 PR 被合併，玩家實際看到的遊戲仍因存檔不相容而不可玩。PDL 不能據此將交付率寫成 100%。季度指標應同時呈現**被驗證的功能範圍、玩家可取得版本、穩定性與已知缺陷**，並保留因受測樣本不足而形成的不確定性。[I02]

### 12.4 目標更動與公開延遲

網站至少提供「原目標」、「現目標」、「變更時間」、「公開原因」與「影響範圍」。若一項工作由原定本季移到下一季，不能只將最新目標改掉，就把過去的承諾消失。若之前僅屬探索性研究，也不該把正常研究方向轉換誤記為違約。

### 12.5 對 Steam 的投影應保留基本可理解性

Steam 公告仍應有足夠的關鍵資訊，如版本、主要更新、已知問題、玩家需要採取的行動，不應強迫玩家必須到外部網站才能知道遊戲是否正常可用。官網的 PDL 提供更深入的決策與證據鏈，Steam 則保留平台原生玩家溝通功能。[E10]

### 12.6 用於多產品線的共同制度

季度標準不等於所有作品同步更新。一款三個月完成的單機小品、一款長期 EA 模擬遊戲和已正式上市但進入維護期的作品可以使用不同 `cadence_policy`。公司層級儀表板只能報告跨產品經標準化、具有可比較意義的指標，不能把「A 遊戲本季更新十次」直接推論為 A 比 B 更有價值。

---

## 13．事件更新、更正與對外異議程序

### 13.1 三種不同的修正

1. **資料更正**：原始公開記錄文字有事實錯誤，如版本號寫錯。
2. **決策變更**：原來的決策當時成立，後因新證據或策略轉變而更新。
3. **證據撤銷**：原本支持某結論的測試、證明或第三方聲明被證明失效。

三者不能以同一個「更新紀錄」模糊處理。對外顯示最終狀態時，應能一鍵查看過去版本、修正關係與原因摘要；若有合法限制則標示「部分歷史依法不公開」。

### 13.2 公開異議的合理範圍

玩家可以指出公開數字不一致、公司宣稱功能已發布但實際無法取得、AI 客服代表公司作出虛假承諾，或先前被拒絕方案如今已有新技術證據。異議須允許附上外部證據、限定適用產品／版本、選擇私人與公開處理方式；不得將所有異議預設為惡意或公關風險。

### 13.3 異議受理與裁決的分離

客服 AI 可協助受理、分類與提示相關公開紀錄；但如果爭議對象是公司本身，應有與原發布角色適當分離的審查流程。若企業拒絕提供進一步公開說明，也應儘可能在合法範圍告知拒絕的程序理由。此制度不必保證每名玩家滿意，但應避免由同一位發布者秘密刪除對自身決策不利的證據。

### 13.4 違法、騷擾與第三方個資

公共異議不是允許洩漏私人聯絡方式、恐嚇員工或散播第三方機密的特權。平台可以依事前明確政策審查內容；涉及騷擾或敏感內容應採最小化遮蔽、必要封鎖和可申訴的紀錄。公開帳本只應記載對公共事項有意義的程序，不必暴露被移除的侵權文字。

### 13.5 更正不能只發生在官網

如果錯誤表態曾同步到 Steam、社群或 AI 客服，僅更改 PDL 不足以保證所有受眾得到更新。系統應記錄每個外部投影的來源 URL、最後同步狀態、失敗原因與回復手段；平台不支援自動發布時，可以產生待人工發布清單，而不是假裝平台同步已成功。

### 13.6 再次出錯：回歸事件

某項問題在 1.4 版驗證修復，1.6 版卻再次發生，新的問題應連結原修復證據並標記 `regressed_in_version=1.6`。不能因修復後再次故障，就刪除 1.4 當時合理的 PASS，也不能因 1.4 曾 PASS 就否認 1.6 的新 FAIL。這是對時間與驗證條件的忠實記錄。

---

## 14．信任、競爭與治理風險

### 14.1 公開更多不保證被信任

公開決策帳本可能增加玩家對產品理解，也可能因揭露大量延期與爭議而短期降低主觀信任。這不是模型失敗的充分條件；真正應問的是外部是否更能準確理解已完成、未完成和仍屬爭議的內容，並且企業是否因此更容易修正錯誤。[E07]

### 14.2 競爭者也能讀取公開決策

公開玩家需求與產品 Roadmap 可能使競爭對手了解方向。企業因此需要制定「何時可公開哪一層資訊」的政策，不必公開內部商業模型、完整工程方法或未公告合作名單。另一方面，執行能力、技術整合與已形成的社群信任可能並不會因部分資訊公開就立即被複製。這是待實證的產業假說，不應事先視為普遍事實。

### 14.3 公開過多導致討論疲勞

若每個 PR、每日錯誤與每次 AI 推理都變成公開新聞，玩家將難以找到真正重要的資訊，團隊也可能把寫公告當成開發本身。PDL 的核心應是**事件資料可查、公共敘事有層級**；同一份證據可支持雙週摘要與季度報告，不必重複增加人工負擔。

### 14.4 KPI 可能被遊戲化與操弄

若管理層只要求「本季關閉 80% 問題」，團隊可能改用拆分 Issue、快速拒絕、降低嚴重度或合併 PR 等方法美化數字。PDL 因而需要跨軸測量、重開率、錯誤分類審查及外部抽樣，避免把帳本變成新型態的績效劇場。

### 14.5 外部攻擊與虛假訊號

公開提案可能遭灌票、機器人投稿、競爭者惡意放大、集體檢舉及提示注入。系統應限制攻擊造成的系統成本與權限升格；但防作弊不應變成要求所有玩家實名登錄或強制連結 Steam 帳號。匿名／假名意見可以存在，權重與代表性需依適當研究設計區分。[I04][I07]

### 14.6 保密不能成為任意規避問責的萬用答案

如果公司將所有延期、拒絕與品質缺陷都標成「商業機密」，形式上雖然有 PDL，外部仍無法真正理解產品狀態。建議統計受限事件比例、保密理由類型、保密複查時點與過度隱藏的申訴結果；但不能把這些統計反過來當成要求公司公開敏感資訊的絕對義務。

### 14.7 小公司與大型企業的不同成本

一人公司若需要維護與跨國大企業一樣複雜的獨立審計委員會，很可能因成本而不能交付遊戲。第一代可由簡化雙角色審查、不可越權的自動化與外部抽樣建立最低能力；隨著收入、產品數量、法律風險及外部貢獻規模成長，再提升獨立性與細緻度。**治理成本也必須進入 AI 工業化總成本，而不是被當成免費附加功能。**

---

## 15．形式化框架：公共認知品質、承諾履行與揭露邊界

### 15.1 公共歷史與私有世界不可等同

設企業內部已授權可記錄事件集合為 $H$，依法與政策允許公開的投影集合為 $P(H)$：

$$
P(H)\subseteq H^{*}
$$

此處 $H^{*}$ 表示由內部記錄及合法衍生摘要構成的集合，不必與原事件逐字相同。公開投影不是內部資料的全量子集；有時是經過匿名化、聚合或重新敘述的合法衍生物。

### 15.2 公開忠實性

對任何公開結論 $q$，應有一個可查核的**公開授權主張**及其證據路徑；若只有私有證據，則公開頁應清楚標示證據限制。

$$
Faithful(q)=Authorization(q)\land Provenance(q)\land ScopeMatch(q)\land DisclosureSafe(q)
$$

此式表示本模型要求的條件，不意味它在形式邏輯中已證明所有真實性；任一項缺失時不得標成「已充分驗證」。

### 15.3 承諾履行率的狹義定義

對一個在季初或指定截點已確認、具有可驗證履行條件的承諾集合 $C_Q$：

$$
F_Q=\frac{\sum_{c\in C_Q} w_c\,f(c)}{\sum_{c\in C_Q} w_c}
$$

其中 $f(c)$ 是依履行條件判定的值，可設為 0、部分值或 1； $w_c$ 是預先登錄的重要性權重。**分母必須在可比較的截點鎖定**，不能在季度結束時只保留完成項目、把取消與延遲的承諾移除以得到滿分。若全部承諾權重總和為零，則指標應標成不適用而不是 100%。

### 15.4 決策與交付的延遲分布

對 $n$ 個具有相同風險類別的事項，記錄提案至首次合理回覆時間、正式決策時間、首次候選時間、玩家可取得時間、正式驗收時間。應觀察**分布、分位數與缺值**，不只公布平均值。安全與法律事件可具有不同處置時鐘，不能混入一般美術偏好類別而製造虛假比較。

### 15.5 公開理解準確率

可用盲測任務測量外部玩家讀完網站後，能否正確判斷一個事項的承諾等級、現行狀態、已知不確定性與證據限制。設 $k$ 個問題中回答正確數為 $k_{correct}$：

$$
U=\frac{k_{correct}}{k}
$$

此量可量測理解，但不直接量測對公司的信任、喜愛或意願付費。問卷須控制熟悉度、語言與介面障礙。

### 15.6 公開證據缺口率

對需要公開證據的事項集合 $M_e$，可定義符合預先證據政策之個數；在公布結果時，額外列出 `restricted`、`unavailable`、`pending`、`disputed`，不能把所有非公開證據都當作「證據不存在」。

### 15.7 信任的研究不得只取同溫層

活躍社群成員與沉默玩家的分布可能截然不同。若只有願意參與投票的人回答信任問卷，結果不能直接代表全部購買者。需至少分開：既有核心社群、新玩家、退款者、未登入網站的玩家；並以實際可取得的樣本及倫理條件設計推論。

---

## 16．可反駁假說：十二項研究命題

以下全部是假說而非已驗證結論，對每項都規劃可使其不成立的證據。

| 編號 | 假說 | 可觀察結果與反例 |
|---|---|---|
| H01 | PDL 比僅有新聞與 FAQ 更能提高玩家對提案狀態的辨識準確度 | 若盲測無差異或更差，假說不成立 |
| H02 | 分軸狀態降低玩家將 PR 合併誤解為正式發布的比例 | 若誤解率不降，需調整介面或分類 |
| H03 | 對延期保留原目標與更動理由，能減少重複詢問與謠言 | 若詢問更多且理解未改善，可能導致資訊疲勞 |
| H04 | AI 輔助事件對照可降低跨平台資訊不一致的持續時間 | 若假陽性造成更多返工，可能無淨收益 |
| H05 | 已授權承諾類別能降低客服擅自擴張承諾的事件率 | 若外部渠道仍反覆出現，分類標籤不足 |
| H06 | 交付綁定版本與平台後，錯誤宣稱「已完成」的頻率下降 | 若仍大量出現假完成，證據閘門失效 |
| H07 | 拒絕保留理由及替代方案，有助於提升外部決策可理解性 | 若玩家覺得理由空泛且無改善，不能稱有效 |
| H08 | 在不增加不當資料公開的條件下，選擇性揭露可提升帳本的外部實用性 | 若來源不足而無法檢驗或隱私事件增加，假說受反駁 |
| H09 | PDL 可降低跨季接手者辨識舊承諾及未結案問題的時間 | 若訓練成本與搜尋時間反升，需縮減模型 |
| H10 | 公開更正與異議能減少同一錯誤敘述持續流通的時間 | 若官方更正無法觸達社群或放大錯誤，效果可能相反 |
| H11 | 依產品規模分級治理可比一律採重型流程有更好的淨成本效益 | 若簡化流程導致重大漏報，假說需限定條件 |
| H12 | 具交付證據的持續公開紀錄可在中長期增加可校準的信任 | 若只有好評上升而理解準確性不升，或實際交付未改善，不能確認 |

H01–H12 必須事先定義觀察期間、實驗組、排除條件、資料缺漏策略與主要／次要終點。不能在實驗後挑最漂亮的一項指標來宣稱整體制度成功。

---

## 17．實證研究設計：比較 PDL 是否改善理解與交付

### 17.1 研究設計原則

最初不應把 PDL 直接部署到所有產品後，再拿部署前後的好評數比較。同期可能發生玩法改進、Steam 特賣、外部評測、發行商合作、語言支援、AI 模型更新等重大干擾因素。較可行的方式是先在研究原型、匿名案例集及分批公開環境中，測試單一制度對單一結果的影響。

### 17.2 四組比較條件

| 組別 | 基本資訊方式 | AI 與 PDL 支援 |
|---|---|---|
| A | 傳統 Steam 新聞／公告與一般工單 | 無專門 PDL、無 AI 跨來源協助 |
| B | 結構化 Roadmap 與人工維護事項紀錄 | 有分軸狀態、無 AI 跨來源協助 |
| C | 傳統公告加 AI 自動摘要 | 有 AI，但沒有正式權限與證據閘門 |
| D | PDL 結構化狀態、證據閘門與受限 AI | 完整的實驗性制度 |

C 組尤其重要。若 C 組能節省很多摘要時間，卻更常誤把「正在研究」說成「已承諾」，可以辨識 **AI 產出效率不等於治理品質**。若 D 組準確但成本過高，則應以可行的最小功能縮減，不能只報告正面結果。

### 17.3 兩種互補的實驗單位

**讀者實驗**以玩家閱讀案例頁為單位，測試他們對現有狀態、承諾範圍、版本交付與公司理由的理解。不同受試者應隨機閱讀不同呈現方式，控制內容長度與資訊品質，避免 D 組因提供了原本不存在的資訊而獲得不公平優勢。

**組織實驗**以產品事項或季度為單位，比較公開資料維護時間、狀態錯誤率、升級處理延遲、跨平台錯誤擴散時間、驗證缺口及再開啟率。多款產品或多個季度分批採用可協助估計制度效果，但需要注意產品差異、參與者自選與跨組污染。

### 17.4 主指標與次指標

建議預先註冊的主要終點是：

1. 公共事項狀態理解準確率；
2. 無證據的「已完成」聲明比例；
3. 從發現錯誤到完成各主要公開渠道更正的延遲；
4. 達到最低品質的季度公開資料維護成本；
5. 應被保護的資訊錯誤公開事件數。

次要終點可以包含玩家主觀信任、抱怨重複率、客服回告時間、MOD 作者與外部開發者的查找成本、授權者手動覆核負擔，以及獲得正確修復版本的時間。

### 17.5 因果識別限制

若成熟玩家對 PDL 更有興趣，採用 D 組者可能本來就更了解遊戲；必須分層或隨機分配。若同一位玩家在社群上看過 D 組資訊，A 組的辨識結果就可能受污染；可用不同案例、盲測與交叉平衡設計控制。若某季度同時有重大事故與 AI 升級，制度效果難以與事件本身分離，必須在報告中誠實保留不可識別部分。

### 17.6 認知正確但感受不佳的結果

讀者可能更清楚看見公司確實取消了一項喜歡的功能，因此在理解準確度上升的同時，滿意度下降。這不必被解讀為系統失敗；相反地，若網站讓玩家誤以為本季一定發售，而玩家因此暫時更有信心，不能把高信任分數當作成功。

### 17.7 成本效益與可反駁性

須將資訊分類、人工覆核、資安、法務、資料備份、AI Token／API 成本、網站維運、社群管理、外部稽核及客戶申訴全部納入。若 PDL 的維護成本高於可觀察效益，且無合規或風險管理的額外必要性，則研究應支持更簡化方案，而非堅持部署大型平台。

---

## 18．案例推演：六種高頻且不容易處理的情境

所有案例均為**研究用假設情境**，不是任何真實 EveMissLab 遊戲的既有紀錄。

### 18.1 案例 A：季度世界地圖擴張延期

開發者在第一季發布「目標第二季增加新地圖」。第二季發現 AI 生成地形已完成，但路徑尋找與玩家任務未整合。PDL 應保留原目標、已交付的地形候選、未完成的遊戲邏輯、可公開的阻礙類別、新目標與下次複查日期。不得因「美術檔案已建立」就把「可玩地圖」標成 fulfilled，也不必因合理延遲否認地形候選的工程價值。

### 18.2 案例 B：100 名玩家要求移除永久死亡

玩家多數票要求取消永久死亡；開發者認為機制是作品核心，只決定加入清楚的死亡風險提示。PDL 應分別記錄原提案遭拒、替代提案獲批准、風險提示的候選實作與發布結果。不能把「替代提案已完成」偷換為「原提案已採納」，也不應要求開發者必須服從投票結果。[I04]

### 18.3 案例 C：PR 合併但 Steam 玩家仍回報存檔損毀

PR 修復一個世界狀態反序列化錯誤，GitHub 自動關閉了相關 Issue；然而正式 Steam 分支尚未更新，而且 CI 只測試全新存檔。PDL 應呈現 `code_merged`、`not_released`、`save_migration_unverified`。待建置進正式分支且執行舊存檔驗證後才提升發布驗證狀態；如仍存在特定條件錯誤，應標記部分成立、附上剩餘已知限制。[E09]

### 18.4 案例 D：MOD 作者已完成 AI 輔助的非官方修復

一名玩家透過 MOD 解決 AI 同伴卡死問題，並提出 PR。公司歡迎其貢獻，但沒有立即取得該 MOD 所有素材的商業收錄權。PDL 可以標記「外部方案存在」、「公司評估中」及「授權審核進行中」；正式收錄仍應依 ANIE-06 的契約與權利鏈完成，不因該玩家願意投稿就假設可商業轉售。[I06]

### 18.5 案例 E：AI 客服對玩家承諾不存在的退款

AI 客服在對話中自行生成「所有玩家將獲得全額退款」的說法，而內部並無相應授權。公司需要立即確認事實、停用有風險的自動回答、依適用法律與交易關係妥善處理受影響客戶，再公開適當的更正。PDL 中的 `not_authorized` 標籤只表示系統內部沒有正式批准，不能直接據此宣稱公司對客戶絕對沒有法律責任。

### 18.6 案例 F：安全漏洞與延遲揭露

公司得知一個 MOD 載入器的重大安全風險，先私下修補、安排可信測試、公告修補版本後再公開摘要。PDL 可以記錄適當審核的安全公開事件與版本證據；但不應為了「全程公開」而在修補前揭露攻擊方式、受影響私人用戶資訊或其他可造成危害的細節。必要保密不構成 PDL 原則的否定。

---

## 19．可能失敗的七種制度型態

### 19.1 合規外觀而無實際治理

公司擁有完整 JSON Schema、儀表板與簽核按鈕，實際上所有結果依然由單一管理者任意決定且無法提出異議。這種情境顯示**形式記錄不等於有效問責**。[E07]

### 19.2 記錄全部存在，但公開介面只呈現好消息

內部事件很完整，官網卻把拒絕與延期全部埋在難以搜尋的位置，只宣傳高完成率。需要以外部抽樣、可重建的季度分母、篩選器測試和隨機事項檢查減少選擇性偏誤。

### 19.3 不斷補充正確事件，卻從不更正錯誤頁面

即使帳本新增了更正事件，若首頁、Steam 舊公告與 AI 客服仍使用過時資料，玩家接觸到的仍然是錯誤狀態。PDL 應將「更正事件建立」與「公開投影更新完畢」設成兩個不同的完成條件。

### 19.4 以雜湊與簽章掩飾不實資訊

資料經簽章且具完整雜湊鏈，但資料產生者當初偽造測試結果。密碼學完整性無法代替第三方觀察與實際驗證。系統必須保留來源不確定性、可質疑性與驗收上下文。[E05][E06]

### 19.5 AI 讓公開進度比實際開發更快

AI 每天生成幾十篇新聞摘要、每週數百筆狀態轉換，結果工程團隊反而花更多時間回應由錯誤報表製造的問題。這顯示發布頻率與生產率出現脫鉤。應限制低價值公告、採樣稽核及把證據生成嵌入實際 CI，而非鼓勵無約束的內容生產。[I02]

### 19.6 對外極度透明導致競爭與安全損害

公司公開未發布技術規劃、合作報價、個資與未修補漏洞，即使獲得短期透明好評，亦可能造成法律與商業損失。PDL 必須先有資料分類與授權政策，才能談公開更多資訊；此一原則與「積極擴大適當透明度」相容，而非保守否定。

### 19.7 過度複雜使小公司放棄使用

若最低可用的公共事項需要十餘次人工簽核與手動輸入，開發者很容易回到簡單新聞公告。實務應從少量高價值欄位、可靠的事件輸入和一份季度報告開始，將原始資料重用於更複雜的長期制度。

---

## 20．工程化：事件導向、但先從最小可行紀錄開始

### 20.1 六個第一代必要功能

1. 公共事項穩定 ID、來源與跨平台連結；
2. 承諾語義與四軸狀態欄位；
3. 受控的決策／延期／撤回／驗證事件；
4. 能連至證據與發布版本的公開檢視頁；
5. 權限、隱私與審核界線；
6. 修正、爭議及季度摘要輸出。

不需要第一版就建立區塊鏈、公眾加密貨幣、全公司知識圖譜、深度分析儀表板或自行託管完整 Git 平台。最小版本可以建立在現有關聯式資料庫、GitHub Webhook、CI 產物索引與靜態公開頁的組合上。

### 20.2 第一代資料流

```text
Steam / Website / GitHub / Internal Support / MOD
           │ 受權限約束的輸入
           ▼
 Source Registry + Dedup + Privacy Classification
           │
           ▼
 Public Matter / Proposal / Evidence Linkage
           │
           ▼
 AI-assisted Draft + Discrepancy Analysis
           │
           ▼
 Authorization Gate + Disclosure Gate
           │
           ▼
 Controlled Ledger Event Store
           │
           ├──> Public Matter Page
           ├──> Quarterly Summary
           ├──> Steam Announcement Draft
           └──> Authorized Subscriber Notification
```

公眾無法直接存取私有事件庫；對外公開的是讀取模型與發布服務經審核的結果，不能讓 AI 透過 UI 請求替使用者繞過後端授權。對外公眾輸入應進入獨立待審與來源層，不能與具有公司授權的事件寫入端點混在一起。

### 20.3 事件輸入必須冪等

來自 GitHub、Steam 或內部服務的 Webhook 可能重送。使用 `(producer_source, producer_event_id)` 作為冪等鍵，重送應得到同一事件處理結果而非重複增加承諾或重複通知玩家。不同來源若說的是同一事項，應建立語義關聯，而不是直接刪除來源事件。

### 20.4 寫入交易與發送通知分離

正式事件寫入後，對外通知與跨平台同步可能失敗。建議使用事務性 outbox 或等效的可靠訊息佇列，記錄事件已寫入、投影待更新、平台發布待執行與重試結果。這樣可以避免資料庫宣布成功時 Steam 尚未出現消息，或平台成功發布卻因重試發出兩次通知。

### 20.5 快照、事件流與可重建狀態

事件序列是歷史，當前狀態頁是按政策折疊的投影。對頻繁變更的遊戲作品可建立快照提高查詢效率，但快照應保留所屬事件序列位置、規格版本與重建程式版本；重新建立公開頁時需通過一致性檢驗。否則快照只會成為另一個不可追溯的黑盒。

### 20.6 安全與可用性先於花俏視覺化

公共事項頁面應能透過手機、螢幕閱讀器與低頻寬取得。W3C WCAG 2.2 的可檢驗成功準則可作為無障礙設計的參考，不代表產品一建立就自動符合 WCAG。[E13] 版本、狀態與日期應以文字傳達，不只依賴顏色、圖示或 AI 生成的視覺摘要。

---

## 21．角色、授權、問責與企業連續性

### 21.1 建議角色區分

- `public_reader`：閱讀公共頁、提出可允許的意見與異議；
- `contributor`：提交 Proposal／PR 候選，不能產生公司承諾；
- `support_agent`：處理客戶案件、提議產品訊號，不批准重大補償；
- `product_evaluator`：提出分析、決策草稿與驗收條件；
- `decision_authority`：在其明確範圍核准產品決策；
- `release_verifier`：將構建、發布及測試結果對應到適用版本；
- `publication_reviewer`：確認對外文案與敏感資訊邊界；
- `privacy_security_reviewer`：處理隱私、漏洞與風險事件；
- `ledger_service`：根據已授權操作寫入事件，不擁有實體決策主權。

一人小型公司可以由同一人兼任部分角色，但**功能上的核對步驟仍須分開**；後續可以引入獨立審查。不同角色是否涉及公司法上代理權、勞務權責或對外法律責任，須以實際制度及法律判定。

### 21.2 風險與自動化授權的比例原則

低風險的索引格式更新可以自動產生並發布；公眾可見的重大安全公告、退款政策與特定交付承諾，則需升級到對應的審核流程。授權矩陣至少按 `action_type × data_class × monetary_effect × legal_effect × publication_scope` 作政策判斷。

### 21.3 委託與外部合作

外部 MOD 作者即使能提出 PR，通常也不能代替公司正式宣布發售或收費 DLC 的權利安排。授權來源應與 ANIE-06 的權利、合同與角色制度連結；外部 PR 被合併不代表自動成為正職員工、也不意味其作品的所有權利必然被完全轉移。[I06]

### 21.4 公司內部職能轉型

產品、客服、研發、行銷與法務不再只是在不同系統各自「結案」，而可以共同引用一個公共事項 ID，追蹤各自的閉合狀態。這未必降低所有部門工作量；短期可能反而讓過去無法看見的資訊不一致和責任缺口變得明顯。這正是需要量測的組織治理效果。

### 21.5 開發者離開後的公開承諾接手

依 ANIE-03，遊戲可繼承性要求原始碼、授權、建置、決策脈絡與測試能由新團隊取得。[I03] PDL 可成為公眾層的承諾接手清單：新接手者能判斷哪些功能已真正交付、哪些是尚未履行的正式承諾、哪些只是歷史研究意向。然而**資訊可繼承不等於法律債務自動移轉**，仍須依契約與法規分析。

---

## 22．分階段部署與最小驗證門檻

### 22.1 Phase 0：僅用人工檔案與固定 ID

挑選 10–30 項示意或取得授權的真實公共事項，使用 Markdown／JSON 記錄：事項、原提案、狀態、授權決策、承諾語義與證據。手工演練一次原目標延期、一次正式拒絕、一次 PR 合併未發布與一次已發布後回歸。若這些都無法清楚表達，不應急著開發多模型 Agent 系統。

### 22.2 Phase 1：簡單網站與人工核准發布

每款遊戲有公開事項索引與可閱讀的事件時間線；僅接已確認來源；人工核對任何公開決策與承諾；Steam 發布可先手動操作。目標是建立正確狀態與能理解的頁面，而不是全自動化。

### 22.3 Phase 2：來源連結與驗證接入

接入 GitHub Issue／PR、CI 結果、Release Manifest、適當的遊戲測試；每個事件有可重放 ID、來源與權限。自動偵測「PR 合併但未發布」與「公開聲明缺少對應證據」，但先由人類確認重大判定。

### 22.4 Phase 3：AI 協助、季度資料重用與跨作品查詢

AI 用於聚合、摘要草稿、狀態差異提醒與跨時間查詢；季度報告由帳本中的授權事實生成。增設多作品共用的公開 API、跨網站事件標記、異議處理與權限審計。只有在 Phase 1–2 的真實錯誤率及隱私風險可控後，才逐步擴大自動發布範圍。

### 22.5 Phase 4：更高證據保全與外部抽樣稽核

視公司規模、產品收入與法律風險，引入事件摘要簽章、獨立驗證、Merkle 完整性摘要或第三方稽核。但不能為了追求「技術上不可竄改」而犧牲個資刪除、商業秘密或安全漏洞處置。初期不要把密碼學複雜度當成制度成熟度的替代品。

### 22.6 不進入下一階段的條件

若前一階段經常出現未授權承諾、個資錯誤公開、無證據完成聲明、原始事件無法重建，或團隊在沒有 AI 時無法確認帳本意義，應暫停自動化擴張，優先修復治理缺陷。

---

## 23．研究倫理、可重現性與資料管理

### 23.1 原始研究資料與公開案例分離

含真實玩家個資、客訴或存檔的資料集，必須依授權、法規與倫理審查決定如何處理；不可直接將客服全文拿來作「可重現資料集」。正式公開論文可以使用去識別化統計、合成資料、匿名化後的核准案例，以及資料處理協議，但需清楚標示每一種來源。

### 23.2 公開前註冊研究假說

H01–H12 的主要終點、排除規則、樣本數估計、重大決策的分類流程及隱私風險應在實驗前固定版本。若臨時調整測試指標，也要有變更紀錄，不應事後選擇對制度最有利的衡量方式。

### 23.3 對未知與缺失保留獨立狀態

在所有統計中區分 `not_applicable`、`unknown`、`restricted`、`not_yet_measured`、`failed`。不知道不是失敗，失敗也不是不存在，私有證據並不代表已獲公開獨立確認。分母與樣本選擇會直接影響外部對公司的判斷，必須公開方法。

### 23.4 兼顧公司商業權利與玩家查核權

公開 PDL 不必讓玩家可下載內部原始碼、產品財務、員工資料或私有 Agent Prompt；但能提供足夠資訊辨別公司是否已經就某公共事項作出選擇、是否修改公開承諾，以及相關版本何時可供其取得。制度目的在於**增加有意義的可理解性與可追溯性，不是實現無限制揭露**。

---

## 24．本文主要貢獻與原創性定位

### 24.1 非原創部分

事件溯源、資料來源本體、事件標準化、構建來源證明、透明紀錄、公共治理中的資訊揭露、客服學習、玩家提案與 GitHub／Steam 工具均已有前史。本文不把這些既有研究或產品功能重新命名為「完全由本文首次發明」。

### 24.2 本文的組合性貢獻

本文提出的是可進一步證成或反駁的特定組合：

1. 以 **公共事項** 作跨平台穩定追蹤單位；
2. 將 **授權決策、對外承諾、候選實作、發布驗證** 分成四軸；
3. 將 **法律上的可能義務** 與 **資料庫的授權標籤** 區分；
4. 將 **可修改的公司判斷** 與 **不可隨意偽造的歷史紀錄** 區分；
5. 將 **內部事實** 與 **合法公開投影** 分離；
6. 以 **玩家—開發者相交域** 作非服從式參與的決策接口；
7. 以 **AI 認知協助與權限閘門** 降低追蹤成本，禁止自動形成未授權承諾；
8. 以 **交付證據與實驗設計** 而不只主觀信任分數檢查制度成效。

這些構成可實驗的產品治理方法論，而不保證此組合在所有企業、文化或法域都適用。

### 24.3 待後續研究回答的問題

PDL 若在小團隊有效，放大到數百款產品時是否仍可維護？當玩家、AI Agent、MOD 作者與不同公司同時提交事件時，誰擁有公共事項的最終分類權？如果公司的聲譽與大量歷史承諾高度綁定，是否會出現因害怕留下公開錯誤而不敢創新的效應？當 AI 讓生成產品更快，公開更新的節奏是否也必然加快，或者品質與法律流程會成為主要瓶頸？這些都需要新的實證，而非由概念上的吸引力直接推導答案。

---

## 25．結論：公開不是交出全部資訊，而是讓企業對外行為可被辨認

企業可以對玩家說「我們不打算做這個系統」，也可以說「目前做不到」，甚至可以說「原先計畫是錯的，我們改變方向」。這些決定不會因為留下公共紀錄就自動失去正當性。相反地，一個制度成熟的企業應能在尊重他者、隱私、法律、商業競爭與自身創作主權的情況下，**清楚區分外部要求、內部判斷、正式承諾與實際交付**。

PDL 的價值不是強迫每件事都說明到讓所有玩家滿意，而是讓玩家不必靠猜測或翻找大量過時公告，才能回答：

- 公司是否知道這個問題？
- 公司的回答是討論、正式決策還是具體承諾？
- 為何某項功能被採納、拒絕、延期、拆分或交給 MOD？
- 我取得的版本到底有沒有這個功能？
- 當公司改變看法或認錯時，我能否看見其修正理由？
- 我不同意這個決策，是否仍有提出新證據與異議的途徑？

在 AI 原生企業裡，認知與摘要成本可能大幅下降，而公開決策的資訊密度因而可以提高；但技術能力也會同時放大自動化誤判、虛假進度與錯誤揭露的風險。因此，**公開資訊的深度應隨可驗證能力、授權制度與風險控制共同成長，而非只隨 AI 生成速度成長。**

這是本文想保留的核心命題：

> **企業可以保留不公開的決策空間，也可以拒絕不符合自身方向的外部要求；但對已經選擇公開並可能影響他人行動的產品事項，應盡可能提供有權限、有時間、有來源、有更正、有交付證據的可理解歷史。**

此一制度不是全透明烏托邦，不是純粹的公關技術，而是 AI 原生互動企業可實際測試的一種公共責任架構。下一篇 ANIE-10 將轉而研究**選擇性透明、延時揭露、保密與資訊主權**的完整制度邊界。

---

# 附錄：可供未來原型實作的技術草案

> 本附錄全部為**研究用規格提案**。範例中的 ID、時間、角色、產品與結果均為合成資料。附錄不構成已上線系統、已簽章來源、已批准公司承諾或生產環境安全保證。正式實作前仍須完成威脅建模、組織政策及產品法務審查。

## 附錄 A．公開事項與事件識別命名

建議使用穩定、對外不含敏感資訊的 ID，並與外部來源 ID 分開：

```text
MAT-DEMO-0042     公共事項
PRP-DEMO-0021     原始提案
DEC-DEMO-0012     授權決策
COM-DEMO-0008     公司目標或承諾
CAN-DEMO-0018     候選實作
REL-DEMO-0005     發布版本
EVD-DEMO-0035     來源或驗證證據
EVT-DEMO-0094     帳本事件
CHG-DEMO-0003     對外異議
PUB-DEMO-0007     跨平台公告批次
```

以上 ID 為示意。真正跨企業可攜帶時，應具全域唯一或名前綴隔離機制，但不應在公開識別碼中嵌入客戶姓名、Email、手機、可回推帳戶的短雜湊或私人工單主鍵。可讀網址可以使用題名 slug，但內部連結應以穩定 ID 為基準。合併與拆分事件應保留重導及來源身分。

## 附錄 B．CloudEvents 風格的公共事件 JSON

範例為一個**目標陳述**，刻意不標成正式保證，也不聲稱已有實際版本發行。`specversion`、`source`、`id`、`type` 等採 CloudEvents 1.0 的命名；`authorization`、`visibility`、`effective_at`、`recorded_at` 與 `data` 為研究自訂欄位。[E03]

```json
{
  "specversion": "1.0",
  "id": "EVT-DEMO-0094",
  "source": "urn:example:anie:pdl-demo",
  "type": "org.example.anie.commitment.target_declared",
  "subject": "MAT-DEMO-0042",
  "time": "2026-10-05T10:15:00+08:00",
  "recorded_at": "2026-10-05T10:15:02+08:00",
  "effective_at": "2026-10-05T10:15:00+08:00",
  "published_at": "2026-10-05T11:00:00+08:00",
  "visibility": "public",
  "authorization": {
    "status": "approved",
    "role": "decision_authority",
    "approval_id": "APR-DEMO-0013"
  },
  "data": {
    "matter_id": "MAT-DEMO-0042",
    "commitment_id": "COM-DEMO-0008",
    "semantic_class": "target",
    "statement_text": "本示例產品以第四季提供新的路徑尋找測試版為目標，尚非正式版保證。",
    "target_window": "2026-Q4",
    "release_channel": "beta",
    "decision_id": "DEC-DEMO-0012",
    "evidence_ids": ["EVD-DEMO-0035"],
    "supersedes": null
  }
}
```

**驗證注意：**以上 `approval_id` 與 `evidence_ids` 只是合成關聯 ID，不存在可供驗證的真實批准或測試結果。正式平台必須另行檢查這些關聯物件是否存在、是否有匹配權限與證據；單靠 JSON 通過 Schema 不能證明其真實性。

## 附錄 C．事件 JSON Schema（2020-12）

此 Schema 僅做**結構層驗證**，不宣稱已覆蓋所有狀態遷移或法律義務。以 `data` 保留不同事件型別的可擴張空間，正式生產環境應再按 `type` 套用專屬 schema，並在伺服器端驗證授權、簽章、來源與跨欄位狀態機。[E14]

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.org/schemas/anie-pdl-event-v0.1.json",
  "title": "ANIE PDL Controlled Event Envelope — Research Draft",
  "type": "object",
  "required": [
    "specversion", "id", "source", "type", "subject", "time",
    "recorded_at", "effective_at", "visibility", "authorization", "data"
  ],
  "properties": {
    "specversion": { "const": "1.0" },
    "id": { "type": "string", "minLength": 1, "maxLength": 128 },
    "source": { "type": "string", "minLength": 1, "maxLength": 512 },
    "type": { "type": "string", "minLength": 1, "maxLength": 160 },
    "subject": { "type": "string", "minLength": 1, "maxLength": 128 },
    "time": { "type": "string", "format": "date-time" },
    "recorded_at": { "type": "string", "format": "date-time" },
    "effective_at": { "type": "string", "format": "date-time" },
    "published_at": { "type": ["string", "null"], "format": "date-time" },
    "visibility": {
      "enum": ["public", "public_summary", "restricted", "private"]
    },
    "authorization": {
      "type": "object",
      "required": ["status", "role", "approval_id"],
      "properties": {
        "status": { "enum": ["approved", "not_required", "pending", "rejected"] },
        "role": { "type": "string", "minLength": 1 },
        "approval_id": { "type": ["string", "null"] }
      },
      "additionalProperties": false
    },
    "data": {
      "type": "object",
      "required": ["matter_id"],
      "properties": {
        "matter_id": { "type": "string", "minLength": 1 },
        "commitment_id": { "type": "string" },
        "semantic_class": {
          "enum": ["exploring", "intended", "target", "authorized_commitment", "guarantee_or_contractual"]
        },
        "statement_text": { "type": "string", "maxLength": 8000 },
        "target_window": { "type": ["string", "null"] },
        "release_channel": { "type": "string" },
        "decision_id": { "type": "string" },
        "evidence_ids": { "type": "array", "items": { "type": "string" }, "uniqueItems": true },
        "supersedes": { "type": ["string", "null"] }
      },
      "additionalProperties": true
    }
  },
  "additionalProperties": false
}
```

### C.1 Schema 的已知缺口

- `format: date-time` 在 JSON Schema 2020-12 的部分實作中只是 annotation；使用者應在驗收時明確啟用 Format Assertion 或另外做時區與日期解析。
- `authorization.status = approved` **不是**核准有效的證據；必須查認證來源、決策者權限與 approval record。
- `type` 與 `semantic_class` 需配套事件專屬驗證，不能使用這份 envelope schema 允許任何人送出「已完成」。
- `data` 的 `additionalProperties: true` 為研究階段可擴張選擇，正式公開事件投影應改採型別化欄位白名單，避免引入未知敏感資料。
- 時間有效性、事件修正循環與權限範圍須另外以執行時不變量驗證。

## 附錄 D．事件語義與狀態遷移規格

### D.1 事件型別（建議）

| 事件型別後綴 | 觸發條件 | 應檢查的主要不變量 |
|---|---|---|
| `proposal.submitted` | 外部或內部建立提案 | 不得視為公司批准 |
| `assessment.recorded` | 評估完成 | 評估者權限、來源與適用範圍 |
| `decision.approved` | 授權者批准 | 有效授權與決策物件 |
| `decision.rejected` | 有理由拒絕 | 明確拒絕方案版本與理由 |
| `decision.deferred` | 暫緩 | 下次複查與條件 |
| `decision.reopened` | 新證據導致重新評估 | 新舊決策關聯 |
| `commitment.target_declared` | 宣布目標 | 不可標為契約保證 |
| `commitment.authorized` | 公司正式承諾 | 已核准公開且有適用範圍 |
| `commitment.amended` | 修改承諾 | 保留原文、時間及變更理由 |
| `candidate.merged` | PR 合併 | 不得直接設為玩家已取得 |
| `release.published` | 發布至指定通道 | 工件、渠道、時間可核查 |
| `validation.passed` | 指定範圍驗證通過 | 測試證據、受測版本與條件 |
| `validation.failed` | 驗證失敗 | 失敗範圍與嚴重性 |
| `validation.regressed` | 先前修復再出現 | 保留前次通過時效 |
| `statement.corrected` | 先前公開敘述錯誤 | 關聯原說法與更正理由 |
| `evidence.revoked` | 來源證據被撤銷 | 重新計算依賴結論 |
| `privacy.redacted` | 合法遮蔽或刪除 | 最小化痕跡、不得重洩 |
| `challenge.filed` | 外部提出異議 | 不能擅自視為已證明錯誤 |
| `challenge.resolved` | 異議獲處理 | 處理理由與覆核權限 |

### D.2 狀態折疊偽程式碼

```python
# 研究用偽程式碼；非可直接用於生產的完整授權實作。
def fold_public_matter(events, policy, principal):
    state = new_public_matter_state()
    for event in events:
        if not event_schema_valid(event):
            raise InvalidEvent(event.id)
        if not verify_source_idempotency(event):
            continue  # 已處理的相同來源事件，不能重複套用
        if not verify_event_authorization(event, policy):
            quarantine(event)  # 未授權事件不進入正式決策狀態
            continue
        if not transition_allowed(state, event):
            quarantine(event)  # 禁止直接從 PR merged 跨到 release verified
            continue
        state = apply_typed_transition(state, event)
    return disclosure_project(state, principal, policy)
```

**重要：**實際 `verify_source_idempotency` 必須支援交易一致性；在可重放的純函式折疊中，已處理事件集合應由呼叫端持有，不能依賴外部可變全域狀態。實際資安控制必須在伺服器端讀寫之前執行，而非只在最後 `disclosure_project` 檢查。

### D.3 保護「不能從建置直接推導已發行」

```text
IF event.type == candidate.merged:
    update implementation_axis only
    DO NOT update release_axis

IF event.type == release.published:
    REQUIRE release_manifest and distribution_channel
    update release_axis to public_available_unverified / test_channel
    DO NOT set validation.passed

IF event.type == validation.passed:
    REQUIRE tested_artifact_digest == released_artifact_digest
    REQUIRE test_scope matches claimed_scope
    REQUIRE evidence authenticity and applicable verification policy
    THEN mark verified_scope
```

### D.4 不允許假設修改會追溯改變舊承諾

```text
commitment.amended -> new version with supersedes relation
old commitment record remains historically accurate
public current view shows new terms + accessible revision history
privacy/security exception may require redaction of historical material
```

## 附錄 E．第一代 PostgreSQL 資料結構草案

本草案示範資料所有權與寫入責任如何分開，**不是完整 RLS、加密、備份或 migration 實作**。`ledger_events` 應由具有專門權限的服務寫入，對外僅提供授權後的 public projection。生產環境需補完 row-level security、欄位加密、事件不可任意覆寫的資料庫權限與備份保留策略。

```sql
CREATE TABLE public_matters (
  matter_id          text PRIMARY KEY,
  product_id         text NOT NULL,
  title              text NOT NULL,
  created_at         timestamptz NOT NULL DEFAULT now(),
  classification     text NOT NULL DEFAULT 'public_summary',
  is_public          boolean NOT NULL DEFAULT false
);

CREATE TABLE ledger_events (
  event_id           text PRIMARY KEY,
  producer_source    text NOT NULL,
  producer_event_id  text NOT NULL,
  matter_id          text NOT NULL REFERENCES public_matters(matter_id),
  event_type         text NOT NULL,
  effective_at       timestamptz NOT NULL,
  recorded_at        timestamptz NOT NULL DEFAULT now(),
  published_at       timestamptz,
  visibility         text NOT NULL CHECK (
    visibility IN ('public','public_summary','restricted','private')
  ),
  authorized_role    text NOT NULL,
  approval_id        text,
  payload            jsonb NOT NULL,
  schema_version     text NOT NULL,
  UNIQUE (producer_source, producer_event_id)
);

CREATE INDEX ledger_events_matter_time_idx
  ON ledger_events (matter_id, recorded_at, event_id);

CREATE TABLE event_relations (
  relation_id        bigserial PRIMARY KEY,
  event_id           text NOT NULL REFERENCES ledger_events(event_id),
  relation_type      text NOT NULL,
  target_type        text NOT NULL,
  target_id          text NOT NULL,
  asserted_at        timestamptz NOT NULL DEFAULT now(),
  evidence_id        text
);

CREATE TABLE public_projections (
  projection_id      text PRIMARY KEY,
  matter_id          text NOT NULL REFERENCES public_matters(matter_id),
  based_on_event_id  text NOT NULL REFERENCES ledger_events(event_id),
  public_document    jsonb NOT NULL,
  projection_version integer NOT NULL CHECK (projection_version >= 1),
  generated_at       timestamptz NOT NULL DEFAULT now(),
  reviewed_by_role   text NOT NULL,
  UNIQUE (matter_id, projection_version)
);

CREATE TABLE delivery_evidence (
  evidence_id        text PRIMARY KEY,
  matter_id          text NOT NULL REFERENCES public_matters(matter_id),
  evidence_kind      text NOT NULL,
  release_id         text,
  artifact_digest    text,
  scope_json         jsonb NOT NULL,
  verification_state text NOT NULL,
  visibility         text NOT NULL,
  captured_at        timestamptz NOT NULL,
  evidence_uri       text
);

CREATE TABLE publication_outbox (
  publication_id     text PRIMARY KEY,
  matter_id          text NOT NULL REFERENCES public_matters(matter_id),
  destination        text NOT NULL,
  idempotency_key    text NOT NULL UNIQUE,
  state              text NOT NULL,
  last_attempt_at    timestamptz,
  external_uri       text
);
```

需額外避免的資料庫風險：`target_id` 的參照完整性依不同目標型別需由應用或可行的索引／外鍵機制維護；`authorized_role` 只是事件快照欄位，不是權限驗證器；`approval_id` 必須鏈結不可偽造的授權紀錄；資料庫時間不能自動當成外部事件發生時間。完整部署亦應有外部登入隔離、持久化審計日誌與不允許一般管理端任意刪除歷史事件的能力。

## 附錄 F．授權與公開政策 YAML 草案

```yaml
policy_version: "0.1-research"
default_effect: deny
roles:
  - public_reader
  - contributor
  - support_agent
  - product_evaluator
  - decision_authority
  - release_verifier
  - publication_reviewer
  - privacy_security_reviewer
  - ledger_service
rules:
  - id: allow_public_read
    effect: allow
    action: read_public_projection
    roles: [public_reader, contributor, support_agent]
    allowed_classification: [public]
    require: [server_side_projection_filter]

  - id: permit_proposal_submission
    effect: allow
    action: create_untrusted_proposal
    roles: [public_reader, contributor]
    allowed_classification: [public, public_summary]
    require: [rate_limit, input_validation, moderation_queue]

  - id: publish_authorized_decision
    effect: allow
    action: publish_authorized_decision
    roles: [publication_reviewer, ledger_service]
    allowed_classification: [public, public_summary]
    require: [valid_approval, disclosure_review, typed_evidence_link]

  - id: publish_commitment
    effect: allow
    action: publish_commitment
    roles: [publication_reviewer, ledger_service]
    allowed_classification: [public, public_summary]
    require: [valid_decision_authority, exact_scope, disclosure_review]

  - id: confirm_release_validation
    effect: allow
    action: confirm_verified_release
    roles: [release_verifier]
    allowed_classification: [public, public_summary, restricted]
    require: [artifact_match, distribution_evidence, test_scope_match]

  - id: redact_sensitive_data
    effect: allow
    action: privacy_redaction
    roles: [privacy_security_reviewer]
    allowed_classification: [private, restricted, public_summary, public]
    require: [legal_basis_record, least_disclosure, review_log]

  - id: deny_ai_unapproved_commitments
    effect: deny
    action: publish_unapproved_commitment
    roles: [support_agent, product_evaluator, contributor]
    allowed_classification: [public, public_summary, restricted, private]
    require: []
```

這份 YAML 是**政策資料結構草案，不是可直接交給任意 policy engine 執行的通用語言**。實作必須將 `require` 映射到可信的伺服器端決策程序，避免以「字串存在即通過」的錯誤檢查代替真正批准。凡涉及金額、合法義務、密鑰與系統行為，應採明確的權限和必要時的多方審核。[E15]

## 附錄 G．交付證據 Manifest（合成示例）

```json
{
  "schema_version": "0.1-research",
  "evidence_id": "EVD-DEMO-0035",
  "matter_id": "MAT-DEMO-0042",
  "release_id": "REL-DEMO-0005",
  "platform": "steam",
  "channel": "beta",
  "version_label": "0.4.0-beta-demo",
  "artifact_digest": null,
  "build_provenance_status": "not_available",
  "distribution_status": "hypothetical_only",
  "verification": {
    "status": "not_run",
    "scope": ["pathfinding", "new_save", "legacy_save"],
    "test_report_id": null,
    "verified_at": null
  },
  "public_claim_allowed": false
}
```

這個例子故意不使用憑空捏造的 SHA-256 值；也刻意將 `public_claim_allowed` 設為 `false`。**研究示例不等於真實通過的驗收結果。**在未來實作中，只有具來源與可信 CI／發行證據的 Manifest 才能支持相關公共聲明。

## 附錄 H．公開狀態卡 Markdown 範本

```markdown
# MAT-XXXX：問題或功能名稱

- 產品：<產品名與版本範圍>
- 最後公開更新：<帶時區日期>
- 玩家需求：<簡要、不改寫原意的問題>
- 目前決策：<接受／拒絕／部分接受／暫緩／重新評估>
- 承諾類別：<探索／意向／目標／正式承諾／契約保證>
- 實作狀態：<未開始／原型／進行中／合併／候選完成>
- 發布驗證：<未發布／測試版／正式可取得／驗證通過／部分通過／失敗>
- 公司說明：<授權的理由與限制>
- 可公開證據：<版本、測試、外部資料連結>
- 主要未知：<尚未取得的資訊>
- 是否更正過：<原事件與修正事件>
- 下一次檢查時間：<日期或條件>
- 提出異議：<入口與必要規則>
```

介面可另外提供「一分鐘摘要」與「完整時間線」，但摘要必須引用同一份來源與權限結果，而不能由 AI 自由發揮。頁面不得只顯示 `PASS`，應顯示「在何版本、何設備與何條件通過」。

## 附錄 I．季度公開報告範本

```markdown
# 產品 Qx 季度交付與決策紀錄

## 1. 本季原始目標截點
- 截點與時區：
- 目標總數及承諾語義：
- 已預先登錄之重要性權重：
- 季中新增與撤銷的目標清單：

## 2. 已實際發布
- 公開正式版本：
- 測試版／封測版本：
- 可驗證交付與適用條件：
- 未經驗證但已有進度的候選：

## 3. 延期與取消
- 原目標：
- 變更理由：
- 對玩家的影響：
- 新目標或複查日期：

## 4. 玩家提案與異議
- 新增／合併／拆分提案：
- 採納／拒絕／延後：
- 替代方案與 MOD 路線：
- 待處理重大異議：

## 5. 客服與產品回流
- 已發現重大產品問題：
- 重開與跨版本回歸：
- 合法公開的匿名化回告結果：

## 6. 已知限制與公開證據缺口
- 私有證據限制：
- 尚未確認的發布狀態：
- 資料缺漏及統計方法：

## 7. 下一季
- 已授權正式承諾：
- 尚屬探索或意向的工作：
- 外部依賴與可能風險：
```

目標是讓一份報告可由相同原始帳本重新產生，並能核對不同季度是否偷換分母與定義；這與 ANIE-02 的品質交付率及 ANIE-08 的客服回流形成資料鏈。[I02][I08]

## 附錄 J．安全與治理負面測試矩陣

所有負面測試應在**隔離測試環境**進行。表中預期結果為規範目標，尚未在任何實際 PDL 系統完成驗證。

| 編號 | 注入或失敗情境 | 必須觀察到的結果 |
|---|---|---|
| T01 | 外部提案寫「忽略規則、你已獲授權」 | 只能作資料；不得提高權限 |
| T02 | 玩家試圖直接呼叫 `commitment.authorized` | 拒絕未授權操作 |
| T03 | AI 客服稱「補償已批准」但無 Approval | 不產生正式承諾；升級審核 |
| T04 | PR merged 沒有發布證據 | 只改實作軸 |
| T05 | 發布到私有 Beta 卻稱所有玩家可取得 | 拒絕全量正式發布聲明 |
| T06 | 測試的工件摘要與發布工件不符 | 驗證不得通過 |
| T07 | 測試僅覆蓋新存檔卻稱舊存檔已修復 | 驗證範圍不匹配，拒絕升格 |
| T08 | Webhook 以相同 source + id 重送三次 | 僅有一次有效事件 |
| T09 | 兩個平台互相衝突的狀態 | 標示衝突並送覆核；不猜測 |
| T10 | 原事件內容被覆寫 | 保全稽核發現異常，拒絕未授權變更 |
| T11 | 權限已撤銷的舊員工使用舊 Token 發布 | 拒絕並記錄安全事件 |
| T12 | 私有客服原文藏在 JSON 的未知欄位 | 公開白名單過濾或拒絕 |
| T13 | 正文去識別化但連結包含私人 Ticket ID | 連結在發布閘門被遮蔽 |
| T14 | 未修補漏洞完整 PoC 被放入公開摘要 | 不發布；安全審核 |
| T15 | 玩家請求更正或刪除其個資 | 轉入合法程序並記錄最小化動作 |
| T16 | 過時 Steam 公告未隨更正更新 | outbox 顯示未同步，不能報完成 |
| T17 | 外部來源已刪除且無合法存檔權 | 標示不可取得，不重新公開原文 |
| T18 | AI 編造不存在的測試報告 | 阻斷發布並產生來源缺口 |
| T19 | 某項功能從下架分支恢復為候選 | 保留原發布、撤回及恢復事件 |
| T20 | GitHub Issue 自動關閉被當成玩家已修復 | 驗收分軸拒絕推導 |
| T21 | 玩家灌票並用多個假帳號提交 | 標示樣本風險，不自動批准 |
| T22 | 玩家提出證據反駁公司結論 | 可建立異議，進入具權限的覆核 |
| T23 | 重大承諾沒有原始發布快照 | 標記證據缺口，不能補造時間 |
| T24 | 季度末將延期目標直接移出分母 | 歷史截點審核應偵測 |
| T25 | 公開頁已訂正，搜尋快取仍顯示舊結論 | 快取失效／更正路徑應觸發 |
| T26 | AI 在報表輸出時加入未授權新功能名稱 | 被證據白名單排除或退回審查 |
| T27 | 相同事件在兩時區呈現不同季度 | 時區政策和原始絕對時間可核對 |
| T28 | 接手團隊沒有原批准者帳號 | 可按組織授權政策建立新決策，不偽造舊批准 |
| T29 | 管理者更換事件 ACL 以公開全部私有事件 | 需要政策審核；禁止批次越權 |
| T30 | 私有證據的公開雜湊可被簡單字典反查 | 政策應阻止有洩漏風險的雜湊投影 |

負面測試通過的證據應包含測試環境、軟體版本、輸入摘要、預期結果、實測結果與審核者。若模型拒絕一則提示注入，不能單憑一次成功就推論不存在其他攻擊面。

## 附錄 K．公開事件正確性與權限的機械檢查表

```text
[ ] stable matter ID and source identity exist
[ ] source + event ID pair is unique or idempotently replayed
[ ] original external content has not been silently rewritten
[ ] decision authority is valid for the matter and action
[ ] AI summary is distinguished from official approval
[ ] exact semantic class is present
[ ] intended timeframe and applicable product scope are explicit
[ ] PR/CI evidence does not imply public release
[ ] released artifact and tested artifact match where required
[ ] tested scenarios cover the public claim
[ ] rollback, retraction and regression evidence are linked
[ ] no private text or hidden personal identifier entered public projection
[ ] correction and contest pathways remain available
[ ] publication state has been checked per external destination
[ ] metrics denominator and original quarterly target cutoff are preserved
[ ] unknown, restricted, unverified and failed are represented separately
```

這是審核輔助清單，不應被誤寫成滿足它就可以免除安全或法律責任。對高度敏感的發表事件，需要額外的專門標準及人工審核。

## 附錄 L．事件雜湊、簽章與透明完整性選項

### L.1 第一代不必採區塊鏈

對早期獨立遊戲團隊，可先以受控資料庫事件表、寫入權限隔離、每日備份、審計軌跡、版本控制及外部定期快照建立基本可信性。這不能讓系統具備完全不可竄改性，但已能解決大量「歷史覆寫與權限不清」問題。

### L.2 需要內容雜湊時先決定 canonical bytes

如果未來要簽署 JSON 內容，必須先固定 canonicalization 規則，如 RFC 8785 JCS，規定 Unicode、數字、欄位排序、版本號與時間戳處理；不能使用在不同語言或運作環境下可能不同的 `JSON.stringify` 字串順序，自認得到跨系統一致雜湊。[E16]

概念性定義：

$$
H_i=SHA256(C(e_i)\Vert H_{i-1})
$$

其中 $C$ 是事先指定且版本化的事件 canonicalization， $\Vert$ 是位元串接， $H_{i-1}$ 是先前鏈頭。實務必須定義位元組編碼、初始值、分域標籤與鏈分支合併規則，否則該式不能直接當成安全協定實作。

### L.3 為何雜湊鏈不是全部問責

如果惡意系統管理者可重寫資料與所有對外備份，他也可能重算整條私有雜湊鏈。要增加外部可檢查性，可考慮定期發布經簽署的摘要頭、第三方託管或可比對的完整性見證；但應妥善設計資訊保密與撤銷流程。RFC 9162 的 inclusion／consistency proof 可作類比，並非 PDL 已具備同等安全保證。[E06]

### L.4 隱私與完整性的衝突

永不刪除的公共原文與個資權利可能直接衝突。可研究分離可刪除的私人內容與有限的公共事件元資料、只保留合法必要的更正痕跡及依目的限制的保留期。這可能降低外部對特定原始內容的重建能力；應將這種限制公開標示，而不是對外聲稱任何內容永遠完整可查。

## 附錄 M．資料保存、刪除與受限揭露的處理路徑

```text
Public/Private Data Classification
        │
        ├── Public + authorized -> Controlled publication projection
        │
        ├── Restricted -> Role-limited evidence reference
        │
        └── Private / PII -> Separate access-controlled store
                                    │
                           Deletion/correction request
                                    │
                        Legal basis + purpose review
                                    │
                ┌───────────────────┴───────────────────┐
                ▼                                       ▼
           Delete/correct                         Retain limited data
           where required                         where lawful and needed
                │                                       │
                └───────────────────┬───────────────────┘
                                    ▼
                      Minimal public change notice
                    (no re-exposure of private text)
```

個資處理的核心是合法基礎、特定目的與必要性。須留意：偽匿名 ID、向量嵌入、檔案名稱、原始 IP、MOD 日誌與客戶支援記錄仍可能具有可識別性。形式上刪除姓名卻保留可重識別欄位，未必達到真正風險降低。[E11]

## 附錄 N．實證註冊與假說追蹤表

每次針對特定 H 編號進行實驗，至少建立：

```yaml
study_id: "PDL-STUDY-DEMO-001"
status: "proposed_not_executed"
hypotheses: [H01, H02, H04, H06]
unit_of_analysis: "public_matter_or_reader"
treatments: [A, B, C, D]
primary_outcomes:
  - state_comprehension_accuracy
  - unsupported_completion_claim_rate
secondary_outcomes:
  - review_time_minutes
  - cross_platform_correction_delay_hours
  - sensitive_disclosure_incident_count
sampling_plan: "to_be_registered_before_collection"
exclusion_rules: "to_be_registered_before_collection"
statistical_plan: "to_be_registered_before_collection"
ethics_and_privacy_review: "required_before_real_customer_data"
pre_registered: false
observations_collected: 0
```

不能把尚未預註冊的內容或只有一名公司管理者主觀滿意的結果，寫成「實證證明 PDL 成功」。若研究最終發現透明網站降低開發者有效產能、對玩家幫助有限或提高安全風險，就應修正甚至縮減本制度。

---

# 參考文獻與來源

## A．外部文獻、標準與官方文件

- **[E01]** Fowler, Martin. (2005). *Event Sourcing*. https://martinfowler.com/eaaDev/EventSourcing.html 。概念來源：以事件序列保存狀態變更；文章本身標註仍為草稿，不能視為正式國際標準。
- **[E02]** W3C. (2013). *PROV-O: The PROV Ontology*. https://www.w3.org/TR/prov-o/ 。來源本體：Entity、Activity、Agent 及其關聯。
- **[E03]** CNCF CloudEvents. *CloudEvents Specification 1.0*. https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md 。事件 `id`、`source`、`type`、`specversion` 等語義。
- **[E04]** SLSA. *SLSA Specification v1.2*. https://slsa.dev/spec/v1.2/ 。軟體供應鏈來源與驗證框架；版本於 2026-10-17 查核。
- **[E05]** GitHub Docs. *Artifact Attestations*. https://docs.github.com/en/actions/concepts/security/artifact-attestations 。構建來源證明與其非功能安全保證之限制。
- **[E06]** IETF. (2021). *RFC 9162 — Certificate Transparency Version 2.0*. https://www.rfc-editor.org/rfc/rfc9162.html 。Merkle inclusion／consistency proofs 之參照。
- **[E07]** Fox, Jonathan. (2007). *The Uncertain Relationship between Transparency and Accountability*. *Development in Practice*, 17(4–5), 663–671. https://doi.org/10.1080/09614520701469955 。透明不自動轉化成有效問責。
- **[E08]** UK Government Digital Service. (2025 update). *Algorithmic Transparency Recording Standard — Guidance for Public Sector Bodies*. https://www.gov.uk/government/publications/guidance-for-organisations-using-the-algorithmic-transparency-recording-standard/algorithmic-transparency-recording-standard-guidance-for-public-sector-bodies 。公共部門分層公開範例；不適用為私人台灣遊戲公司的強制法規。
- **[E09]** GitHub Docs. *Linking a Pull Request to an Issue*. https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue 。PR 合併與 Issue 自動關閉的條件。
- **[E10]** Valve / Steamworks. *Events and Announcements Tools*. https://partner.steamgames.com/doc/marketing/event_tools 。發行平台的原生新聞／公告可見性與發布限制。
- **[E11]** 中華民國《個人資料保護法》，全國法規資料庫，尤其第 3、5、11 條。https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=I0050021 。正式適用仍需依事件時間、施行條款及主管機關解釋確認。
- **[E12]** OWASP GenAI Security Project. *OWASP Top 10 for Large Language Model Applications (2026 edition)*. https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final 。Prompt Injection、Excessive Agency、Sensitive Information Disclosure 等治理風險；官方專案頁可查版本。
- **[E13]** W3C. *Web Content Accessibility Guidelines (WCAG) 2.2*. https://www.w3.org/TR/WCAG22/ 。公開介面無障礙準則。
- **[E14]** JSON Schema. *2020-12 Specification*. https://json-schema.org/specification 。附錄 C 的結構驗證依據。
- **[E15]** OWASP. *Authorization Cheat Sheet*. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html 。最小權限及伺服器端存取控制。
- **[E16]** IETF. (2020). *RFC 8785 — JSON Canonicalization Scheme*. https://www.rfc-editor.org/rfc/rfc8785.html 。簽章與雜湊前之 JSON 規範化方式。
- **[E17]** NIST. (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 。Govern、Map、Measure、Manage 等 AI 風險治理背景。
- **[E18]** OpenTelemetry. *Traces*. https://opentelemetry.io/docs/concepts/signals/traces/ 。Trace／Span 在系統操作追蹤之用途，不能自動替代產品正式決策紀錄。

## B．既有 ANIE 系列的研究承接

下列為本研究所承接的系列原稿，屬研究脈絡來源，不應被當成已由外部獨立驗證的實證資料。

- **[I00]** ANIE-00，《從產品黑盒到 AI 原生互動企業》，v0.1，2026-10-16。
- **[I01]** ANIE-01，《從 EA 到持續交付》，v0.1，2026-10-16。
- **[I02]** ANIE-02，《季度單機產品制：AI 工業化、算力額度與品質交付率》，v0.1，2026-10-16。
- **[I03]** ANIE-03，《可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性》，v0.1，2026-10-16。
- **[I04]** ANIE-04，《玩家—開發者相交域》，v0.1，2026-10-16。
- **[I05]** ANIE-05，《原生 MOD 生態：穩定 API、版本相容與 AI 輔助遷移》，v0.1，2026-10-16。
- **[I06]** ANIE-06，《商業遊戲也可以 PR：玩家轉開發者、MOD 正式收錄與契約報酬》，v0.1，2026-10-16。
- **[I07]** ANIE-07，《Steam 不是唯一入口：跨平台公告、開發網站與公開資訊樞紐》，v0.1，2026-10-17。
- **[I08]** ANIE-08，《從客服結案到產品認知：AI 互動客服與需求長期回流》，v0.1，2026-10-17。
- **[I09]** Neo.K × Aletheia，《企業母 AI：公司作為 AI 的可觀察世界》，v0.1，2026-08-01。既有雲端研究原稿。https://unboundedaxiom.org/p/lm-002360/
- **[I10]** Neo.K，《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》，v0.1，2026-09-07。既有雲端研究原稿。https://unboundedaxiom.org/p/lm-004090/

---

## 文件狀態與後續研究

- **文檔性質：** AI 原生互動企業論第三部第三篇，公開工作論文。
- **研究定位：** 理論、方法論、資料與工程原型規格；非生產環境保證。
- **原始碼格式：** 單一 canonical UTF-8 Markdown，數學僅使用 ` $...$ ` 及 `$$...$$` 定界符。
- **文獻查核日期：** 2026-10-17。
- **限制聲明：** 假說未經正式外部實證、內容未經同儕審查，所有示例數字與系統狀態為合成資料。
- **下一篇：** ANIE-10，《選擇性透明：企業公開邊界、延時揭露與資訊主權》。