如果爭議案件從未進入調查階段，它為何能在我們的儀表板上顯示通過？

僅追蹤已進入佇列案件的儀表板，可能會遺漏從未進入該佇列的有效通知。在此合成的表單後模型中，正常路徑基準回報 COMPLIANT，而狀態探索則發現在模型第 6 天存在一條從有效通知通往 ClosedIncomplete 且未經調查的路徑。反例詳細展示了該路徑上的每個事件。

PROVEN 是否意味著我們的爭議處理流程符合 Reg Z 或 Reg E？

否。PROVEN 僅代表已設定的屬性在所提供有限模型的已探索狀態中普遍成立。實際的合規性取決於該模型是否與實際線上工作流程相符、通知是否合格，以及適用哪些法規與例外條款。本示範僅為審查輔助工具，而非法律意見書。

這項工具能否檢驗我們線上的實際爭議佇列或卡片網路案件？

本錄製示範使用四個合成的 JSON 工作流程模型。它並未與銀行佇列、核心系統、通知生成器、Visa 或 Mastercard 系統或消費者記錄建立即時線上連線。真正的評估首先需要針對實際流程與適用義務建立經驗證的模型。

未通過的檢驗究竟能為我們的合規團隊提供什麼？

針對失效的已設定屬性，檢驗器會展示狀態圖、帶有模型化事件與時鐘數值的有序反例追蹤軌跡，以及可匯出的審查證書。在表單後範例中，該軌跡在次要表單逾時後進入 ClosedIncomplete，且未經調查。證書記錄了所檢驗的模型與限制；它並非主管機關的背書。

它是如何處理營業日與帳單週期的？

本示範採用了簡化的編碼時鐘。其 Reg Z 解決檢驗將「兩個完整帳單週期」的條件簡化為 90 個日曆日的上限，且其 Reg E 的 10 個營業日檢驗採用固定的 7/5 換算比率，未扣除國定假日。例外條款、延長期間與法規適用性均需要獨立的專家審查。

搜尋是否可能在發現錯過的截止期限前就停止？

探索上限設定為 200 個日曆日。若在達到該上限前，適用的時限屬性未發現反例，檢驗器將回報 BOUNDED 而非 PROVEN。在已探索路徑內發現的反例依然清晰可見。

是否由 AI 模型來裁定工作流程是否通過？

否。在經過設定時，可選的模型合成代理可以提出工作流程模型建議，但探索其狀態並指派 PROVEN、COUNTEREXAMPLE 或 BOUNDED 的是由確定性 Python 程式碼負責。隨附的四個案例在沒有大型語言模型（LLM）或即時網路連線的情況下即可執行。

爭議工作流程驗證

這些畫面來自所提供的合成工作流程。先從基準的綠色結果開始，然後沿著它從未檢查的分支深入查看。每張圖片均可開啟全螢幕原尺寸。

01 / 比較檢驗結果

綠色僅描述單一路徑

標準追蹤器沿著填妥表單的路徑進行，並回報 COMPLIANT。狀態探索則詢問另一個可到達的分支是否會失效。在相同的自創表單後模型上，它回報 NON-COMPLIANT ，表示不符合已設定的規則。

這兩項結果回答了不同的問題。基準表示其選定的路徑通過了測試；但對於在調查前就脫離該路徑的通知，它卻隻字未提。

審查面板針對所提供的表單後工作流程，將標記為 COMPLIANT 的正常路徑追蹤器，與標記為 NON-COMPLIANT 的狀態探索進行對比。 — 比較面板指出了確切的落差：追蹤器只檢查了預期的路徑，而驗證器則深入探索了失效的分支。

02 / 尋找分支

次要表單即為分叉點

在狀態圖中，模型化的通知會從 Messages Submitted 轉移至 Secondary Form Requested。填妥表單會繼續走向路由分派與調查。而逾時則會走向 Closed Incomplete。檢驗器在此提供的模型中探索了 93 個可到達狀態，並發現四項已設定的屬性失效。

合成表單後工作流程的清晰應用程式視圖：紅色路徑從 Secondary Form Requested 分叉到 Closed Incomplete，具有 93 個可到達狀態與四項已設定的失效屬性。 — 沿著狀態圖中的紅色分支查看。該分支結束於 Closed Incomplete，而填妥表單的分支則繼續向右延伸。

