讓證據累積成知識。

1. 系統要產出什麼

這套系統以證據為依據，持續建立品牌的材料需求模型，並將需求與布廠有文件佐證的能力相互比對。模型保留版本紀錄，回答一組明確定義的業務問題，同時說明每個答案的適用範圍、限制，以及還需要哪些證據才能改善答案。

核心循環沿用先前分享的設計對話 ↗：原始證據 → 單一事實觀察 → Jev 的限定範圍判斷 → 暫定知識狀態 → 成熟度評估 → 保存狀態 → 彙整為更高層次的狀態 → 布廠機會。新證據可能強化結論、縮小其適用範圍、提出質疑，或讓新結論取代舊結論。

保存狀態，是保存可重現的結論及其依據，而不是把結論永久視為真理。 所有版本都應保留，包括暫定與已否定的版本。成熟度決定一項結論是否符合使用條件，而不是決定這筆紀錄值不值得保存。

本文件描述目標設計。目前的 state-next 是已發布的雙語設計文件閱讀介面；知識狀態引擎、資料庫、背景工作程序與實際操作畫面尚未實作。下列規則中的數值都是建議的起始設定，並非已量測的成效，也不是對 Mammut 的實際研究發現。

相關規格：

• 64 個業務問題：用來決定知識模型與工作優先順序。
• 資料契約與判定規則：定義紀錄結構、判斷題組、狀態生命週期，並提供完整範例。

2. 主要設計決策

1. 由業務問題決定蒐集與彙整方式。 每一項持續維護的主張，都必須對應至少一個已登錄的問題，並有明確的適用範圍。
2. 計算與必要限制由程式處理。 Jev 負責難以透過欄位解析或資料庫查詢可靠完成的語意判斷。
3. 區分四種內容： 觀察到的事實、推論主張、未來預測與商業建議。四者各自需要不同的證據。
4. 分開記錄模型輸出與經驗證的可靠度。 Jev 原始機率分布、證據涵蓋程度、規則判定結果與實測錯誤率，必須放在不同欄位。
5. 追溯到獨立的原始證據。 零售商轉載的產品說明與品牌原始頁面，可能只算同一份依據。從同一來源推導出的十個子狀態，不等於十次獨立佐證。
6. 把「未知」視為正式結果。 缺少成分資料不代表聚酯纖維含量為零；沒有訂單資料不代表沒有需求；未觀察到產品不代表產品已停產。
7. 以事件與不可覆寫的版本更新知識。 來源變更時，必須讓依賴該來源的結論重新接受檢查，包括已產出的答案。
8. 先以關聯式資料庫建立證據關聯圖。 資料表加上明確的依賴關係，即可支援稽核與重算；第一版不必另建圖形資料庫。
9. 保留替換判斷引擎的彈性。 透過服務轉接層，將 Jev 的 API 傳輸格式與業務領域模型分開。
10. 先完成一個問題的完整流程。 確認「來源 → 狀態 → 答案 → 修正」能正常運作，再擴充問題清單。

3. 系統全貌

flowchart TD
    Q[業務問題登錄表] --> PLAN[限定範圍的證據計畫]
    ERP[ERP 紀錄與採購文件] --> ING[來源轉接層與不可覆寫的快照]
    CAT[零售產品與歷史快照] --> ING
    REV[消費者評論] --> ING
    MILL[布廠能力與驗證文件] --> ING
    PLAN --> ING
    ING --> NORM[統一單位、實體識別、時間與材料部位]
    NORM --> OBS[單一事實觀察與來源追溯]
    OBS --> METRIC[以程式計算比較群組、數量與涵蓋程度]
    OBS --> PACK[限定內容的證據封包]
    PACK --> JEV[Jev 判斷題組]
    JEV --> VAL[驗證型別化回應並保留不確定性]
    METRIC --> CAND[候選主張版本]
    VAL --> CAND
    CAND --> GATE[版本化成熟度規則]
    GATE --> STORE[知識狀態版本與依賴關係圖]
    GATE --> GAP[證據缺口與分析人員複核]
    GAP --> PLAN
    STORE --> HIGH[產品家族、品類與品牌層級的狀態]
    HIGH --> GATE
    STORE --> MATCH[布廠能力配對]
    MATCH --> ANSWER[限定範圍且附有出處的答案與機會]
    STORE --> ANSWER
    ING --> CHANGE[偵測變更並使受影響結論失效]
    CHANGE --> STORE
    ANSWER --> OUTCOME[經查證的結果與修正]
    OUTCOME --> EVAL[評估與校準]
    EVAL --> GATE

