業務詞彙表¶
業務詞彙表是建立在數據模型之上的一套活的詞彙。模型中的每個實體資料行都對應一個術語，承載同一概念的資料行共用一個術語，無論它們寫法有多不同。每個術語都可以有定義、一組指向其他術語的類型化關係，以及一份負責其含義的領域專家名單。
詞彙表是一種本體：由概念、概念的定義以及概念之間的關係組成的圖。Provisa 把它對應到存放數值的資料庫結構，因此能夠回答關於你資料的問題。一個概念在觸及資料之前（直接觸及或經由其他概念）只是草稿。詞彙表與指標互相獨立：詞彙說明概念是什麼，指標說明數字如何計算。
這套共用詞彙把業務語言及實體數據連了起來。知道「customer」指代每個帶客戶識別碼的資料行的 AI 代理，不必猜測 cust_id、customerId 及 CUSTOMER_KEY 中哪個才對。它們都對應同一個術語，而定義就在這個術語上。
術語如何推導而來¶
Provisa 會依一條決定性的正規化規則，自動從每個欄位名稱推導出術語：大小寫摺疊、分隔符與 camelCase 斷詞、縮寫展開，以及尾端代理權杖的剝除。
縮寫展開把企業常用簡寫對應為完整形式：cust → customer、txn → transaction、qty → quantity 等。id 及 key 都展開為 identifier。這張表是固定且保守的：st、min、no 這類有歧義的簡寫保持原樣，以免猜錯。
代理權杖剝除會移除尾端的 identifier、code、index 或 reference 權杖。名為 cust_id 的欄位命名的並不是識別碼本身；它是透過一個代理值來指稱客戶。剝掉代理之後，cust_id 與 customerId 就一同落在 customer 這個術語上。只有尾端的權杖會被剝除，而且絕不剝到只剩最後一個：孤零零的 id 欄位展開為 identifier 後便停在那裡。
關鍵在於去重。正規化規則是確定性的，所以 cust_id、customerId 及 CUSTOMER_KEY 都會得到 customer。每個資料行都參照這同一個術語，整理時只需在一處加入定義，而不是三處。
通用短語¶
有些正規化短語太泛，無法單獨成為一個概念。單獨的 name、date 或 identifier 資料行指的是其所在資料表概念的一個屬性，離開那個資料表就不存在。員工有名字，產品亦有名字，但兩者不是一回事。
當一個短語落在通用集合之內，而又有表脈絡可用時，術語會被限定為 <table concept> <phrase>：employees.first_name 正規化為 employee first name，而 orders.id 正規化為 order——因為代理剝除接著會把這個限定短語收攏到它所識別的那個概念上。最後這個情況很重要：orders 的主索引鍵，連同其他表上每個 order_id 外部索引鍵，全都落在 order 上，毋須額外策展。
通用集合涵蓋屬性名詞（name、date、status、type、amount、quantity）、審計軌跡短語（created_at、modified_by、submitted_timestamp），以及另外幾個幾乎每張表都有的字眼。
用業務名稱，而非實體名稱¶
衍生術語遵循資料行的業務名稱：建模者設定了別名就用別名，否則用實體名稱。當 usr_nm 的別名是 user name 時，衍生術語就是 user name，而直接展開 usr_nm 可能會得到 user number。
為資料行設定別名是更徹底的修正。別名會傳到每個讀取該資料行的入口（SQL、GraphQL、AI 代理、目錄），令模型在各處都正確描述自己。重新命名術語只修正一條目錄條目，下一個讀者看到的資料行名稱仍是 usr_nm。介面中的建議術語橫額亦這樣說：先為資料行設定別名，只有在資料行名稱正確而詞彙不對時才重新命名術語。
重新設定資料行的別名會重新推導其建議術語，所以詞彙表一直跟隨模型，從不要求同樣的修正做兩次。一旦管理員為某個術語加入了定義、關係或專家，修改別名就不會移動參照，因為這些工作屬於管理員，會保留下來。
存取路徑式的表名¶
有些資料表名稱描述的是存取路徑而不是概念：user_by_name 是經按名稱查找得到的使用者，並不是另一種實體。當 Provisa 為限定泛化短語而推導資料表概念時，會在連接詞處截斷名稱，所以 user_by_name 變成 user，orders_by_customer 變成 order。
如果不截斷，user_by_name 上的代理鍵會正規化為 user name，與真正的 users.name 屬性衝突，導致一個術語同時指代一個事物及其自身的一個欄位。截斷只作用於資料表概念。在資料行名稱中，by 是複合名詞的一部分，所以 pet_by_name 及 pet_name 會正規化為同一個術語 pet name。
術語何時算是已策展¶
由資料行正規化產生的術語一開始是空白的，只是一個提議，還不算詞彙。只要符合以下任一條件，它就成為已整理的術語：
- 已儲存一段定義。
- 已加入一條關係邊。
- 已指派一位主題專家。
- 策展者已手動將它退役。
整理狀態影響術語的生命週期。當已整理術語的最後一個實體資料行離開模型時，該術語會被棄用並保留：它停止服務，保留編輯者提供的內容，如果同一資料行重新出現會自動恢復。沒有剩餘資料行的未整理術語則直接刪除。
從表重新同步¶
每當一張表被儲存或重新載入，sync_table_refs 便會把該表的欄位與既有的 ref 對帳。新欄位會建立或連結術語；離去的欄位會撤掉自己的 ref；而移除或淘汰的規則會為任何失去最後一個 ref 的術語作出了結。
只有未整理的術語會重新推導。如果您為資料行設定了別名，而建議術語因此變了，參照會轉到新術語。如果術語已整理，連結保持不變，因為修改別名不會推翻管理員對術語的選擇。
一個抽象術語若通往實體數據的唯一路徑經由某個正在離去的術語，它會被淘汰而非移除，在重新接線之前先保住概念結構。
關係¶
術語透過具類型的邊與其他術語產生關聯。受支援的關係類型如下：
| 類型 | 含義 |
|---|---|
KIND_OF |
來源術語是目標術語的一種。 |
PART_OF |
來源術語是目標術語的一個組成部分。 |
SYNONYM_OF |
兩個術語在此領域中可互換。 |
RELATED_TO |
一種鬆散的關聯——沒有更強的說法貼切。 |
VALID_VALUE_OF |
來源是目標列舉或值域的一個允許值。 |
DERIVED_FROM |
來源由目標計算而得或取自目標。 |
REPLACES |
來源取代了已淘汰的目標。 |
PREFERRED_TERM_FOR |
相對於不建議使用的目標，來源是首選術語。 |
TRANSLATION_OF |
來源是目標的地區設定或語言翻譯。 |
ANTONYM_OF |
來源在語意上與目標相反。 |
關係有方向性。UI 會同時顯示外向邊（此術語 → 另一術語）與內向邊（另一術語 → 此術語），並各自以自己的白話說法標示方向。
這些邊存放在 glossary_term_edges 中，這是一張宣告為聯結（junction）關係的關聯表：它的 rel_type 欄是判別欄，因此上表中的每種類型都是兩個 GlossaryTerm 節點之間獨立的 Cypher 關係類型，而不是具體化節點上的一個屬性。該表隨中繼資料綱要的其餘部分一併佈建，在圖用戶端中不會顯示為節點：它就是邊。它沒有任何專屬於業務術語表的地方：它的宣告方式與你在自己的表上宣告聯結完全相同，並且由同一套程式碼讀取。
抽象術語¶
抽象術語自身沒有任何實體欄位 ref。當某個業務概念橫跨多個具體術語時就用它：先立一把傘，再接線到真正持有欄位的那些具體術語。舉例來說，revenue 可以是抽象術語，由 order amount、adjustment amount 與 refund amount 各拉一條 PART_OF 邊指向它。
無法經關係圖連到任何實體資料行的抽象術語，是一個懸空的提議。它不會出現在代理的術語搜尋中，亦不會出現在中繼資料匯出中，因為不指向任何數據的術語回答不了任何問題。
消費介面的准入規則¶
消費介面可以提供的術語，必須滿足三項條件：
- 在役——未退役（策展者將它撤出服務）且未淘汰（它失去了最後一個欄位，僅因刪掉它會留下懸空之物而被保住）。
- 已定義——它帶有一段定義。從欄位名稱推導而來的術語是一個權杖，不是一個含義。沒有定義，它就只是一項等待策展者的提議，絕不是代理能據以立足來回答問題的詞彙。
- 已扎根——經由在役術語，連通到至少一個持有實體欄位 ref 的術語。詞彙表是通往數據的入口，因此每條鏈都必須終止於某個欄位。
連通性會沿着圖傳播：抽象術語可以經任何能連到數據、且仍在服務中的相鄰術語連到數據。停止服務的術語不傳導，所以已退役的術語不會令依賴它的術語繼續存活。
中繼資料匯出¶
詞彙表會作為中繼資料匯出的一部分發佈到外部數據目錄。適用同樣的准入規則，只收緊一點：判斷術語是否有根，只看真正會發佈的資料行。如果一個術語的所有資料行都被排除在匯出之外（因為它們的資料表沒有標記為數據產品，或被技術篩選器排除），那麼即使它在控制平面中有參照，就匯出而言亦不算有根。
關係邊只在兩端術語都會發佈時才發佈。
欄位資產則獨立匯出。某個術語被排除，並不會把底下的數據藏起來。
把術語排除於匯出之外¶
有些欄位承載的是水電管線而非業務數據：ETL 批次識別碼、行版本、擷取時間戳記。由這類欄位推導而來的術語，其定義可能準確無誤，只是它根本不算業務詞彙。排除於中繼資料匯出這項控制項會把該術語，以及任何以它為終點的關係邊，一併從 Provisa 發佈的目標目錄中扣起，而欄位本身仍會以資產形式匯出。
關鍵在於業務是否使用這個詞，定義寫得好不好並不決定這一點。ETL 批次識別碼的含義很清楚，應該放在面向工程師的詞彙表裏，但不該出現在業務目錄中，與 customer 及 revenue 並列。
使用詞彙表¶
在 UI 中開啟 管理 → 詞彙表。左側面板列出所有術語；點選其一即可開啟其詳細檢視。從那裡可以：
- 重新命名術語，改動它的措辭而不搬動它的欄位。
- 加入定義：自行輸入，或點擊 AI 草擬按鈕，依術語名稱、其實體欄位及其關係生成一個起點。草稿在你確認之前不會儲存。
- 移動 ref 以合併兩個術語：在任一實體 ref 旁的下拉式選單中挑選目標術語。若來源術語因此失去最後一個 ref，系統會自動依移除或淘汰的規則作出了結。
- 加入關係，連結此術語與另一術語，並從封閉集合中選擇類型。既有的邊可就地改類型，毋須先刪再加。
- 指派專家，以使用者 ID 指定，種類可為
expert或author。 - 退役某術語，將它撤出服務。它保留自己的欄位，在此處仍可編輯，但代理的術語搜尋與中繼資料匯出都會略過它。日後概念回歸時可再還原。
- 批次生成定義，一次補齊所有空白的定義。只會寫入空白的定義；人寫的文字絕不會被覆寫。
- 批次生成關係，就整份術語清單提議具類型的邊。格式有誤的提議——未知的術語名稱、指向自身的邊、無法辨識的類型——會被自動丟棄。
沒有定義的術語上會出現提議中橫幅，它會告訴你該術語是未定義（去替欄位設別名，或補上定義）還是未扎根（把它關聯到某個持有欄位的術語）。看到這個橫幅，就表示該術語尚未能被代理或目錄觸及。