目前看得到鏡頭在哪一站，看不到模型在哪一站。這份提案補上模型這條軸。
觸發後不一定要人：配方沿用上一版就自動開訓，配方要變才等人決定（見「進入」）。
「已上版」是凍結點 —— 之前可以往復，之後不回頭。有問題不是把舊版退回訓練，而是開新版。
鏡頭掛的是「版本」，不是「模型」 —— 所以某支鏡頭已驗證完成、模型卻要重訓時，它停在舊版不動，不會被拖回去。
其中三個模型就吃掉 115 支。看到 136 個點，實際只有 7 件事在進行 —— 壓縮比接近 20 倍。
其他站也一樣：訓練 38 支鏡頭 ＝ 5 個模型；找有效資料 56 支 ＝ 6 個模型。
所以「哪些模型訓練中、哪些結束需查驗」現在只能人工去對，模型一多就對不完。
| # | 決定什麼 | 何時 |
|---|---|---|
| 1 | 配方變更 —— 這一版怎麼訓 | 要改超參／架構，或新模型 |
| 2 | 訓練去向 —— 上版／重訓／退回／終止 | 該版跑完（含失敗） |
| 3 | 換版 —— 哪些鏡頭換過去 | 新版上線後 |
例行重訓不佔你的時間：配方沿用就自動跑，因為閘門在上版、不在啟動。訓練跑了不上版沒有傷害，只花 GPU。
自動的部分：登記、狀態變更、心跳與死亡偵測（含 OOM killer、機器重開）、門檻計算、退回路由建議、涵蓋鏡頭清單、通知、部署執行。
| 結束即指派 | 沒有「待認領」狀態，不會有無主的東西 |
| 每日摘要 | 即時推播漏看了，隔天還會出現 |
| 逾時升級 | 停太久提醒本人，再久升上層 |
| 心跳偵測 | 訓練靜默死掉也會被抓到，不會無聲消失 |
目前最大的漏洞正是最後一條：現行做法只認 log 印出來的錯誤，被 OOM killer 砍掉的訓練會永遠卡著沒人發現。
誤報驗收仍然需要人工，這是前提不是待改進項。VLM 只負責讓客戶端不看到過多誤報，不參與驗收判斷。
其餘都是參數（門檻數值、逾時天數、終止條件的 N），不影響流程成立，可邊做邊調。
訓練快照與 ISMS 的鏡頭名稱對應 —— 兩套命名獨立，目前無共同識別碼。不解就算不出「這版該驗哪幾支鏡頭」。已知問題，不需在此討論。