圖中呈現的是隨時間持續運作的回饋循環。但在單次計算內，推導關係必須形成有向無環圖。上層結論不能再被當成獨立證據，用來證明推導出它的下層結論。

4. 業務範圍與推論界線

第一版支援材料組合的描述性分析、歷史商品組合趨勢、從評論提出需求假設、已觀察到的採購關係、能力配對，以及待查證機會的優先排序。每個答案都必須標示：它是在描述已觀察到的零售商品組合、ERP 交易活動、推論，還是預測。

品牌的零售商品組合無法直接代表採購量；零售價格不能直接推得布料成本；ERP 中規格相容的布料，不代表確實用在某件產品上。再生材料含量不等於取得認證，消費者抱怨也不足以判定是哪一道製程造成問題。這些都是不同主張，需要各自的證據。

系統透過修正與獨立觀察改善累積的知識。第一版不調整 Jev 的模型權重。未來可以用經查證的結果，以及從 Jev 判斷萃取的特徵，訓練小型分類器，但必須另外評估其品質。

5. 資料來源盤點與整合方式

檢視儲存庫後，找到下列可銜接的元件。其內容依相鄰專案的文件描述；本次設計尚未重新稽核底層資料，也未確認資料是否完整。

相鄰總覽專案的 README 已指出：不同型錄母體有重疊、零售商與品牌產品之間有尚未解決的對應問題，認證證據也不完整。這些應列入第一批稽核工作，不能直接把畫面上的總數合併成同一個母體。

每個轉接層都要產生來源清單，記錄資料集 ID、負責人、出處、來源類型、結構版本、內容雜湊值、快照時間、宣告的時間涵蓋範圍、已知蒐集缺口、紀錄筆數、原始出處識別碼與存取限制。「匯入成功」與「資料涵蓋完整」是不同狀態，不能混為一談。

原始資料應匯入私人儲存空間，資料蒐集與推論流程也要分開。初期先匯入已獲授權使用的既有快照；設計這套架構本身不需要即時呼叫 Jev，也不需要傳送 ERP 資料。

6. 知識模型：需要辨識哪些對象

實體對應依序採用：權威識別碼 → 正規化後的精確對應 → 限定條件下產生候選 → 限定範圍的語意評估 → 明確標示未解決或待複核。提議中的連結與已接受的連結須分開保存。關係也必須有明確型別：same_product、successor_of、variant_of、compatible_with、purchased_as 與 used_in 不能互換。

探索用視覺化中較寬鬆的配對門檻，不能直接沿用為正式系統的實體對應規則。連結品質須用未參與調整的保留測試集衡量精確率，並支援撤銷合併，同時保留原始紀錄。

7. 證據模型

單一事實觀察

每筆觀察只表達一項有來源支持的事實，包含主體、屬性或關係、值、材料部位、單位、適用時間、觀察時間、原文位置、擷取方式與不確定性。例如，從來源欄位解析出「某款產品的表布是 100% 聚酯纖維」，並不能同時推定它使用再生原料、採梭織結構，或由某家布廠供應。

正規化值旁須保留原始文字。來源位置必須能指向不可覆寫快照中的欄位路徑、頁碼與頁面區域，或特定文字段落。OCR 或生成式模型擷取的結果，在欄位品質通過適用規則前，仍屬暫定資料。

四種證據角色

來源的權威性取決於要證明什麼。官方成分欄位可支持「品牌宣稱的成分」，卻不能單獨證明經測試的性能。採購單可支持採購關係，報價單則只能支持曾提供報價的事實。

證據相依與重複資料

用 originGroupId 記錄共同的原始出處，並用 samplingUnitId 記錄統計單位，例如產品家族。跨季重複觀察可以支持延續性，但不能把未改變的同一規格，算成多份獨立佐證。轉載評論與複製的產品說明，應共用出處群組。

