重點摘要
- 驗證（verification）是 工作中(WIP)→協作(Shared)→送審核定(Published) 之間的閘門：把「廠商說交了」變成「業主確認可用」。
- 三個層次由淺到深：完整性（該交的都交了嗎）→ 合規性（符合規定嗎）→ 可用性（拿來用得了嗎），任一層不過即退件。
- 合規性驗證有四個具體面向：幾何、屬性、命名、座標—各有各的檢核方法與常見地雷。
- 驗證不是竣工才做一次，而是每個交付里程碑都做：交付前廠商自驗、交付時協調員整合驗、里程碑業主審查。
- 屬性與命名這類結構化檢核，正走向以 IDS 自動化—業主的驗證人力應逐步移往需要判斷的地方。
為什麼交付要「驗證」
廠商把模型與文件交上來，不代表就過關。ISO 19650 在交付流程末端有一道資訊驗證（verification）：業主/PCM 要確認收到的資訊對不對、夠不夠、能不能用，達標才核准進入下一狀態（送審核定(Published)），不達標就退件。沒有驗證，CDE 裡的「送審核定(Published)」就只是個資料夾名稱，不是品質保證。
驗證 = 把「廠商說交了」變成「業主確認可用」。是 工作中(WIP)→協作(Shared)→送審核定(Published) 之間的那道閘門。
驗證的三個層次
| 層次 | 問的問題 | 怎麼驗 |
|---|---|---|
| 完整性 | 該交的都交了嗎？ | 對照 EIR/MIDP 交付清單，逐項點收（缺件退回） |
| 合規性 | 符合規定嗎？ | 命名規則、座標單位、檔案格式、LOD/LOI 是否達 EIR 要求 |
| 可用性 | 拿來用得了嗎？ | 模型可開啟、屬性可讀、IFC 可匯入業主軟體、衝突已解 |
三層由淺到深：先確認有交，再確認合規，最後確認能用。任一層不過即退件。
合規性怎麼驗：幾何、屬性、命名、座標
「合規性」一詞很抽象，落到模型上就是四個具體面向。你的驗收檢查表應該照這四塊編：
| 面向 | 驗什麼 | 常見地雷 |
|---|---|---|
| 幾何 | 元件建到約定 LOD 了沒？有沒有用面片、量體充數？重複元件、破面？ | LOD 300 的機電用示意方塊交差；同位置元件重疊兩份，數量表全錯 |
| 屬性 | EIR/LOI 要求的必填屬性都填了嗎？值域、單位、格式對嗎？ | 屬性欄存在但值為空；防火時效填「1hr」「60」「一小時」三種寫法混用 |
| 命名 | 檔名、模型名、元件命名符合 EIR 命名規則嗎？ | 檔名少一段流水碼；版本碼手動亂跳，CDE 排序全亂 |
| 座標 | 共用座標系、高程基準、真北/專案北設定一致嗎？ | 各專業模型各自原點，一疊圖全部錯位，衝突檢查形同虛設 |
實務建議：座標與命名放在第一次交付就驗死—這兩項一開始錯、後面每一版都錯，重作成本隨時間翻倍。幾何與屬性則配合 LOD 演進（200→300→350）逐里程碑加嚴。
驗證時點：不是竣工才驗一次
最常見的驗收失敗，是把驗證全部堆到竣工—那時發現屬性缺一半，已經沒有時間也沒有籌碼要求重作。正確的節奏是把驗證綁在交付流程的每個關口：
- 交付前（廠商端）：任務小組送協作(Shared)前依自主檢查表自驗，附自檢報告。沒過自檢的東西不該離開工作中(WIP)。
- 每次交付時（整合端）：協調員收到各專業模型，先驗座標與命名（不合即退，不進整合），再跑衝突檢查與屬性抽驗。
- 里程碑審查（業主端）：對照 BEP 與 EIR 逐項審查，決定核准進送審核定(Published)或退件。這是契約意義上的驗收點。
- 竣工移交（最終驗）：以 AIR/維運需求為準做最終驗證—此時應該只是「確認最後一哩」，而不是第一次認真看模型。
原則：越早驗、越便宜。同一個命名錯誤，在第一次交付抓到改一個檔；在竣工抓到，改的是兩年份的版本紀錄。
誰驗、用什麼證據
- 廠商自驗（第一層）：送審前依自主檢查表自查，附自檢報告。
- 協調員整合驗（第二層）：彙整模型、衝突解決率、可用性檢核。
- 業主／PCM 審查（第三層）：對照 BEP 與 EIR 逐項審查，做最終核准。
驗證要有證據，不接受口頭宣稱：自檢報告、衝突矩陣、視點截圖、版本紀錄、審查意見與核准確認。本平台的 BEP 逐項審查＋自動對照（已填/缺漏/需確認）即是把完整性與合規性驗證系統化。
退件與重送
驗證不過 → 退件並附明確意見（哪項、為何、要求行動）→ 廠商修正重送 → 重新驗證。這條「送審→驗證→退件→重送」的回圈，配合 CDE 版本狀態與 BEP 審查意見，形成可追溯的交付品質紀錄。
退件意見要可執行：寫「B3 機電模型 42 個閥件缺 Model 屬性，清單如附件，下次交付補齊」，不要寫「屬性不完整，請改善」。前者廠商照單修，後者只會換來一模一樣的第二版。
自動化驗證的未來：IDS
上面四個面向中，屬性、命名、部分幾何規則本質上是結構化比對—這正是機器最擅長、人工最容易漏的部分。buildingSMART 的 IDS（資訊交付規範） 就是為此而生：把 EIR 的屬性需求表寫成機器可讀的規格檔，檢核軟體讀入 IDS 與 IFC 模型後逐條自動比對，上萬個元件全數檢核、不靠抽查。
對驗證流程的意義：
- 廠商自驗與業主複驗用同一份規格，「你的軟體驗的跟我的不一樣」的爭議消失。
- 完整性與合規性大幅自動化，業主的驗證人力移往可用性與工程判斷（衝突是否真的解了、設計是否合理）。
- 驗收標準在招標時就是可執行檔，而不是交付時才開始解讀的文字。
業主/經理的實作要點
- 先定驗收標準：EIR/BEP 就把「怎樣算過」寫成可驗收條件（如「衝突矩陣重要衝突歸零」），驗證才有依據。
- 三層分工別跳級：缺件就退（第一層），不必進到逐項合規；別讓業主花時間驗本該廠商自驗的東西。
- 座標命名首驗定生死：第一次交付把座標與命名驗死，後面的每一版才有共同基礎。
- 證據留痕：每次核准/退件都留紀錄，作為里程碑關卡與稽核軌跡。
- 能自動的交給機器：結構化檢核逐步導入 IDS，人力集中在需要判斷的審查。
資訊驗證是 ISO 19650 交付鏈的收尾—把 EIR 開頭訂的需求，在交付末端真正驗收回來。相關見 ISO 19650 資訊交付落地 與 OIR/AIR/PIR/EIR 四層推導。