01 · 問題
不知道哪些模型訓練中、哪些結束需驗證
ISMS 記錄的是鏡頭在哪一站。要回答「這個模型現在在哪」，只能人工去對。模型一多就對不完，事情就懸在半空。
原本以為痛點是「報告出來沒人拍板」。實際更嚴重的是連「送了哪些模型」都不明確。
02 · 現況
鏡頭軸把 7 件事攤成 136 列
其中三個模型就吃掉 115 支。看到 136 個點，實際只有 7 件事在進行 —— 壓縮比接近 20 倍。
同樣的落差在其他站也成立：訓練中 38 支鏡頭 ＝ 5 個模型；資料審核 56 支 ＝ 6 個模型。
鏡頭軸回答不了「現在在做什麼」。
03 · 提案
加一層「模型版本」，五個狀態
訓練中⇄
待評估→
已上版→
驗證中→
已交付
「已上版」是凍結點 —— 之前可以往復，之後不回頭
追蹤單位是模型版本（factory_ppe_v20260706），不是模型、也不是單次訓練。
一個版本底下可能跑很多次（調參、重跑、cascade 兩段），那是往下鑽才看的。
這一層在現有命名裡已經存在：前半段是版本，後半段是執行變體。只是沒被當成追蹤單位。
04 · 三條規則
流程怎麼走
上版前可以往復
待評估 → 重訓 → 訓練中，仍然是同一版。資料變了才算新版本，只調超參不算。
上版後凍結，不回頭
版本被鏡頭掛住就固定了。有問題不是把舊版退回訓練，而是開新版。
鏡頭掛版本，不能超前
鏡頭階段 ≤ 它掛的那個版本。版本推進會解鎖鏡頭往前，鏡頭卡住不影響版本。
換版是獨立動作：某鏡頭已驗證完成、模型要重訓時，它停在舊版不動。
每次狀態變更固定做三件事：寫台帳、指派負責人、通知。全自動，沒有人工登記步驟。
05 · 範圍
做到上版決策為止
在範圍內
- 訓練啟動與執行記錄
- 訓練完成／失敗的偵測
- 版本狀態與負責人
- 上版門檻（可自動檢查的下限）
- 交接給驗證：這版動了什麼、該盯哪裡
不在範圍內
- 驗證階段內部怎麼跑
- 驗收人力與排程
- 誤報回報量的規劃
- 鏡頭層級的交付管理（ISMS 既有）
驗證仍然需要人工，這是前提不是待改進項。VLM 只負責讓客戶端不看到過多誤報，不參與驗收判斷。
06 · 需要決定
兩件事
- ISMS 能不能寫入 —— 決定是在 ISMS 加一張表，還是外掛一套。兩者工作量差很多
- 同時在跑的版本數上限 —— 目前約 15–20 個未結案，要不要設天花板
其餘都是參數（門檻數值、逾時天數），不影響流程成立，可邊做邊調。
我方處理中
訓練快照與 ISMS 的鏡頭名稱對應 —— 兩套命名獨立，目前無共同識別碼。不解就算不出「這版該驗哪幾支鏡頭」。已知問題，不需在此討論。