合併子狀態時，對最底層證據 ID 與相依群組取聯集。子狀態版本仍保留為依賴項，但不能把子狀態與它引用的底層觀察重複計入證據分母。來源是否相依若無法確認，必須揭露並保守處理。

資料涵蓋與時間

依來源、市場、品類、年度／季別、材料部位及重要欄位建立涵蓋矩陣，保留缺值與蒐集失敗的紀錄。有七個年度的檔案，不代表有七組可互相比較的產品群組。

時間分成兩種：validTime 表示事實適用的時間，recordedAt 表示系統何時得知這件事。系統須同時支援「現在如何看待 2023 年？」與「僅使用 2023 年當時已知的證據，可以回答什麼？」晚到的證據可以修正前者，卻不能洩漏進後者。

單位正規化必須一併保留量測基準：成衣重量不等於布料每平方公尺克重（gsm），成品布克重不等於胚布克重，幅寬會影響用布量，而成分百分比只屬於指定部位。缺少基準時，不得換算或配對。

8. 知識狀態的層級

以上都是示意，並非 Mammut 的實際研究結果。成熟的 L3 描述性狀態，可以支持仍屬暫定的 L4 推論；上層狀態不會因子狀態已成熟，就自動成熟。證據關聯圖可以依需要跨層引用，不要求每個問題都走完七層。

9. Jev 判斷層

TypeSafe 文件列出 Choice、Score 與 Noul 三種基本判斷型別。同一個請求中的問題共用輸入狀態，但各自獨立評估，不能直接使用同批其他問題的答案。對相同、限定內容的證據封包，應批次提出互不依賴的問題；只有真的需要前一步結果，才發出後續請求。TypeSafe 基本型別文件 ↗

API 的 state 是請求內容；本系統長期保存的 StateVersion 則是資料庫紀錄。兩者透過版本化轉接層產生的證據封包銜接，不能把這兩種「狀態」混為一談。

適用時，Choice 選項須包含 insufficient_evidence（證據不足）與 not_applicable（不適用）；候選配對還須包含 none_of_candidates（候選皆不符合）。三者含義不同。Noul 則須另設適用性與資料可用性檢查，避免把低機率同時解讀成「缺少證據」與「事實為否」。

Score 的每個序位等級都要有明確判準，並保存分布與等級對照表。不能把任意序位分數的平均值，當成實測物理量或商業事件的機率。

輸入封包包含選定原文、適用範圍、知識模型定義、明確缺值、程式算出的指標及相關反證。標準答案、分析人員的最終判定，以及無關的 ERP／客戶欄位不應放入。檢索過程須記錄候選筆數、選取規則、未納入的資料與任何內容截斷。

服務轉接層須驗證回應型別、預期 ID、選項合法性、數字是否有限、機率範圍與總和容許誤差，並記錄請求及實際使用的模型 ID、輸入雜湊值、題組版本、服務請求 ID（若有）、時間、嘗試次數、token 用量與成本計算依據。缺漏或格式不符的結果應標為 decision_failed，不能當成反對主張的證據。

10. 成熟度與信心程度

成熟狀態代表：針對特定主張類型、適用範圍與使用目的，證據在當時已通過規則。它不保證結論永遠正確。

介面應分項顯示品質，而不是自行合成一個信心數字：

• 證據數量與獨立出處的涵蓋情況。
• 母體、欄位與時間涵蓋程度，以及各自的分母。
• 實體連結品質，以及是否明確指向特定材料部位。
• 一致性、反證與尚未解決的關鍵矛盾。
• 資料時效，以及依賴資料是否仍有效。
• 各任務在保留測試集上的評估狀態。
• 結果對去重方式、缺值處理與群組選擇的敏感程度。

Jev 的 Choice／Score confidence 是輸出分布形狀的摘要；Noul 沒有獨立的信心欄位。它必須與「所選選項的機率」及「本任務實測的正確率」分開呈現。TypeSafe 信心程度文件 ↗

