結論

決策表的矛盾訊號：同一個真實案例同時命中兩列、兩列給出相反結論。這時最誘人的修法是在表內處理 — 加優先序、加 tie-breaker、把其中一列改窄。比較穩的修法在表外：矛盾通常代表案例承載著兩種身分、而表把兩種身分當成一種在判 — 缺的是一個上游區分維度、補一個前置澄清問把身分拆開、兩列就各自回到自己的適用域、矛盾自然消失。

判別兩種修法的條件：矛盾案例拆開身分後、兩列的結論各自都對 → 缺上游維度、補澄清問；拆不出身分、兩列就是對同一件事意見相左 → 表內規則真衝突、要改規則本身。

為什麼逐列檢查抓不到

決策表的每一列通常各自正確 — 「產品本身是軟體 → 自建」對、「需求是某平台的標準域 → 用該平台」也對。錯不在任何一列、在兩列的適用域有重疊而設計者沒看到：重疊區的案例會同時觸發兩條路。逐列 review 驗證的是「每列單獨成立嗎」、永遠不會把兩列放進同一個案例裡比。

偵測需要 dry-run：拿一個真實、具體、帶完整語境的案例（不是為驗證表而造的乾淨例子）、從頭走一遍表、記錄命中了哪些列。乾淨例子只會命中設計者預想的那列；真實案例自帶模糊地帶、才會踩進重疊區。

反模式與修法

修上游維度的具體形式：在表之前加一個澄清問、問題的答案決定案例帶著哪個身分進表。澄清問要放在表前而不是表內 — 它不是表的一列（它沒有結論）、它是表的前提。

跟其他抽象層原則的關係

• #127 Process content 結構由最大差異維度決定 與 #128 Data topology 是第 6 audit 維度：同屬「框架缺維度、用案例暴露」家族。#127/#128 的維度缺口由新類型的 process 案例暴露、本卡的維度缺口由判讀矛盾暴露 — 矛盾是比「套不進」更尖銳的訊號、因為它給出兩個都自信的錯誤答案。
• #153 Review 漏抓先分 design gap 與 execution gap：#153 立卡的情境是 review 流程的漏抓、本卡把它的診斷分流延伸到決策表設計 — 決策表矛盾是 design gap 的一種具體形態 — 修法是改框架（補維度）、不是改執行（要求執行者更小心地選列）。把矛盾歸因於「執行者判斷力不足」就是 #153 警告的誤診。
• #69 Test-First：先看到 RED 才相信 GREEN：dry-run 真實案例等於給決策表跑測試 — 表設計完只用設計者預想的例子驗證、等於只跑會 GREEN 的測試；真實案例是會 RED 的測試、RED 出現的位置就是重疊區。
• #58 篩選類指令的澄清時機：前置澄清問的機制同源 — 指令 / 需求在進入執行前先把歧義拆開、成本遠低於執行到一半發現走錯路。

觸發 case

一份 SaaS 設計訪談 skill 的「交付形態 gate」有兩條規則：「產品本身是軟體 → 自建」、反向問「核心流程是某平台的首頁文案 → 先用該平台」。讀者旅程 reviewer 用真實案例 dry-run —「做一個給健身教練管理學員課表跟收款的 SaaS」— 兩條同時命中：它是軟體產品（命中前者）、「課表 + 收款」是垂直平台的首頁文案（命中後者）、結論相反、執行者只能自由心證。

拆身分後矛盾消失：這句需求可以是「要賣給眾多教練的產品」（垂直平台是市場競爭對手、走自建）、也可以是「教練自己管理學員的工具」（垂直平台正是該用的託管形態）。修法是 gate 前加澄清問「這個軟體是要賣的產品、還是經營業務的工具？」— 兩列規則本身一字未改、各自回到正確的適用域。

判讀徵兆

• 設計任何判讀表 / 決策表後、至少用一個真實案例（帶完整語境、不是教科書例）從頭 dry-run、記錄全部命中列。
• 執行者回報「這個 case 兩條規則都說得通」— 別當成執行者的問題、當成表缺維度的訊號。
• 修表時發現自己在加優先序或把列改窄 — 停下來問「重疊區的案例是不是承載兩種身分」。