一致性

沒跑過的檢查，不是通過的檢查。

MMPF 之所以以發布候選的身分出貨，部分原因是它的帳本從未被官方 MMLC Runtime 執行過。2026 年 8 月 1 日跑了。第一次執行的結果是：一個 PASS、一個稽核失敗，以及兩個根本執行不了。

第一次執行

MMPF 自己的 TEST_RESULTS_V1.md 一直寫著 Official MMLC local execution: NOT RUN — offline GitHub resolution failure。把這件事寫下來、而不是讓那一列空白，正是這個章節得以存在的原因。

帳本	第一次執行
`mmpf_bandit_decisions`	PASS
`mmpf_factorization_reconstruction`	FAIL —— 局部稽核
`mmpf_conformal_assurance`	執行前即被拒
`mmpf_policy_voi`	執行前即被拒

被當成標籤用的時間索引

兩個被拒的錯誤是同一個：兩筆交易共用了同一組 (series_id, time_index)。那一組是時間序列座標 —— 一個 series 每個 tick 只能有一筆觀測，這正是「帶落後的參照」之所以有意義的原因。

有兩份帳本把案例名放進了 series_id，於是一個案例的六個（或四個）量全部落在同一個鍵上。而 tick 本來就是對的：case 017 的 time_index 從頭到尾都是 17，那 300 個值一個都不需要改。

已驗證

專案自己通過的那份帳本本來就是對的 —— mmpf_bandit_decisions 用單一 stream，time_index 從 0 跑到 599。修法照它自己的慣例，不另外發明一套。

宣告的來源不是真正的來源

帳本能執行之後，180 筆裡有 140 筆、120 筆裡有 110 筆被判不健康，而 factor-step-001 失敗。全部是同一個缺陷：一筆交易宣告了一個 source_id，而那個物件的值並不是它的 base 的來處。

factor-step-001 是最清楚的一例。它的算術完全精確 —— 268435459 × 576460752303423619 一位不差就是宣告的那個 27 位數乘積 —— 所以執行報告把「算出來的值」與「期望值」兩欄印成一模一樣的數字，旁邊卻標著 FAIL。數值沒有任何問題。有問題的是它對「自己從哪來」的宣稱。

未覆蓋

那些失敗的 base 裡，有一部分確實等於同案例中較早的某個結果，把它們鏈接起來很容易。但浮點數相等不是衍生關係的證據，所以我們選擇拿掉那個假宣告，而不是用一個發明出來的宣告去取代它。

修正之後

帳本	交易數	重播	語意雜湊
`mmpf_bandit_decisions`	600	PASS	`e1c86969e1b83459`
`mmpf_conformal_assurance`	180	PASS	`9f91823e1d0b35e1`
`mmpf_policy_voi`	120	PASS	`74e7b489d1cb3d08`
`mmpf_factorization_reconstruction`	2	PASS	`f1786ffd2111c0ac`
902 筆交易	4 / 4

所有宣告的數值在修正前後都已經是精確的 —— 902 筆交易裡，0 筆數值不符。官方 Runtime 抓到的是血緣與索引。

這兩種缺陷都不是本地測試套組找得到的，因為兩份帳本內部都是自洽的。它們只跟一個「把宣告當真」的 Runtime 意見不合 —— 而那正是「拿獨立實作重播，而不是拿本地的近似品重播」這件事的全部意義。

重現

Runtime 是以 commit 釘死的，所以重播對著的是一個特定建置，而不是 main 當下剛好是什麼。

bash

python -m pip install \
  git+https://github.com/kakon77777-commits/mmlc-runtime.git@7f179aac11dcfd20a73fdc8783f08cab17da1515

for ledger in mmlf/*.yaml; do
  python conformance/replay_official_mmlc.py "$ledger"
done

每份帳本的執行輸出記在 conformance/results/，而倉庫的 CI 會在 Python 3.11、3.12 與 3.13 上跑同樣這四次重播。