可以量測的成熟度條件由程式計算。Jev 可以指出歧義、相關性、語意衝突或其他解釋，但不應估算資料庫已知的筆數。也不能把相依的 Jev 判斷機率相乘，或平均子狀態的信心值，就稱為經校準的真實性機率。

不同主張適用不同規則：

初次部署時，依賴模型的狀態先採旁路評估，不直接影響正式決策，並由分析人員核可。各任務通過評估門檻後，才逐項啟用自動成熟判定。範圍很窄的權威事實，可能一份文件就足夠；廣泛趨勢則需要合理的分析母體，不能共用一個證據筆數門檻。

11. 狀態生命週期

評估結果、資料時效與版本關係分開保存：

• assessment：候選 → 暫定 → 成熟；另設「有爭議」與「已否定」。
• freshness：有效／待更新／已失效，與評估結果分開。
• supersedesVersionId：串連不可覆寫的版本；另以目前版本指標選出最新適用版本。

每次轉換都記錄觸發原因、規則版本、條件檢查結果、證據變更、操作人及前一版本。歷史結論即使曾經成熟、目前已待更新，仍可作為歷史資料呈現，但不能直接用於當前建議。

如果某主張只適用於特定市場的女款高山外套，應明確拆出較窄的主張，並記錄原本較廣主張未成立的原因。縮小範圍後仍須重新評估，不能直接繼承成熟度。

12. 執行循環與停止條件

1. 選定問題與範圍。 確認指標、必要來源、適用規則及決策用途。
2. 建立資料涵蓋計畫。 找出可用紀錄、缺少的必填欄位與未解決連結。
3. 匯入並正規化變更證據。 保留原始紀錄，產生版本化觀察。
4. 以程式計算可確定的事實。 建立群組、數量、比例、時間序列與精確條件配對。
5. 提出範圍明確的候選主張。 優先採用問題範本及計算結果。可選用生成式擷取提出附出處的結構化候選，但不能讓模型自行認證。
6. 執行語意判斷。 建立可重現的封包，透過轉接層呼叫 Jev，再驗證結果。
7. 評估成熟度。 套用主張專屬規則，保存所有條件結果，包括未知。
8. 將變更傳遞給依賴項。 依拓樸順序，重算受影響子圖中的狀態。
9. 組成答案，或暫不作答。 回傳有支持的部分、限制與下一份有用的證據。
10. 只有可能改變未決結果的工作，才繼續排入佇列。 記錄為何值得投入該項成本。

以下任一情況發生即停止：答案已可用、沒有剩餘的獨立取證行動、必要證據無法取得、用盡預算，或連續兩輪沒有實質證據／條件變化。對同一份證據改寫問題或重複呼叫，是實驗，不是增加佐證。

初期本機試行，建議每個問題最多進行三輪取證，每次執行設可調整的 100 次 API 呼叫上限，另設金額預算。這些預設值用來防止循環失控，不是容量估計。預算耗盡時，回傳部分答案與可續跑的位置。

工作優先順序使用透明的效益分數：業務重要性 × 預估能解決阻礙條件的機會 × 預期決策影響，再除以預估成本。尚無實際結果前，須標示這些值是分析人員的經驗估計。未來若改用學習式排程器，也要與此基準比較。

13. 答案與機會的資料契約

答案包含：問題 ID／版本、品牌與範圍、資料截至時間、知識截止時間、狀態、簡短結論、適用時的實測結果、引用的狀態版本及底層來源、涵蓋程度、重大反證、假設、限制與下一步所需證據。

答案狀態為 supported（有充分依據）、partial（部分可答）、contested（有爭議）與 insufficient_evidence（證據不足）。supported 只表示這個精確措辭與範圍已通過規則，不代表整個大問題的各個面向都已掌握。

事實性答案優先以結構化結果與範本產生。可另用語言生成改善可讀性，但不得加入不存在的數字、來源、關係或確定程度。逐句檢查出處，新提出的商業解讀須有分析人員複核流程。

機會配對分成兩階段：

1. 資格檢查： 檢查必要的結構、材料、幅寬、克重基準、製程與有效文件，分成通過、不通過與未知。必要條件未知時，不能列為完全合格的配對。
2. 優先排序： 對已符合資格的候選，依有據可查的材料相近程度、用途證據、延續性、能力準備程度、製程依賴及商業證據比較。各項分數與可調權重須保留。排序分數只代表優先順序，不是取得訂單的機率。

