業務語意

同一句「客戶數」，在兩個報表裡可能是兩件事。

行銷把 trial 算客戶，財務只算付費帳戶。欄位名稱救不了這個歧義；要在 Agent 與變更審查裡少走彎路，得把名稱、owner 和證據期待寫成能被檢查的契約。

這次要釐清的事：release 前有人要改訂單模型，而「月活躍客戶」會受影響。審查者需要知道它對應哪個 governed subject、誰負責，以及這個詞需要什麼證據；不是讓 Agent 從欄位名稱自己推理。

把定義留在可審查的地方

把術語寫成版本控制下的契約

在 semantic 檔旁維護版本 1 的 dbcli.contracts.json。每份契約有 canonical name、model:／field:／relationship:／metric: subject 和 draft、approved、deprecated 狀態。

先驗證，再讓 Agent 看見已核准的定義

契約檔有錯時，先修檔案，不要把它當 context。通過後可輸出或搜尋已核准契約，讓「客戶」指的內容有明確來源。

dbcli contract validate --format json
dbcli contract context --format json
dbcli contract search customer --format json

變更前檢查定義是否還站得住腳

evidence policy 可選 none、receipt-required 或 verification-required。設計要改前跑一次 drift；本機 semantic 證據過期或不一致時，就把它列為審查議題，格式不合的產物則會被判為 invalid 而非 stale。

dbcli contract drift --format json