有些值記錄已做出的決策，有些值回答目前資料是否符合條件。把兩者塞進同一個狀態欄位，就很難判斷退款、資料修正或期間切換時，究竟應該更新什麼。
在電商平台中，我將已授予的合作夥伴等級與依交易計算的資格分開。本文省略實際名稱與商業門檻，重點是不同資料在時間上的意義。
儲存決策，計算當下答案
| 資料 | 判斷依據 | 後續修正的處理 |
|---|---|---|
| 已授予等級 | 已記錄的業務決策 | 依定義的審核或調整流程處理 |
| 目前資格 | 期間統計與設定規則 | 依修正後的輸入重新計算 |
| 已完成撥付 | 已發生的帳務事件 | 保留事件，再做調整 |
用今天的資料重算過去的決策，可能會抹去當時為什麼成立。反過來，把目前資格另存一份，也意味著每次退款、修正與期間切換都必須記得更新。
目前實作使用共用資格計算，並由呼叫端明確傳入期間，不依賴執行環境的本地時鐘推測。
資格與入帳分開處理
記錄佣金與決定能否撥付，是兩個不同的操作。資格可能在建列後改變，因此撥付時需檢查適用條件，先認領可支付的紀錄，再將金額入帳。
退款同樣需要原始計算基礎。若拿今天的費率去沖回先前事件，即使兩次計算各自合法，也可能得到不一致的金額。
彙總與個別查詢維持相同語意
後台統計出的資格分布，應與逐一查詢帳號的結果一致。目前實作有個別與彙總查詢路徑，測試核對兩者的規則、空值及期間選擇。
這是容易產生規則分歧的地方。看似只是報表的查詢，可能成為第二套業務判斷。需要一致的是語意與邊界行為，而不只是把查詢數量降到最少。
當輸入與期間明確時，可以計算目前答案；當「這個決策曾經發生」必須在日後變更後仍然成立時，就需要保留紀錄。