胚布廠可以控制紗線、織物結構與基布特性；耐久防潑水整理（DWR）、貼合、染色、測試與認證，可能需要下游夥伴。機會卡須說明哪些要求是布廠可直接處理，哪些仍依賴合作廠或試驗。

每個機會都要列出必要驗證：試織、成品布試驗、測試方法／目標、幅寬與縮率檢查、合作廠可用性，以及有實際數值時的經濟評估。不能用商品組合筆數推估採購量。知識循環不應自動採購、對外聯繫或承諾生產。

14. 應用介面結構

主要操作路徑為問題 → 答案 → 知識狀態 → 證據，另一條路徑為缺口 → 查證 → 修訂答案。

狀態須同時有文字標示，不能只靠顏色；日期、範圍、單位與缺值也應清楚可見。介面提供英文與台灣繁體中文，內部 ID 及原始來源文字保持穩定。若此應用加入平台首頁，頁首 F(SYNC) 標誌須連回 https://fabric-sync.com。

15. 技術架構

state-next 作為分析人員介面與伺服器 API 邊界。匯入、Jev 評估及關聯圖重算，交由獨立且可持續執行的背景程序處理。大批歷史資料回補，不能依賴瀏覽器請求一直保持連線。

這是規劃中的引擎部署設計。目前僅部署雙語設計文件閱讀介面，尚未建立引擎所需的基礎設施。開始實作時，可依既有平台選擇部署服務，不必因此改變領域資料契約。

建議模組分工：

app/                         分析介面路由與 API 處理
domain/                      實體、觀察、主張、規則、答案
adapters/sources/            資料集、歷史、評論、ERP、文件與能力
adapters/decisions/          不綁定供應商的介面與 Jev 轉接層
engine/                     規劃、指標、彙整、成熟度與失效處理
worker/                     工作處理、執行租約、重試與待送事件
storage/                    資料存取、資料庫遷移與物件儲存轉接
question-packs/              版本化語意題組與評分規準
evaluation/                 標籤、資料切分、案例、校準與報告
docs/                       架構與實作契約

建議的操作與查詢路由：

不要提供只把 mature=true 打開的路由。分析人員應提交已查證事實，或明確署名的例外核可，再由規則引擎產出狀態。例外核可須保留期限，並註明哪些自動用途仍不得使用。

16. 可靠性、存取與維運

工作採至少送達一次的機制，搭配冪等寫入，確保重複執行不產生重複結果。評估識別由封包雜湊值、題組版本、請求／實際模型、知識模型版本與服務設定共同決定。模型別名可能改指向新版本；沒有明確規則與紀錄，不得跨版本重用快取判斷。

工作須有執行租約、嘗試次數、有限重試、隨機退避，以及重試失敗後的待處理／複核佇列。暫時逾時或速率限制可以在預算內重試；錯誤憑證或格式不合法的請求不能無限重試。回應不明的逾時仍可能已計費，須如實記錄，不能宣稱只會計費一次。

每次狀態更新都用預期前一版本及資料庫交易保護。如果其他工作程序已推進版本，須重新載入並計算，不能覆寫。新版本、依賴關係、條件結果與待送事件須在同一交易中提交。

紀錄與 API 查詢都須明確限定可存取的品牌／組織。ERP 金額、客戶身分與私人文件不得進入公開前端檔案或日誌。送往模型服務的資料採欄位允許清單，並保留遮蔽紀錄。私人資料須符合專案對該服務與用途的共享規則，才能傳送。公開來源文字只能當資料，不能當成工具操作或狀態變更的指令。

保留不可覆寫歷史，仍須遵守來源撤回與資料保存規則。來源遭撤回或刪除時，在允許的範圍內只保留最少稽核紀錄，並讓受影響主張失效；不能以可重現性為由保留不得保存的原始資料。

