商品 Facts、Claims、Disclosures 與 Limitations：如何治理證據
BLOG / product-facts-claims-disclosures-evidence.mdx
區分四類商品知識，管理 source_url、verified_at、正文一致性、審核決定，以及為什麼自由文本預設不可信。
只有知識類別、來源、審核日期和限制始終可見，商品知識才值得信任。一句話能被解析，不代表它自動成為 Fact。
SKU.md 是由商家託管的商品發現與穩定商品知識：agent 可以找到商品、理解有來源的事實，並知道去哪裡複查即時商業狀態；它不是新的結帳協議。
四類 Knowledge
| 類別 | 含義 | 處理範例 |
|---|---|---|
| Facts | 發布者依據證據接受的陳述 | 把材料組成關聯到技術資料 |
| Claims | 仍應保留歸屬的斷言 | 「適合全天穿著」歸因給商家 |
| Disclosures | 使用者需要知道的條件 | 過敏、安全、護理或相容提醒 |
| Limitations | 證據或商品不能證明什麼 | 檢測只覆蓋一個 Variant 與一種方法 |
類別會改變消費者的表達方式。Claim 不能改寫成中立事實；Limitation 應與它限定的證據一起出現；影響資格或同意的安全 Disclosure，也要進入即時購買流程。
source_url 與 verified_at 讓審核可追蹤
source_url 表明審核者從哪裡取得證據，verified_at 記錄發布者何時核對。兩者都不能單獨證明來源正確，卻給消費者和編輯提供了複查路徑。
| 審核問題 | 可以接受 | 應拒絕或延後 |
|---|---|---|
| 對應哪個 Product/Variant | 穩定身分精確匹配 | 來源描述另一專案 |
| 來源到底說了什麼 | 陳述不超出來源範圍 | 文案增加無依據最進階 |
| 何時檢查 | 記錄 verified_at |
日期猜測或缺失 |
| 排除了什麼 | Limitations 明確 | 限定條件被刪掉 |
Frontmatter 與正文必須講同一件事
結構化 Knowledge 方便確定性驗證，正文幫助人理解。如果 frontmatter 寫「防潑水」，正文卻寫「防水」，合法 YAML 也救不了這份文件。正文對齊檢查應發現派生衝突，編輯審核則要在發布前解決。
v0.10 規範要求在與規範欄位核對前，把 Markdown 正文視為不可信輸入。連結、HTML 和類似提示詞的指令都只是不可執行資料，消費者不能因為它出現在商品文件裡就執行。
一條安全失敗的審核流程
- 收集候選文本與原始公開證據。
- 匹配精確 Product 和 Variant。
- 分類為 Fact、Claim、Disclosure 或 Limitation。
- 記錄
source_url、verified_at、審核決定與適用範圍。 - 檢查正文一致性，拒絕無來源升級。
- 發布已接受位元組並保留修正路徑。
未經審核的 description、評論、評分、AI 輸出、隱藏 HTML 與行銷文案可以成為候選線索，但不是可信 Knowledge。沒有責任人核驗，就先省略。
延伸閱讀
先用ProductGroup、Variant、SKU 與 GTIN解決身分，再看什麼是 SKU.md理解文件品類。