工作流
兩個工作流，以及對其中一個的誠實說明。
這裡的工作流是一串固定的、被允許的操作，並宣告預期的輸出雜湊。若重播產生不同的雜湊，那不是資料集動了就是程式碼動了——兩者都應該被看見。
登錄
| 工作流 | 操作數 | 可從發行包重播 | 輸出 sha256 |
|---|---|---|---|
prime-distribution-baseline | 4 | 否 | — |
stable-baseline | 7 | 是 | 5b93e5f26256… |
為什麼隨附的那個無法重播
v1.0 發行包含有已晉升的資料集，位於 stable_data/shards/。它不含資料湖的索引（lake_state/lake_index.sqlite）或第一世代的湖分片（lake_data/primary/shards/）——那些只出現在 v0.8 與 v0.9 的包裡。基線工作流以分片索引定址資料湖，所以在發行包裡它什麼也定址不到。
拿它對著發行包跑，過去會產生三個未處理的例外，以及更糟的一個自信的答案：family_counts 回傳 status: OK、decision: ALLOW 與一整組零計數，而它開啟的檔案數是零。索引缺失讀起來，跟一個真的沒有質數的區間一模一樣。
這已經修好。空的分片選取現在會拋出例外，而不是回傳一個空的聚合，CLI 將它回報為 status: NO_DATA 並以結束碼 2 退出。四個操作現在都以同樣清楚的方式拒絕：
shell
$ python lake/mmrf_lake_cli.py query \
--request query_examples/family_counts.json
{
"status": "NO_DATA",
"reason": "No shards registered for index range [0, 20)."
}
exit 2替代方案
穩定分片基線計算同樣的四個聚合量——外加間隔直方圖、模 6 與模 210 的剩餘分布、以及數量級分段——直接從已晉升的分片算，不需索引也不需網路。
shell
python workflows/stable_baseline.py --project-root . \
--output results_v10/stable_baseline_output.json- workflow_id
stable-baseline- workflow_version
- 1.0.0
- 工作流 sha256
36f765220749b287cde604bbff48b2c1b31e1c212855afeac3c10498bfd22569- dataset_manifest_sha256
a5caea22a57efaac915c00dd92c655b1126e0b6d9b2b93790e48bc167733e0d1- 預期輸出 sha256
5b93e5f26256e16f6290cea957df45aaf78de672ca0e80bf17ef2419b4d50ac3- 資源估計
- 不到一秒；讀取約 2 MB
- 安全分類
- L0_PUBLIC_MATH，僅聚合
它強制的前置條件
- 穩定清單必須雜湊出它自己記錄的那個值。
- 磁碟上的分片數必須與清單相符。
- 分片內的質數總數必須與清單相符。
- 旗標欄中每一個被設起的位元都必須對應到一個具名的族；無法命名的位元會中止執行，而不是被悄悄少算。
每一條都是原本可能無聲失敗的條件，而且每一條都正是先前那個缺陷躲過的那種檢查。結果在研究頁。