追蹤匯入延遲、涵蓋缺口、未解決連結、候選／成熟數量、待處理失效項目、接受結果的錯誤率、暫不作答率、token 用量、每份可用答案的成本、佇列等待時間、重試與第 95 百分位處理延遲。正式更改行為前，先旁路比較模型及規則版本。保留舊版本以利回復，但回復不能讓已失效來源重新變有效。

上線前須備份資料庫與私人檔案，實際演練還原及匯入重播。開發用案例應與真實商業資料分開。

17. 評估與學習

資料擷取、實體對應、語意分類、主張成熟度、答案忠實度與機會實用性，須分別評估。依事實表作答的選擇題成績，只能支持那項閱讀任務的表現。

經查證標籤須保留原始出處與複核人。兩次 Jev 呼叫結果一致，是重現性檢查；與既有模型產生的主題圖譜一致，是與該圖譜的比較。兩者都不能單獨當成獨立真值。複核人意見不一致時，應裁定或保留爭議，而不是強迫標籤一致。

依產品家族、共同出處及時間切分資料，避免資料洩漏。預測任務用較早已知資料訓練與調整，以較晚結果評估；即使文件描述早期事件，只要系統在預測截止日之後才取得，就不能放入當時的預測。固定保留測試集不得用來調整門檻。Mammut 流程可用後，再加入其他品牌，直接量測能否轉用。

實體連結要報告精確率、召回率及暫不判定率；有適當標籤的機率輸出要報告 Brier 分數與可靠度曲線；規則要報告誤判成熟率與可回答涵蓋率；答案要檢查引用與數值是否忠實。須同時報告樣本數與不確定性區間，重抽樣時以相關產品家族／來源為群集單位。模型分布不能取代實證驗證。

初期建議依任務設上線門檻：已接受實體連結的精確率至少 98%，描述性主張的誤判成熟率至多 5%，且單側 95% 不確定性界限也須符合目標。這些是待審定的設計目標，並非已達成成績。樣本太少或缺乏代表性時，即使點估計符合目標，也應維持分析人員複核。影響較大的商業行動仍由分析人員主導。

比較純程式、Jev 輔助及人工複核三種基準。測試缺值、矛盾證據、轉載說明、選項順序變動、多語評論、實體更正、來源撤回及過期依賴。只有在保留測試集證明改善後，才加入校準器或後續分類模型。特徵可以包含 Jev 判斷，標籤則必須來自獨立查證的結果。

18. 交付順序與驗收

第一次試行應先把少量問題回答好，再執行全部 64 題。建議順序為 Q09、Q10、Q12、Q25、Q30、Q41、Q42、Q49、Q57 與 Q62。預測與品牌專案歸屬，仍須受各自的證據要求約束。

19. 第 0 階段須驗證的假設

• 歷史產品檔案有足夠穩定的識別碼與可比較快照，可做產品家族層級的跨期分析。
• ERP 可區分報價、樣品、大貨訂單、出貨與退貨，並提供單位及專案歸屬證據。
• 原始採購文件的引用可私下保存，且授權分析人員可取閱。
• 有紡織專業複核人員可裁定初期實體、材料與矛盾樣本。
• 布廠能力文件可區分胚布生產、下游後整理與當前認證範圍。
• Jev 的使用、資料保存及共享安排，適合所選的評估欄位。
• 更新頻率與業務可接受的誤差，按問題分別訂定，而非全系統共用。

假設不成立時，應縮小可回答的範圍，不能以模型的確定語氣填補缺口。

20. 參考來源與歸屬

狀態層級與累積證據的目標，來自先前分享的 ChatGPT 對話 ↗。本文的資料庫設計、規則、問題清單、運作方式與交付計畫，都是本次提出的工程設計。

服務行為已於 2026-09-22 對照 TypeSafe 簡介 ↗、基本判斷型別 ↗與信心程度 ↗文件。供應商對效能或校準的宣稱，未被當成本系統已達成的保證。

儲存庫參考：總覽 README ../../../jev-mammut-next/README.md、總覽資料建置程式 ../../../jev-mammut-next/scripts/build-data.mjs、既有循環 ../../../jev-mammut-next/lib/loop.ts、MCQ README ../../../mcq-mammut-next/README.md與 Jev 轉接層參考 ../../../mcq-mammut-next/lib/jev.ts。