03 / 審視見證反例

追蹤軌跡為審查者提供了一條可供質疑的路徑

失效的屬性會附帶一個有序的反例。在此模型化的序列記錄了第 0 天的提交、第 1 天要求填寫次要表單，以及在第 6 天因逾時而結案。在此路徑上，該通知從未進入調查階段。

反例追蹤軌跡列出了第 0 天、第 1 天與第 6 天的模型化事件，最終結束於 ClosedIncomplete，且未出現調查狀態。 — 該畫面具體指出了每個事件及其產生的狀態。這是一個模型見證反例，而非客戶案件記錄。

第 0 天： 模型化的帳單錯誤通知已提交。
第 1 天： 工作流程要求填寫次要表單。
第 6 天： 逾時使案件轉移至 ClosedIncomplete，且該狀態不存在通往調查的路徑。

04 / 驗證變更

重新路由未填妥的表單

獨立的修復模型會將未填妥表單的通知導向路由分派與調查，而非將其結案。更改該路徑後，所有四項已設定的屬性皆被判定為 PROVEN ，涵蓋 153 個可到達狀態。該結論屬於所提供的有限模型及其編碼屬性。

修復後的合成工作流程將未填妥表單的分支導向調查，並顯示四項已設定的屬性在 153 個可到達狀態中均獲得證實。 — 將此分叉點與先前的圖形進行比較：在此自創版本中，通往 Closed Incomplete 的路徑已不復存在。

第二個工作流程 / 時效性

批次延遲呈現出不同的失效形態

夜間批次處理範例測試了在另一個獨立合成模型中編碼的有條件暫時性退款假設。其中一條路徑直到第 14 個營業日才首次入帳模型化的退款，超過了該模型 10 個營業日的限制。檢驗器在 79 個可到達狀態中的七項已設定屬性裡傳回了一個反例。真實的 Reg E 例外情況與適用期限需要另行專案審查。

合成的夜間批次工作流程顯示了 79 個可到達狀態、一項失效的已設定屬性，以及超出編碼 10 個營業日限制的暫時性退款路徑。 — 在此，狀態圖確實到達了暫時性退款狀態，但模型時鐘的數值已逾期。該失效屬性與時效性相關，而非調查路徑無法到達。

審查路徑	此處觀察到的內容	仍待釐清的事項
正常路徑基準	預期路徑回報 COMPLIANT。	它從未探索次要表單的逾時分支。
狀態探索	在提供的表單後模型中，存在 93 個可到達狀態，以及一條未經調查即通往 ClosedIncomplete 的路徑。	所提供的模型是否與實際工作流程相符。
修復後模型	所有四項已設定的屬性在 153 個可到達狀態中皆成立。	這些屬性是否涵蓋了每項適用的義務或例外情況。

審查路徑

此處觀察到的內容

仍待釐清的事項

正常路徑基準

預期路徑回報 COMPLIANT。

它從未探索次要表單的逾時分支。

狀態探索

在提供的表單後模型中，存在 93 個可到達狀態，以及一條未經調查即通往 ClosedIncomplete 的路徑。

所提供的模型是否與實際工作流程相符。

修復後模型

所有四項已設定的屬性在 153 個可到達狀態中皆成立。

這些屬性是否涵蓋了每項適用的義務或例外情況。

審查您目前的審查機制從未看見的路徑。

一個實用的第一步，是繪製出合格通知在何處進入、等待、路由分派與結案的完整路徑圖。

在任何人將模型視為實際線上流程的證據之前，我們能協助構建工作流程模型、選擇欲測試的合規義務，並與爭議營運、工程及合規專家共同審查反例。

工作流程評估

✓ 通知受理與路由分派圖
✓ 死胡同與逾時分支
✓ 規則適用性與例外條款審查
✓ 供簽核的模型假設

驗證設計

✓ 明確的狀態與轉換模型
✓ 設定好的調查與時鐘檢驗
✓ 反例審查工作流程
✓ 證據與限制記錄

有效的申訴通知可能在調查前就消失無蹤。而預期路徑卻依然顯示合規。

從未進入佇列的案件，能輕易避開看似乾淨的儀表板。

模型檢驗如何運作

編碼路徑

檢視可到達狀態

展示證據

審讀路徑，而不只是看裁決結果