title

SMPDC Paper 11｜系統驗證、跨篇可證偽實驗與第一系列結案

english_title

System Validation, Cross-Paper Falsifiable Experiments, and First-Series Closure for Stellar Multi-Primary Persistent Diffusive Computing

series

SMPDC — Stellar Multi-Primary Persistent Diffusive Computing

paper

11 / 11

version

0.1

date

2026-10-17

language

zh-TW

authors

Neo.K × Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

status

First-Series Research Closure — Protocol Specification, Not Empirical Validation

source_format

UTF-8 Markdown, canonical math delimiters $...$ and $$...$$

prerequisites

SMPDC Paper 00–10 v0.1

claim_level

L1 research protocol; embedded limited V0 mock tests where explicitly reported

SMPDC Paper 11｜系統驗證、跨篇可證偽實驗與第一系列結案

——從多主工作流、相位擴散、資訊聚合、確定性提交與異質硬體，走向可重演的科學判決

英文題名： System Validation, Cross-Paper Falsifiable Experiments, and First-Series Closure for Stellar Multi-Primary Persistent Diffusive Computing
研究系列： 群星多主節點持續擴散計算論（SMPDC）
篇號： Paper 11／第一系列 Paper 00–11
研究主構想： Neo.K
研究協作： Aletheia / GPT-6
機構： EveMissLab／一言諾科技有限公司
日期： 2026-10-17
版本： v0.1
狀態： 第一系列形式與實驗規範結案稿；不代表已完成真實 CPU／GPU 端到端 A/B、AI 訓練品質驗證、FPGA 或晶片測試。

作者： Neo.K × Aletheia / GPT-6

摘要

群星多主節點持續擴散計算論（Stellar Multi-Primary Persistent Diffusive Computing, SMPDC）以一個刻意限定於中觀—宏觀的計算執行觀為起點：允許多個持續性邏輯主工作流（Primary Workflow Node, PWN）在 CPU 異質核心等現有實體載體上保持局部自治，藉相位語義啟動有界資訊擴散，依具型別的冗餘協議傳送、驗證與聚合候選，並把計算進度、局部證據與正式提交權威分離。GPU 可用於大批可平行化的關係運算及數值工作片段，但不取代實體 CPU 快取、主記憶體或 I/O 互連，亦不直接取得全域提交權。第一系列前十一篇 Paper 00–10 已依序提出節點、相位、冗餘、推測、抽象指令、程式語言、OS／AI 控制、CPU–GPU 協作、微觀硬體映射及 AI 工作負載適用域的候選契約與反例。

本篇的任務不是再發明一種泛化計算本體，也不藉概念類比宣告性能突破；而是建立一個可被第三方重演、可在負結果下封閉、可清楚判定證據有效性的全系列科學驗證程序。本文提出 SMPDCValidationProtocolV0_1、CrossPaperContractMatrixV0_1、ReproductionManifestV0_1、RunEvidenceBundleV0_1、FalsificationVerdictV0_1 與 SeriesClosureDecisionV0_1 六個高階研究契約，並繼承 Paper 10 的 AIQualityEvaluationWitnessV0_1 與 ExperimentRunVerdictV0_1，不改寫已發表原稿所定義的權威及版本規則。驗證區分 V0 有限狀態／協議測試、V1 現有消費級 CPU／單 GPU 實機、V2 可選的異質平台複驗與 V3 專用硬體驗證；在任何階段都不得以低階 PASS 推論較高階 PASS。

本文定義統一主張—前提—證據—反例映射、跨篇安全與活性分離、強基線選擇、階層式消融、同品質／同成本端到端比較、預註冊統計規格、故障注入、尾延遲、能源／記憶體放大與 Time-to-Quality 判準，以及分層研究結案結果。明確容許「特定工作負載可得到正收益」「僅安全而無效能收益」「效能變快但品質／安全失敗」「未取得足夠證據」「該平台不可測」等不同結果。對 AI 訓練，必須以符合品質門檻的首次達標時間作為主要觀察；對推論，必須有等品質及相同負載條件下的有效交付率與尾延遲；對持續 Agent／Verifier，必須以合法、已授權且可追溯的結果計數。CPU 使用率、GPU kernel latency、模擬事件數與 Python mock 的 PASS 均不能自行充當端到端效能證據。

本篇另提供在一般 Python 3 標準函式庫可執行的有限抽象契約測試、可解析的研究 Manifest、故障反例矩陣與第三方複驗清單。這些附錄僅是 V0 層的研究工具，不是已建成的 SMPDC 編譯器或 Runtime。本文最終結論是：SMPDC 第一系列可以在形式研究與可證偽方案層次完成閉環，而 SMPDC 在現有硬體上是否優於成熟異質計算基線，仍是尚待實證解答的開放問題。

關鍵詞： SMPDC、群星多主節點、持續性擴散、跨篇契約、研究結案、可證偽性、形式驗證、模型檢查、故障注入、實驗再現、AI 推論、AI 訓練、Time-to-Quality、GPU 同步、強基線、消融研究、硬體成本、證據治理。

1. 研究定位：系列結案不能預支實證結論

1.1 這篇到底要完成什麼

Paper 00–10 提供一套候選執行模型與數個相互依賴的契約。若到 Paper 11 只寫「系統很新」「可以像生物腦那樣協作」「應能加速 AI」，即使再寫很多形式符號，也不能形成封閉的科學研究程序。本篇必須回答六個具體問題：

1. 哪些已經成為可檢查的技術定義，哪些仍是待驗證的性能假說？
2. 多個分篇分別正確，是否足以推出整體正確？如果不是，需要哪些跨篇守衛？
3. 同一工作負載上，應和哪些成熟 CPU／GPU／AI runtime 比較，才不會出現稻草人對照？
4. 在何種可事前寫明的條件下，應判定 SMPDC 在某個適用域不成立或不值得採用？
5. 如何讓所有正反證據、測量條件及版本變更可由第三方重演？
6. 即使未來暫時不實作新 CPU、新 ISA 或專用 NoC，第一系列是否仍可作為合格的研究成果封閉？

本文對第六問的回答是：可以，但結案狀態必須標記為「形式／方法論結案」，而不是「系統效能已驗證」。

1.2 四種常被混淆的完成

• DocumentComplete：Paper 00–11 的文字與數學、介面、引用及原始碼完成了版本治理。
• ProtocolVerified：在明確故障模型與有界狀態下，部分安全／活性性質經工具檢查。
• RuntimeValidated：真實可執行程式通過跨模組整合、故障注入及完整 trace 檢查。
• PerformanceValidated：對指定真實工作負載，以成熟調校基線及相同品質成本口徑，取得可重現的端到端差異。

上述狀態彼此不能用一個布林值取代。即使第一狀態為真，其餘仍可能是 INCONCLUSIVE 或 UNAVAILABLE。一個正式系統報告應允許四個欄位同時具有不同結果。

1.3 研究承諾與不主張

研究承諾： 不論結果正負，都保存其證據；不因模型不利結果而事後更改對照組、工作負載、品質閾值或排除樣本規則；不將 PWN、phase、diffusion、replica、commit 等詞改成無法被反駁的任意解釋。

本篇不主張： SMPDC 已優於 Seastar、StarPU、Legion、CUDA Graphs、MoE runtime、Linux scheduler 或成熟編譯器；不主張 AI 一定能比無 AI 的 OS 控制層做得好；不主張「兩路資訊」能必然修復任何錯誤；不主張單機 GPU 可以充當 CPU–CPU 物理互連；不主張新的計算 ISA 已經被實體晶片支援；不主張生物神經網絡與多主 CPU 模型具有微觀同構。

1.4 研究物件的最小可檢驗性

若某項 SMPDC 主張不能指定觀測量、干預變數、失敗判準及可重演對照，即不得列入性能定理或實驗結果，只能保留為設計直覺。當「相位」在某負載中的資訊可由既有排程狀態完全重建時，應允許 phase-blind reduction；當冗餘沒有帶來收益時，應允許退回 R0；當 CPU/GPU 切換成本超過 kernel 本身，應允許 CPU-only；當 AI planner 不優於固定規則，應停用 AI planner。

2. Paper 00–10 的合約來源與不可替代工作

2.1 母狀態不變

本篇沿用 Paper 00 的九元中觀狀態，不重新定義其構件：

$V_t$ 為持續邏輯主節點， $E_t$ 為動態耦合關係， $X_t$ 為局部狀態， $\Phi_t$ 為相位資訊， $\rho_t$ 為工作流至物理核心的承載映射， $\mathcal M_t$ 為資訊流， $\mathcal Q_t$ 為驗證／合併／提交契約， $\mathcal R_t$ 為實體資源與限制， $\mathcal L_t$ 為證據／可見性記錄。注意這是中觀模型：不能由此自動取得 cache line、DDR、NoC、PCIe、CUDA stream 的微觀物理保證。

任何 HardwareTopologyManifest、AI quality 或 compiler proof object 都是對此狀態的受限觀察、具體化或證據，不是替換原始九元母狀態的新本體。

2.2 逐篇來源矩陣

來源契約的具體拼字／欄位定義仍以其各篇 canonical UTF-8 原稿為準。此處為跨篇引用關係，而非破壞版本的中央再定義；需要更動已有契約時，應發布可追蹤的相容性修訂（例如 v0.2），禁止在 Paper 11 靜默「修正」以前的協議。

2.3 既有公開學術先例不能消失

本系列不能把 MIT tagged-token dataflow、Dijkstra–Scholten diffusing computation、Kahn process networks、BSP、MVCC、WAL、hedged requests、Seastar／Legion／StarPU、CUDA graphs、MLIR、LLVM、Linux CPU affinity、Windows CPU Sets、NVIDIA CUDA streams／events、FSDP／ZeRO、MoE、vLLM、SGLang 等已知成果，改名後全部當作原創。SMPDC 可能的新增研究價值是：上述部分成熟機制在保留多個自治主工作流及明確的 typed phase／credit／evidence／authority 之下，是否能形成一套具有可量測淨收益的完整跨層執行協議。本篇之閉環只保證這個問題變得可答，而不預先保證答案為肯定。

3. 科學主張分類、前提與證據責任

3.1 Claim 不是結果；設計圖也不是 Claim 的充分證據

定義一條待驗證主張：

其中 $I_k$ 為不變量或欲檢驗的性質， $A_k$ 為必要前提集合， $W_k$ 為工作負載範圍， $B_k$ 為對照群， $Y_k$ 為被觀察的結果， $\delta_k$ 為預先定義的實質效果門檻， $F_k$ 為反例及失敗規則。 $C_k$ 不因公式寫得複雜而更真；只有具備事前規格、可信資料與可重演審查，它才可能取得有效的判決。

3.2 五類主張不能用同一個證據支持

3.3 Verdict 的固定語義

• PASS：在已宣告的證據等級與預註冊範圍內，相關守衛、資料與效果門檻均滿足；不推論跨平台普遍性。
• FAIL：出現會直接推翻該主張的反例，或其安全／品質／門檻條件被否定；不可用另一成功案例直接抵銷。
• INCONCLUSIVE：證據具備部分可用性，但無法完成結論，例如樣本不足、時鐘不可靠、特定噪音遮蔽效果、模型未於觀察窗內達標但仍存在設限問題。
• UNAVAILABLE：實驗尚未執行、必要裝置或能力不存在、實驗碼未實現或來源缺失。不能當作 FAIL，也不能當作 PASS。

每一個 verdict 需要 scope：安全測試 PASS、工具解析 PASS 與效能主張 PASS 不能在報告中僅顯示一個「全綠」。

3.4 主張變更不可以事後偷換

如果初稿假說是「在具備 4 個 PWN、固定可靠網路與 5 毫秒 deadline 的 verifier 任務上，R1 的 p99 合法完成延遲較 B0 降低至少 10%」，實驗後不得改稱「在任何 mock trace 上觀察到某次提早都算成功」。若必要，應開新版本與新 claim id，將原先失敗的 claim 一併保留。探索性分析可發現新問題，但不得偽裝成事前登記的確認性結論。

4. 跨篇狀態演化與權威邊界

4.1 最小合法執行偏序

給定 epoch $e$ 、work slice $w$ 、主工作流 $p$ 、必要 GPU ticket $g$ 和提交鍵 $k$，合法路徑的一個可能形式為：

PWN.ValidLease
    -> Phase.Ready
    -> Edge.Admitted
    -> Credit.Granted
    -> Message.LogicallySent
    -> Message.AttemptDelivered
    -> Candidate.IdentityValidated
    -> Candidate.Reconciled
    -> [optional Speculation.Validated]
    -> [optional GPU.KernelDone]
    -> [if GPU data used: DeviceVisibility.HostReadable]
    -> CommitProposal.Authorized
    -> CommitAuthority.DecisionDurable
    -> Commit.Visible
    -> [if external effects: OutboxDelivery.Evidenced]

該偏序不是要求所有工作都必經 GPU、冗餘或推測。若無 GPU，相關邊不存在；若使用 R0，不需構造 R1/R2/R3 證據；若僅為唯讀運算，不應憑空產生可修改外部狀態的 commit。必要的依賴邊僅由實際功能及安全契約決定。

4.2 四種不能合併的執行進度

• $P_c$：計算片段已完成多少。
• $P_v$：候選輸入、血緣、版本、結果品質已驗證多少。
• $P_d$：具權威持久化決策完成多少。
• $P_e$：已授權的外部效果被確認交付多少。

這些進度可能不同步；多個 worker 或 GPU 可使 $P_c$ 領先，不能因此使 $P_d$ 或 $P_e$ 自動增長。設計上要容許進度呈非單調：推測分支的計算可撤銷，但已承諾的正式結果若需修正，必須透過新的受控事件，而不是刪去先前 trace。

4.3 核心不可越界關係

四式均是防止不當推論的語義約束，並非某類 CPU、GPU 或 OS 已提供新硬體能力的宣告。

4.4 可重播與物理等價不同

重播需分成三層：SemanticReplay 是同規格輸入與約束得到合法的同等結果；TraceReplay 是在受控事件模型中重演相同事件序列；PhysicalReplay 是實機出現近似乃至相同的執行時序。最後一種通常不能無條件要求，尤其在 OS 排程、GPU 非同步、DVFS 和共享系統有干擾時。測試須註明需要哪一級，而不能把 bitwise trace replay 當作所有並行工作的必要條件。

5. 驗證成熟度、四層實驗階梯與禁止跳躍

5.1 V0｜有限契約與狀態模型

目的：在資源上界明確的模擬環境，檢查失效舊權威、credit 守恆、重送去重、提交前驗證、buffer 可見性、AI 版本、負面路徑和靜止判定。若使用 TLC／Apalache／Spin／有限 Python 狀態探索，須保留模型、探索狀態數、界限和工具版本；有限模型 PASS 不代表所有無界實作狀態安全。 本篇附錄只有小型 Python 契約示例，非完整形式模型檢查。

5.2 V1-CPU｜現有消費級實體 CPU

目的：量測多個持續工作流、相位擴散、隊列、核心親和性、快取競爭、推測／冗餘在真實執行時的開銷和收益。由於使用者當前桌機為舊款 AMD CPU、32 GB RAM 與 RTX 3070，第一輪可以先在該系統進行；實測時仍需由本地 inventory 自動取得正確 CPU SKU、核心數、OS 版本、記憶體頻率與拓撲。本文不聲稱自己已取得這些實測值。

5.3 V1-GPU｜同一現有桌機的單 GPU 協作

目的：測量 CPU 關係評估與 GPU 關係批次計算的拐點，包含 serialization、CPU↔GPU copy、launch、event、等待、資料物化、重試、取消、顯示卡功耗與記憶體峰值；須跟經調校的 CPU-only、CUDA streams、CUDA Graphs／融合 kernel 做等口徑比較。RTX 3070 的實際可用 VRAM、driver、CUDA toolkit、共享顯示負載都應實測，不能僅依型號推斷可重現性能。

5.4 V2｜異質 CPU／平台複驗

若 V1 顯示確有穩定且重要的工作負載收益，才考慮 Intel P/E 混合核心、AMD 多 CCD 或其他記憶體不對稱架構。新硬體購置本身不能當成 SMPDC 性能證據。需要獨立確認性能差異究竟由 CPU 架構、快取大小、DRAM 頻寬、GPU、主機板、編譯器，還是 SMPDC 協議造成。

5.5 V3｜硬體層的額外驗證

V3 可以包含 FPGA、Cycle-Accurate simulator、NoC 原型、可合成 HDL 或專用 ISA proposal，但不是 Paper 11 v0.1 完成的必要條件；若擬宣稱晶片級節省能耗／延遲，須追加面積、頻率、功耗、物理可布線性、設計驗證與保守基線。不能把 x86 虛擬指令的語義直接寫成新 CPU 已有機器碼。

5.6 成熟度與驗證階梯的對應

Paper 00 的 L0–L4 是主張成熟度；本篇 V0–V3 是實驗執行層次，兩個座標系不得混用。例如完成 V0 的程式合約測試可以對部分主張提供 L2 的證據，但不自動構成硬體層 L4；尚未建立 V1 實體 A/B 時，對端到端加速的成熟度仍不足以超越提案／規範階段。

6. SMPDCValidationProtocolV0_1：第一系列統一實驗協議

6.1 Protocol 的輸入與輸出

SMPDCValidationProtocolV0_1 {
  protocol_id, protocol_version, pre_registration_digest
  question_id, claim_ids[], baseline_ids[], candidate_ids[]
  workload_family, workload_manifest_ref, task_quality_contract_ref
  semantics_kind: EquivalentExecution | AlgorithmVariant | ExploratoryPilot
  experiment_tier: V0 | V1_CPU | V1_GPU | V2 | V3
  allowed_hardware[], excluded_hardware[], capability_probe_ref
  input_data_digest, model_digest?, source_commit, build_flags_digest
  seed_policy, precision_policy, fault_model_id
  resource_budget, warmup_policy, measurement_window
  trial_schedule, primary_metric, effect_direction, delta_min
  equivalence_tolerance, correctness_oracle_ref
  clock_calibration, instrumentation_policy
  ablation_plan, adverse_results_reporting_policy
  stop_rule, censoring_policy, statistical_analysis_plan
  planned_artifact_manifest_digest
}

任何主張若無 baseline_ids 或 primary_metric，不可直接獲得 PerformanceValidated=PASS。source_commit 只標記實驗實際程式版本，不能以 Paper 11 自身 Markdown 的 hash 代替。若尚未有實際實作，該欄應為 UNAVAILABLE，而非填入虛構的 commit。

6.2 三類實驗語義

• EquivalentExecution：保持輸入、演算法語義、輸出契約與品質標準；可有合理浮點容差，但須事前聲明。主要回答「執行模型是否改善成本或速度」。
• AlgorithmVariant：允許改變 routing、梯度陳舊性、精度或推論策略等演算法內容；需要同品質與風險條件，且不得將差異全部歸因於 runtime。
• ExploratoryPilot：尋找工作負載可行域與失效點，不做確認性的加速主張；可產生下一版預註冊假說，但不能倒填原始預註冊。

不允許在結果出來後，將原本 EquivalentExecution 的異質加速失敗「改寫」為 AlgorithmVariant 的成功，除非明確發布新版本並保留原結果。

6.3 Resource budget 的不可省略項

每個工作負載至少記錄 CPU physical cores available、logical processors、GPU count、GPU peak allocated and reserved VRAM、system RAM peak、total bytes moved、logical messages、delivery attempts、data duplication factor、CPU host thread time、GPU active time、energy measurement availability、thermal and power limits、wall-clock critical path 及必要的 network I/O。能耗不可測量時須填 UNAVAILABLE；禁止從 TDP 直接推算精確實際能耗。

6.4 停止準則必須在執行前確定

對每次重演，需要指定時間上限、最大 accepted outputs、記憶體界、負載注入次數、故障重試限額、模型訓練步數或驗證集評估上限。結果超時不等於運算數學上不會終止；應按性質區分為 deadline 失敗、右設限、活性前提被違反或未知。

6.5 試驗預註冊鎖定

預註冊文稿不必公開才能進行內部研究，但至少應在首次實際 A/B 前建立不可任意修改的版本雜湊，並把結果與該版本綁定。如果發現記錄錯誤可以更正，但新版本需列出差異及原始 trace，不可覆寫已分析的不利資料。對模型選擇與超參數調優，分開 development、validation 與 held-out evaluation 區域，避免把測試集用成調優資料。

7. CrossPaperContractMatrixV0_1：責任和效果的共同型別

7.1 Contract 表不是自然語言轉接器

各篇契約有自己的主要 owner、版本與用途，Paper 11 的 matrix 只聲明 producer、consumer、擴充方式及拒絕條件：

CrossPaperContractRowV0_1 {
  contract_name, defined_in_paper, canonical_version
  producer_role, consumer_role, stable_identity_fields[]
  authority_scope, required_proofs_or_witnesses[]
  prohibited_implicit_casts[]
  validity_interval_or_epoch, failure_mode
  replay_rule, negative_tests[], test_trace_refs[]
}

若 Paper 06 編譯器把 PDAIS-IR 的一次性權限降成普通布林值，Paper 11 不應只看輸出相同就接受；此類轉換需有型別精化或動態檢查，證明可見的權威及效果語義未被削弱。

7.2 具體 producer／consumer 與故障檢查

7.3 共同 trace 的不可省略資料

每一個跨篇事件至少有 run_id、trace_id、event_type、source_paper_contract、protocol_version、logical_time_or_event_order、clock_domain、flow_id、flow_generation、event_epoch、origin_message_id（若適用）、candidate_key（若適用）、commit_key（若適用）、authority_scope、resource_lease、outcome、failure_code 和 evidence_digest。欄位可以是明確的 NOT_APPLICABLE，不可故意省略表示未知。對 CPU/GPU 的不同時鐘域，因果順序優先於將不同 timestamp 相減的虛構時間差。

7.4 版本相容性規則

定義 source_contract_version、runtime_adapter_version、compiler_ir_version、trace_schema_version 與 analysis_version 五個不同版本。數字恰好同為 0.1 不意味自動相容。每次升版須附：

• 新增、刪除、改名欄位及預設值。
• 既有合法程式是否可能變成非法，或相反。
• 舊 trace 是否仍能被無損解析。
• 靜態效果驗證是否被削弱。
• 窄化權限是否能安全相容；擴大權限是否需要新授權。
• 基線是否需一起重編譯或重測。

7.5 共同拒絕規則

若任何一個守衛的狀態是 UNKNOWN，對安全性敏感的提交應採保守 HOLD 或 REJECT，而不是將三值邏輯的 UNKNOWN 當成真。對只讀無副作用的計算，允許在明確風險預算下維持暫態，且不得把候選輸出計入合法完成數。所有拒絕需要具型別 failure code，不能只輸出「Task Failed」。

8. 主張依賴圖、可證偽單位與最小反例

8.1 非循環的研究主張圖

以研究主張而非 runtime 的任務圖定義：

其中 $C$ 為本系列主要 claim， $\mathcal D$ 為某 claim 的證據依賴，例如 CrossPaperCommitSafe 依賴合法 flow generation、credit/budget admission、候選驗證及提交權威。此圖可以在底層分篇中存在互相引用的設計關係，但證明依賴不得以「A 因 B，B 又因 A」構成無基礎循環。

8.2 最小反例原則

一個反例足以推翻同一作用域及前提下的全稱安全主張；性能問題則常需統計分布、負載域與噪音分析，不能用單一很慢的偶發值推翻所有平均值假說。對結果不利的資料：保存原始 trace、縮小重現條件、標示 fault domain，直到能確認是協議缺陷、實作錯誤、實驗設計偏差或環境限制，不能直接用「目前尚未最佳化」作為不可反駁的理由。

8.3 反例優先序

以下優先級以安全及科學完整性而非文字篇幅排列：

1. 未授權提交、同一受控域雙重衝突決策、外部副作用重複。
2. buffer use-after-free、GPU 資料可見性錯誤、資料競爭、錯誤結果被合法計數。
3. credit 複製、重送增加票數、舊 epoch 再入場、靜止誤判。
4. 模型版本混用、同一梯度重複累加、held-out evaluation 汙染。
5. 負載下死鎖／永久飢餓、不能安全退回成熟基線。
6. 性能及能源退化、成本模型偏差、實驗方法偏差。

第 1–4 類即使只在罕見 trace 發生，也不應因某一平均加速比很好就被忽略。第 6 類需要同時報告負載條件、效果幅度與不確定性。

8.4 Safety 與 Liveness 不合併

NeverUnauthorizedCommit 屬於 safety；EventuallyCompletesUnderFairness 屬於 liveness。前者的反例通常有可追溯壞事件；後者需要完整描述 scheduler fairness、網路可靠性、資源下界、阻塞周期及有限故障假設。在無界延遲、永久故障或必然缺資源場景下，不能要求任何系統無條件活性。

9. Benchmark Suite：面向不同形態的 24 組實驗

9.1 分組規則

整套 suite 不預設所有 workload 都要啟用所有 SMPDC 特性。每組須先記錄 phase_relevance、candidate_parallelism、message_fanout、state_mutability、data_residence、hardware_acceleration_fit 及 required_quality_contract。若某組已可被單一最優 CPU SIMD loop 或高度調校的 GPU kernel 良好解決，SMPDC 的負面結果也是有效證據。

9.2 W11-01～W11-24 工作負載主表

9.3 三個優先落地實驗

先執行 W11-22（持續 verifier）、W11-19（小型動態 MoE）、W11-23（可在現有 GPU 資源內達品質目標的訓練）。研究優先序是因為這三者分別逼迫 SMPDC 接受 authority、CPU-GPU coupling 和 Time-to-Quality 的真正責任，不是因為預設它們最容易跑出漂亮加速比。

9.4 一個不得被隱藏的負對照

W11-24 應在系列最後保留。若一個工作每次只有極少的純量計算，並無多路資訊或持久身分需求，整套 typed phase／credit／reconcile／GPU offload 的附加成本極可能高於收益。在這類負載中，正確的 SMPDC 設計應能選擇不擴散、不走 GPU，甚至完全退回最簡單的串行路徑。 如果連安全退回都做不到，控制層的研究假說即有明確的負面證據。

10. 強基線：不能只與未最佳化串行程式比較

10.1 B11-00～B11-14 的共同對照規格

基線可因平台實際可用性分為 required、applicable、unsupported，不能假裝每個 Windows 環境都能直接安裝完整 Linux stack，或每種 GPU 工作都存在 CUDA Graphs 的相同重播形態。若某個關鍵強基線不可執行，應縮窄可主張的結論，而不是直接宣布新架構勝出。

10.2 一般公平性義務

基線與候選應使用相同輸入、輸出 oracle、同一機器與功耗限制、相同可用 CPU 核心數、同精度、同 model checkpoint、同資料／seed 分割及同合法資源上限。允許各自的最佳合理設定，但要在開發集上調參、固定參數再跑正式集。若候選使用資料常駐 GPU，對照組亦應給予同等常駐機會；若候選有 cache warmup，基線不能刻意 cold start。包含 setup／startup 成本與否，需依服務模式事前固定。

10.3 比較級別

• Level A — Algorithmic: 算法、資料結構及品質契約相同。
• Level B — Systems: 允許不同 runtime、memory placement 和 scheduling，但等價輸出。
• Level C — Quality-Constrained: 訓練／推論策略不同，但同等品質門檻和風險限制。
• Level D — Exploratory: 無足夠等價條件，只能提供工程觀察。

Level D 不能因速度很高就升級為 Level A 的新計算架構勝出。

10.4 避免基線反向污染

若一種基線原本沒有某個安全承諾（例如只提供 at-least-once 處理，不承諾 authoritative commit），不能用 SMPDC 的較昂貴完整提交程序和該基線的無提交數值結果直接宣稱「速度輸了」或「速度贏了」。應建立同功能 baseline（加上所需合法提交服務），並另外報告裸計算路徑和完整功能路徑，使安全功能成本透明可見。

11. 消融：哪些機制真正需要存在？

11.1 A11-00～A11-18 的最低矩陣

11.2 消融必須保持安全契約

如果移除 credit 會造成無界消息生成，A11-05 只能在仍有安全資源上界的成熟隊列對照上執行；不能拿不受控系統崩潰來「證明 credit 有用」。同理，關閉 fencing 會使安全條件失效，只能用 V0 故障注入驗證必要性，不應在正式外部資料或真實提交服務上執行危險對照。

11.3 交互作用而非逐項累加

可存在「相位單獨無收益，搭配動態耦合才有收益」，或「R1 單獨有尾延遲收益，搭配 GPU 批次後取消成本反而增加」。因此除了主效應，至少預註冊三組交互作用：phase × dynamic topology、redundancy × backpressure、CPU–GPU batching × data locality。當資料量不足以估計所有高階交互作用時，應明示僅探索觀察，不宣稱已完整分離因果。

11.4 Minimum-Sufficient SMPDC

真正值得落地的架構可能不是「所有機制永遠開啟」，而是：

條件為該機制子集 $\mathcal K$ 滿足工作負載 $W$ 的正確性、品質、安全及服務等級。不應以這個式子主張其在任意組合空間都可低成本精確求解；實際可採受限候選配置、heuristic 及明確計算預算，並保留與最佳可行基線的差距。

12. 效能、品質、能耗與成本：同一個報告要能分開計分

12.1 端到端總延遲

對同一個具明確輸入與權威輸出的工作片段，令：

此式是非重疊成本分解的觀測口徑，不能將同時進行的 CPU／GPU 活動簡單相加而宣稱為 wall-clock。若異質執行有計算與傳輸重疊，正式報表應同時保留各 stage 實測時間與端到端關鍵路徑，用 trace DAG 計算，並說明哪些成本存在重疊。T_retry 也不一定可與其他階段無重疊相加；實作報告須定義互斥分攤或使用直接 wall-clock 作唯一主要延遲指標。

12.2 安全與品質約束下的可接受加速

固定工作負載與品質合約後，定義成本口徑相同的候選 $E$ 與基線 $B$：

前提是兩邊都通過相同安全／品質／完成條件，且 $T$ 為對應 workload 的合法端到端時間。若 $E$ 在觀察窗內沒有合法完成，不能只取它最後一個局部 kernel 的耗時當分母。候選加速若伴隨 RAM／VRAM／能源超限，依事前 budget 可判為資源失敗，而非自由地以 speedup 補償。

12.3 有效完成吞吐量 Goodput

分子不包含被去重的重送、暫態候選、沒有授權的提交、版本錯誤的 GPU 結果、驗證失敗的回答。若工作類型沒有 deadline，ontime 應採事先定義的服務時間窗口；不得在觀察後隨意加寬 deadline 以提高好看比率。對有多個 tenant 的系統應記錄 per-tenant goodput，避免犧牲小租戶來改善整體總量。

12.4 尾端延遲與 deadline

平均值不能取代 p95/p99。對 1000 次以下的尾端樣本，應特別注意 p99 估計的統計不穩定；不能把 10 次 run 中的第 10 高值直接當成可靠的第 99 百分位分布。對排隊、GPU batch、模型 prefill/decode、R1 hedging 和 speculative retry，至少報告延遲分布、失敗率、逾期比例及並發量。隨 request arrival process 改變，p99 與吞吐可能同時改變，須固定負載生成契約 [E2]。

12.5 AI 訓練的 Time-to-Quality

設品質評估函數為 $Q(\theta_t;D_{heldout})$，門檻 $q^{\star}$ 與方向 $\succeq$ 由預註冊指定：

若觀察窗內未達標，結果須保留為設限或品質失敗（依事先規則），不能用 step/sec 高低排名。實際要以帶時間戳的模型 checkpoint、eval artifact、資料與 evaluator digest 確認首次達標；評估耗時是否計入 clock，應遵循事先定義的測試規則，MLPerf Training 對此有明確制度先例 [E1]。若兩系統的演算法已改變，則需標為 AlgorithmVariant，不可推論 SMPDC runtime 本身造成訓練品質改善。

12.6 能耗、記憶體、額外流量

在量測電力積分可靠時：

能耗包括定義好的系統邊界（CPU package、GPU board、wall plug 等）；不同邊界不可直接對比。每個 accepted output 的能源應為總能源除以合法完成量，而不是除以候選產生量。冗餘路徑應同時呈報 logical bytes、physical transmitted bytes、retry bytes、encoding overhead bytes、peak live copies，以檢測 RAM/VRAM 放大。

12.7 Pareto 而非單一數值崇拜

給每個合法方案成本向量：

正負方向須先統一；在有安全硬約束及品質硬約束下，比較非支配集合。若某方案 p95 改善而 p99 顯著惡化，不能只引述最有利的維度。採納決策可以有偏好權重，但學術報告需要保留完整原始成本向量與適用域。

12.8 對「看似更準」的嚴格解讀

R1 只可能改善某些可靠完成時間，R2 可以增加衝突可觀測性，R3 僅在明確編碼與故障假設下提供恢復能力。重複收到兩份相同 bit pattern 不會自行證明資料「真」，更不會保證 LLM 答案的語義正確。若要主張可靠度提升，需指定故障分布、相關性、test oracle 與真值來源；不應以「兩份相似」代替獨立驗證。

13. 實驗設計：配對、隨機化、統計不確定性與反證

13.1 研究單位要先選對

單次 request 不一定是獨立抽樣：同一個 run 中有共同 GPU 時脈、OS 干擾、熱狀態、模型狀態與相同 seed，彼此可能高度相關。因此須分別定義 request sample、run、hardware session、model training seed、machine 五種試驗層次。不可把同一張 GPU 上一百萬個 token 當作一百萬個獨立硬體實驗。

13.2 配對與交錯試驗

建議在同一硬體 session 內採 ABBA 或隨機交錯 A/B 方案，配對相同資料或 arrival trace，但應避免依序執行全部 baseline 後再執行 candidate 所導致的溫度、OS 更新或電源狀態混淆。對可能有交叉汙染的工作（checkpoint、KV、disk cache）須在配對前重置，或把必要暖機與 carryover 納入模型。

13.3 預先指定 Primary Endpoint

每個 workload 最多一個主要效能終點與一個主要安全／品質判準；其他指標可列 secondary 或 exploratory。若測二十個 workload、十五個 baseline 和十九個 ablation，必須處理多重比較或控制可確認性主張的數量，不能從大量測試裡隨便挑一個最亮眼的結果宣稱整體勝出。

13.4 效果大小與不確定性

對配對 run 的 log ratio 定義：

正值代表候選時間較短。可報告配對的中心趨勢、預先選定的區間估計（例如在適用的獨立 run 層做 bootstrap）及效果大小。若資料含大量設限、零延遲或多模態分布，不應機械套用 log ratio；需採預先規定的生存／負載／分位數統計方法。時間比率只是其中一種量化方式，不能單靠信賴區間取代原始資料。

13.5 範例候選採納門檻（僅提案，非實測）

可以在第一次 V1 前預註冊，例如：主要合法完成時間改善至少 10%，候選與基線品質等價，p99 未越過預設惡化界，RAM／VRAM 不超限，且完整成本比較的效果估計不被主要量測不確定性覆蓋。這些數值是待選的工程門檻，不是此時的已確認性能或科學定律。不同工作負載的實用門檻應有明確理由，不需要被強行套成同一百分比。

13.6 充分性與功效分析

樣本數不宜用「固定跑 3 次」替代。首輪 pilot 可估計變異、熱漂移與效應幅度，再用獨立鎖定的正式規劃選定確認性 trial count；pilot 與正式試驗分離。對 p99、稀有故障率和小幅效能差，需要比平均吞吐更大的有效樣本。若達不到事前規劃的測試量，標 INCONCLUSIVE，不得用大聲描述彌補統計能力不足。

13.7 設限與失敗樣本的資訊

訓練在 budget 內未達品質目標是重要訊號，並非自然可刪除的異常值。對服務驗證超時亦然。報告應保留未完成 run、OOM、driver reset、deadline miss、invalid output、checkpoint corruption 及 retries；所有 failures 都應進分母，除非符合事前明確排除規則。排除 OS 背景更新等干擾，應保留操作日志與理由。

13.8 重複測量的版本穩定性

不同日期的性能比較需記錄 BIOS／UEFI、microcode、GPU driver、CUDA toolkit、compiler、OS scheduler、更新程序、能源設定與常駐背景負載。若這些因素改變，不能只以「同一款 CPU」宣稱配對條件已滿足。跨機型只適合對不同硬體下的模型有效域作複驗，不可將所有變因視為控制完成。

14. 量測基礎設施、時鐘域與歸因

14.1 三種時鐘與事件座標

需區分 host monotonic time、device event time、logical causal sequence。CUDA events 在指定 stream 中量測執行階段具有實用價值，但與 host wall-clock 的直接相減必須先處理不同 clock domain 及 API 非同步性；NVIDIA 官方說明已提醒 async API 的 host 計時陷阱 [E3]。在多 GPU／不同 CPU 時鐘域，沒有校準的負時間差應報告為不合法測量，而非宣稱發現超光速或零延遲通道。

14.2 CPU 指標

可使用 OS 提供的 high-resolution monotonic clock、Windows Performance Recorder／ETW 或 Linux perf stat／perf record（若有權限且硬體支援）；需要時才加入 Intel VTune 或其他分析器。紀錄 cycles、instructions、cache misses、context switches、CPU migrations、run queue、memory bandwidth（若可用）與 observed affinity。PMU 事件在不同架構下可能不可直接比較，不可無來源地把兩個 CPU 的原始 counter 值當成同單位物理量 [E5][E6]。

14.3 GPU 指標

需保留 cudaLaunch 呼叫期間、CPU submit 到 GPU start 的間隔、kernel run、copy H2D/D2H、stream wait、event dependencies、device synchronization、pinned memory、VRAM peak 與 GPU utilization。若 profiler 本身改變系統性能，實驗應將instrumented diagnostic runs 和 uninstrumented timing runs 分開。NVIDIA Nsight Systems 可提供 CUDA API、kernel 與 copy timeline，不能直接取一個 kernel box 的長度冒充整個服務 latency [E4]。

14.4 儀器成本與資料保留

記錄 instrumentation overhead：trace_off、light_trace、full_trace 三組，若全量 trace 導致記憶體或磁碟成為瓶頸，應在正式性能 run 使用低干擾版本，並在獨立 validation run 提供完整性證據。不能為了性能關閉所有版本／權威檢查，讓測到的其實不是 SMPDC 合法實作。

14.5 系統層級變異

現有桌機同時負責螢幕顯示時，GPU 呈現與 OS 系統事件可能干擾計量；建議記錄顯示器、視窗、背景應用、電力供應模式、GPU driver 使用狀態及實驗期間的 throttling。即使同一張 GPU，對 1ms 以內的 kernel，測量與排程噪音的量級也可能不可忽略，須分開觀察與解釋。

14.6 熱與長時間執行

高負載長時間試驗可能觸發 CPU／GPU 降頻，造成時間序列漂移。正式 run 要記錄溫度、功率限制、頻率與熱狀態；必要時交錯不同候選並設冷卻間隔。若散熱不足只能測得短時間 burst 性能，應限定研究範圍，不要從 burst 結果推論 24 小時持續訓練效能。

14.7 Evidence-grade 分類

• EG0：口頭或文字構想。
• EG1：具名的可解析規格／模型。
• EG2：可執行 mock／有限模型／工具級結果。
• EG3：實際單機端到端 trace、正確性與資源量測。
• EG4：跨平台、跨次數、強基線和獨立複驗。
• EG5：硬體級專用實作及第三方可追溯測量。

這是本文的研究管理建議，非任何國際標準認證。每一條 claim 應標註其最高獲得的 evidence grade，不能把整篇單一引用跳轉成 EG4。

15. 形式安全性：必要前提、可檢查不變量與 liveness

15.1 何者可由 V0 驗證

V0 適合探索 bounded model 中所有有限轉移、線性資源重複使用、舊權威世代、重送次數、權威提交與裝置可見性錯誤。然而 V0 的結果依賴 max flows、max messages、max retries、max epochs、max resource generations 與故障範圍；必須隨證據提交這些上界。對需要證明任意 $n$ 節點的性質，必須提供具前提的數學證明或 parameterized verification，不能由 3 節點模擬器直接推廣。

15.2 三個不同的形式檢查任務

• Invariant Checking：任何合法 reachable state 都不得違反指定 safety predicate。
• Refinement Checking：實作 trace 投影到抽象機器後符合其允許的事件／輸出語義；須明確處理 stuttering 與隱藏事件。
• Progress Checking：在指定 fairness 和故障假設下某些進度終能發生；未滿足前提不代表架構違反設計。

可採 TLA+／TLC 作為候選工具，TLC 支援有界安全與活性檢查；此處只有工具路線，本篇沒有聲稱已完成任何 TLC model checking [E7]。

15.3 資源與權威的局部安全命題

命題 V11-P1（舊權威不能提交）。 假設同一提交域之 fencing_token 由唯一具權威的 generation service 單調核發，所有正式提交操作在原子決策點比較 token，且沒有繞過檢查的寫入路徑。則使用低於當前有效世代 token 的舊 worker，無法經合法轉移提交該域的受控狀態。反例為外部寫入 API 未強制 token、持久化前就把外部效果送出或 token 發放者分叉。

命題 V11-P2（有界發送，非有界計算）。 假設同一 epoch 可用 credit 有有限上界、傳送需線性消耗 credit、重試不鑄造新 credit 且無繞過通道。則該 epoch 的受控邏輯新發送數受初始授權總數所界定。這不證明每段 payload 的計算必然終止，也不證明物理 retries、IO 次數或總耗能有相同上界。

命題 V11-P3（局部去重，非真值判決）。 假設重送保留同一 logical message identity，接收端在產生受控效果前以持久 seen-set 檢查，且去重集合保留期限覆蓋合法重試期間。則同一 logical message 的重送不可增加該作用域的 accepted effect 計數。若相異 lineage 的候選都錯，此命題不賦予語義正確性。

命題 V11-P4（GPU 可見性守衛）。 假設所有必要 device dependencies 有證據、資料 buffer lease 有效、host import 必須持有經可信同步生成的 HostReadable witness。則合法 trace 不可在該 witness 前成功 host import。此為協議規則；平台如果遭到不受控的 raw pointer 存取，前提失效。

命題 V11-P5（局部提交鍵的冪等）。 假設同一 commit 域的 commit_key 判決記錄為原子、持久且不允許同鍵不同 payload，則對同一鍵的合法重送最多產生一次新決策。此處只談受控域，不對任意不提供冪等協議的第三方 API 保證外部效果 exactly-once。

15.4 安全命題不是實際延遲命題

上述五個命題不推出「系統一定更快」。相反地，fencing、seen-set、event wait 和持久化日志都具有成本。正確性和性能必須分兩組實驗，先建立可接受的等安全基線，再測量協議是否值得。

15.5 活性候選命題

命題 V11-P6（條件性前進）。 假設每個合法 ready work slice 都獲得公平調度機會、依賴最終可滿足、背壓路徑不存在永久循環等待、必要資源不永久被撤銷、外部服務回覆或逾時可解析，則持續 PWN 的每一個適格工作片段能在有限步走向成功、受控取消或具型別拒絕。這是需進一步形式化的候選命題；它不聲稱無限制無故障保證。

命題 V11-P7（epoch 靜止）。 若 epoch 已關閉新任務生成，所有在途責任可由分散 ledger 可靠追蹤，所有任務、消息與設備事件均已達終止或明確轉移到其他受控 epoch，則可以在某個全域可確認的切面判定該 epoch 靜止。單獨觀察一個 core queue 為空不是足夠條件。

16. C11 四十八條跨篇最低驗證不變量

16.1 驗證方法與責任歸屬

以下每條用 C11-xx 穩定編號。最低可接受欄位為 contract_ref、check_level、positive_trace、negative_trace、evidence_digest 與 verdict；未實作的項目只能填 UNAVAILABLE。所列不變量是應實作並驗證的規格，不代表本篇已對 48 條進行真實系統整合測試。

16.2 A 組：PWN 身分、相位與有界擴散

16.3 B 組：訊息、冗餘與局部聚合

16.4 C 組：推測、提交與外部效果

16.5 D 組：指令、語言、OS／AI Control

16.6 E 組：GPU、記憶體與局部性

16.7 F 組：AI 品質、科學方法及發布

16.8 Cross-paper acceptance 的最低覆蓋

第一輪研究可把上述每條對應到單一最小正反測試，產出 C11-index.json。但正式宣稱「Cross-Paper Safety PASS」需要的不是 48 條字面規格全寫完，而是：

1. 每條可適用不變量都有實際執行證據或已審查的形式證明。
2. 至少有一條跨 3 篇以上契約的完整端到端 trace。
3. 所有安全關鍵故障具 negative test；只靠 happy path 不足。
4. 不存在未被解釋或已知可重現的安全違反。
5. 對 UNAVAILABLE 的項目不納入成功計數，也不宣稱全涵蓋。

本篇附錄的 Python mock 僅示範若干契約的局部行為，不涵蓋以上五項完整條件。

17. F11 四十八組故障注入與負面研究案例

17.1 故障注入不是把系統故意弄壞就算測試

每個 fault record 至少具有 fault_id、precondition、injection_point、expected_safe_outcome、actual_outcome、oracle、artifact_refs 及 severity。若注入的故障超出宣告範圍，結果可作 exploratory，但不能因此說協議承諾遭推翻；相反地，若同作用域內的故障使禁止事件可達，就必須保留 FAIL。

17.2 A 組：身分、擴散、終止

17.3 B 組：冗餘、來源與聚合

17.4 C 組：推測、權威、外部效果

17.5 D 組：語言、編譯、排程

17.6 E 組：GPU、記憶體、時鐘與硬體

17.7 F 組：AI、實驗方法與研究誠信

17.8 故障注入的限制

不是所有 fault 都適合在實體機上以侵入式方式注入，例如對正式資料庫做未授權寫入、對生產服務設計使用後釋放、或讓作業系統核心崩潰。優先在隔離 VM、測試資料、模擬器和不會影響第三方的沙盒中重演。對真正需要實機故障注入的場景，應有環境回復、資源限制、觀測和安全停止計畫。

18. 其餘跨篇條件性命題與真正的效能假說

18.1 V11-P8｜同等品質下的必要性能門檻

假設同一 workload 的基線 $B$ 和候選 $E$ 維持相同輸入、品質、安全、有效成本邊界及已凍結的調參政策。如果經配對測量及預先指定統計規則，可確認 $T_E<T_B$ 且滿足實質門檻，則僅在此 workload domain 可以稱候選獲得端到端淨加速。這是一條採納判準，不是保證 SMPDC 一定滿足的不等式。若完全未測試，verdict 為 UNAVAILABLE。

18.2 V11-P9｜冗餘的尾延遲收益不保證單調

在相互獨立且資源競爭可忽略的理想條件下，兩路競速的最小完成時間可具有改善尾延遲的可能。然而若兩路共享 CPU、L3、記憶體頻寬或 GPU，則延遲分布可能因資源爭奪與 queueing 出現反轉。因此 R1 的效能效果必須以完整系統壓力與實際相關性測試，不能只使用兩個獨立隨機變數的理想公式。

18.3 V11-P10｜無 AI 控制層的存在性是必要而非充分條件

若 SMPDC 的正確執行完全依賴線上 LLM，則「無 AI 時仍能運行的 OS 智能控制」原始設計要求失效。因此至少一套無 AI 基礎控制策略應可獨立通過 safety 和基本 liveness 測試。但即使 AI-free core 通過，也不代表 AI planner 添加後能改善效能；它可能造成更長規劃時間或不穩定 placement。

18.4 V11-P11｜跨平台複驗的必要因果限制

若不同 CPU 平台上 SMPDC 的觀測效果不同，不能直接將差異全歸因於「異質性」。需固定或建模 cache／DRAM／NUMA／GPU／編譯器／OS 等差異，並進行 within-platform A/B，再對跨平台效果做交互項分析。即使觀察到 Intel P/E 優於 AMD 雙 CCD，也只屬特定測試配置的結果，不是產品總排名。

18.5 V11-P12｜負結果閉包

若一個適用域在可接受品質、安全和預先聲明資源界內，經強基線比較與足夠統計測試仍未達實質門檻，則該 workload claim 可以以 FAIL 或「未證實正收益」正式封閉，而不要求研究者再購買更高階 CPU 才能承認。若另一平台將來提供新證據，應建立新的 platform-specific claim，不得抹消先前負結果。

18.6 全系列不能形成的錯誤定理

本系列無法由單一理論公理推出：所有 CPU 核心在持續自治狀態都比分工序列更快；所有 GPU offload 都有效；冗餘越高越正確；所有 AI 訓練更早收斂；所有硬體拓撲都適合環形／群星式映射；未來更高階 CPU 會自動實現新 ISA。這些不是尚待完成的「漏證明步驟」，而是目前不具普遍有效前提、甚至很容易構造反例的過強主張。

19. AI 專用驗證：版本、品質、梯度、KV 與工具權威

19.1 AIWorkloadValidity 不可被一般 Benchmark 統計取代

AI 模型的正確性至少具有兩個不同層次：其一是執行契約的正確性（例如每份梯度只更新一次、KV 與模型版本吻合）；其二是模型輸出的品質（例如 held-out 準確度、推論任務合法完成率、生成答案的外部驗證）。前者 PASS 不推論後者 PASS，後者 PASS 也不能抵銷未授權副作用。對於不可嚴格比對的語義輸出，必須明確指定 evaluator、抽樣方法、置信區間或外部 proof obligation。

19.2 對 MoE 的固定條件

要求記錄 router_version、expert_count、top_k、capacity_factor、expert placement、routing histogram、dropped token count、precision、batch distribution、GPU time 與 CPU orchestration time。若 SMPDC 使用不同 expert activation 或選擇策略，應標 AlgorithmVariant，以免把模型路由改善誤認為 OS/Runtime 的優勢。若同一 MoE 算法，則量測 gating 和 dispatch 是否真的減少排隊、資料搬移或 CPU launch overhead。

19.3 對 LLM Serving 的固定條件

至少固定 model weights digest、tokenizer、prompt length distribution、output length、sampling policy、request arrival、batching、KV cache policy、precision 和 max concurrency。同時報告 TTFT、TPOT、goodput、拒絕率、逾期率、VRAM 峰值和 CPU utilization。不能只用 tokens/s 比較具有不同 context length 或不同可接受品質的系統。若借用 MLPerf Inference LoadGen 等規範，應遵守其相關使用與發表限制，不能以自訂小型測試冒用正式 MLPerf 分數 [E2]。

19.4 對訓練的最低血緣追蹤

run_id → model checkpoint digest → data split digest → microbatch id → forward weight version → backward weight version → logical gradient identity → optimizer step key → new model version → evaluation checkpoint。其中任何缺口都可能使「模型訓練更快」失去相同任務的可比性。增加 parallel branch 導致梯度放大時，如果演算法本意是平均而實際被雙加，則不屬等價 runtime 優化。

19.5 對持續 Agent 的合法完成

不以 Agent 創建了多少內部 thought、tool call 或候選作為主要效能指標。應追蹤 authorization boundary、tool effect policy、dedup key、human confirmation where required、external API semantics 和 result witness。例如多個 PWN 並行生成同一個外部寄送動作，必須以一次正式授權的效果計數，而不是把兩次寄出誤當更高吞吐。

19.6 三個最重要的 AI 負例

負例一： GPU 批次更快，但 TTFT 變長、p99 timeout 增多；全端好處不成立。

負例二： optimizer step/sec 提升，但模型在預先規定的最大時間或步數內未達標；Time-to-Quality 無證據改善。

負例三： R2 兩個 verifier 以相同錯誤前提產生一致答案；一致性不是答案真實性的新證明。

這三類應與正例等量保留，避免 AI 工作負載成為性能敘事的單向佐證。

20. ReproductionManifestV0_1：讓實驗可由第三方重新建立

20.1 最低 manifest 四層

1. Study Manifest： claim、problem、baseline、prereg、主要及次要 endpoints、假設、決策門檻、失敗和 censoring 規則。
2. Environment Manifest： 完整 CPU、GPU、RAM、BIOS、OS、driver、compiler、runtime、container 或 venv、power/thermal、affinity、NUMA、GPU display 等。
3. Run Manifest： 指定 seed、資料、模型、權重、source、build flags、warmup、試驗順序、負載、incident 與注入故障。
4. Evidence Manifest： raw traces、stdout/stderr、checksums、quality witnesses、OS counters、GPU timeline、分析腳本及最終判決。

前四篇將 epoch、flow generation、candidate lineage 和 commit key 寫進執行安全，本篇則把相同嚴謹度擴張到實驗本身的資料血緣。

20.2 RunEvidenceBundleV0_1

RunEvidenceBundleV0_1 {
  study_id, run_id, experiment_tier, claim_scope[], trial_index
  source_commit, build_digest, environment_digest
  dataset_digest, model_digest?, seed, warmup_trace_ref
  raw_event_trace_ref, resource_trace_ref, quality_witness_ref?
  device_timeline_ref?, OS_counters_ref?, energy_trace_ref?
  output_or_effect_receipts[], raw_log_digest, failure_refs[]
  analysis_script_digest, analyzer_version, analysis_result_digest
  provenance_signature_or_equivalent_integrity_ref?
  information_not_available[], exclusion_reason?, retention_policy
}

這個 bundle 不要求所有原始敏感資料都公開；可提供可重現的去識別輸入、合法合成資料、證據摘要與權限受控的複驗安排。但如果關鍵資料完全無法第三方取得或重新生成，應限定重現性主張，不得假稱外部可完全複驗。

20.3 雜湊與來源完整性

SHA-256 等雜湊可用於檔案一致性識別；不等於來源真實性或實驗正確性證明。若要防止惡意篡改與證據替換，需要對來源授權、簽署或可信儲存另行建模。對含模型權重的資料，還要注意權重格式、數值精度、序列化順序、框架版本改變引發的 digest 差異。

20.4 若某功能沒有提供應如何標示

• 沒有真實 CUDA：experiment_tier=V1_GPU, verdict=UNAVAILABLE, reason="no supported device/runtime"。
• 沒有精確電錶：性能可測，energy_verdict=UNAVAILABLE，不可用 TDP 補造。
• 沒有可用 held-out dataset：AI 品質驗證不可宣稱 PASS，最多保留 engineering smoke test。
• 沒有強基線安裝環境：限縮 comparator set 和主張，不得視為自動贏過那套基線。
• 同一 repo 的 Python mock 通過：只標 V0-Mock，不可提升至 V1-AITraining。

21. FalsificationVerdictV0_1：正式判決與採納限制

21.1 每個 claim 必須有自己的 verdict

FalsificationVerdictV0_1 {
  claim_id, experiment_scope, preregistration_digest
  evidence_tier, evidence_grade, statement_kind
  baseline_id?, candidate_id?, workload_manifest_digest
  safety_status, quality_status, performance_status
  resource_status, reproduction_status
  effect_size?, uncertainty_interval?, practical_delta?
  primary_verdict: PASS | FAIL | INCONCLUSIVE | UNAVAILABLE
  observed_counterexamples[], unsupported_premises[]
  data_integrity_check, independent_review_status
  claims_allowed[], claims_prohibited[]
  next_action: Adopt | LimitScope | Rework | Defer | Reject | Archive
}

單一「系列 PASS」是錯誤展示方式。若驗證某個 typed message contract 成功但性能尚未執行，應留下例如 safety=PASS; performance=UNAVAILABLE 的向量判決。主判決只是對預先註冊的某項具體 claim作聚合，而非宣告整個計算架構已證實。

21.2 預期情境與合法結論

21.3 Claim 失敗時不是全部研究一同消失

若 R1 在高負載下證實沒有益處，可局部關閉 R1，繼續測試長壽 PWN 的其它負載；若 GPU offload 在本機過慢，可仍研究 CPU-only phase diffusion；若 AI planner 不穩定，可採 OS-only policy。局部反證可縮窄有效域，而不是強迫兩極化地宣布「整個理論全真」或「全部無用」。 但若 UnconditionalSafeCommit 這類跨多篇核心安全性主張遭推翻，相關下游性能結果也應暫停正式採納，直到安全基線修復且重新測試。

21.4 研究結果不能由主觀審美裁決

「群星圖更像生物腦」「相位語言更優美」「邏輯閉環看起來完整」可以說明設計動機，不足以用於性能、正確性或能耗的 verdict。正式採納應依其對應 workload 的已知代價與可重演證據。此要求也能保護研究免於反過來受命名與比喻所拘束。

22. 從結果到工程路線：何時不該買新 CPU？

22.1 三階段研究投資決策

第一階段： 使用現有舊款 AMD CPU／RTX 3070／32 GB RAM，完成 V0 和 V1 的最小工作。工作重點是證明協議可以不靠昂貴硬體實際執行、定位成本與負面案例。

第二階段： 若 V1 有明確 workload 取得正收益，且瓶頸確實指向核心異質性／快取域或更高平行度，再考慮 Intel P/E 混合核心或 AMD CCD／3D V-Cache 平台。前提是實際 hardware topology 具有能驗證新假說的差異，而不是為了新品或跑分購入。

第三階段： 只有在強軟體最佳化、現有 CPU/GPU 能力和不同硬體架構都無法消除某項明確實測瓶頸時，才提出特定硬體 ISA／NoC／accelerator 設計；並有能估算實體 PPA 與驗證成本的研究計畫。

22.2 立即停止投入更昂貴硬體的條件

• 核心協議仍有可重現的安全違反。
• 主要工作負載缺少可重現的端到端 baseline。
• 工作負載真正的計算時間短於編排／序列化／同步成本且無法以批次化消除。
• 在相同品質／資源下，多主 PWN 反覆不如成熟 thread pool 或 local actor model。
• GPU 子任務依賴大量短而頻繁的 host/device transfers。
• R1 的重複成本顯著高於尾延遲收益。
• AI planner 的建議造成更高成本或不穩定，且規則排程已能滿足需求。

停止不是宣告所有潛在方向無效，而是在當前證據下阻止沉沒成本擴張。

22.3 什麼情況可以支持購買新 CPU？

若現有 CPU 核心／快取拓撲不足以識別「異質核心 vs 記憶體快取不對稱」的因果差異，且已在現有平台得到可重演的 candidate-positive 或具有明確機制的 negative result，可將額外平台作為新自變項。購買前須先寫研究預註冊，說明 P/E、CCD、NUMA、cache、SMT、GPU 相容性與 DRAM 造成的可區分假說；購買本身仍不等於結論。

23. 透明度、權利與責任的研究邊界

23.1 科學透明度不等於洩漏內部資料

完整方法可以公開，而私人 API key、測試者個資、未公開模型權重、合作方機密及授權受限資料不必公開。可以提供可重現的 synthetic inputs、敏感資料剝離的 trace、來源權限說明與證據雜湊。若結果只在不可共享的私人資料上成立，必須將證據可複驗程度明確降級，不能宣稱完全獨立可再現。

23.2 正確使用第三方研究與商標

引用 MLPerf 規則可以使自己的公平性與品質判準更嚴格，但若沒有遵循其 suite、提交、審核和發布要求，不應將自家 SMPDC 實驗稱為 MLPerf 官方結果。引用某開源 runtime 不代表該維護團隊支持 SMPDC；使用其原始碼還需遵守其授權條款。

23.3 反例權利

正式論文應允許第三方回報新的反例、指出自家 benchmark 優化不足、提出更強基線或修正適用域。更正原始論文的方式是 versioned errata，非默默替換先前數據。作者應保有理論立場可修正的權利，且讀者具有根據可再現證據否定某個 claim 的學術權利。

24. 第一系列跨篇結案清單與後續工程 handoff

24.1 目前已完成與尚未完成的層級（截至本稿）

如果後續執行了附錄 mock，應在驗證附記中標明實際 assert 次數、Python 版本與測試結果；不得回頭把表格其餘 UNAVAILABLE 自動改為 PASS。

24.2 給本地工程團隊的最小實作次序

1. 建立 contracts/：將 Paper 01–10 明確的 JSON／typed schema 與 invariants 編成機器可讀版本。
2. 建立 model-check/：有限狀態機、credit 使用、epoch close、commit fencing、device visibility、gradient identity。
3. 建立 runtime-v0/：以 CPU-only 運行 PWN／phase／bounded diffusion／R0／commit，先不接 GPU。
4. 建立 runtime-v1/：加入選擇性 R1/R2、rollback、OS policy、manifest 與 trace，不引入 AI planner。
5. 建立 gpu-adapter/：按 Paper 08 記錄 host/device dependencies、buffer lease、queue、CUDA streams／events。
6. 建立 ai-workloads/：依 W11-22、W11-19、W11-23 次序導入合法工作負載，並保留 R0／CPU-only baseline。
7. 建立 analysis/：固定資料流程、配對統計、性能和品質 witness，讓每一項結果能由 raw artifact 生成。
8. 建立 ci/：格式、型別、故障測試、mock、真實 CPU benchmark、可用時 GPU benchmark、結果驗證。

上述資料夾僅是建議工程拓撲，本稿沒有建立這些程式倉庫、分支或測試輸出。

24.3 第一輪 MVP 必須切得更小

推薦最小功能為：2–4 個 PWN、每個獨立邏輯 generation；一個 bounded epoch；R0 + 可選 R1；一個受控結果域；無外部效果或只使用測試 outbox；CPU-only、OS-only 調度。這個 MVP 就能對「多主工作流是否有安全且有成本上界的長期執行意義」產生可測資料。若其 overhead 過大，可以在引入 GPU／AI／新語言前及早定位。

25. SeriesClosureDecisionV0_1：第一系列到底怎麼結案

25.1 不把所有事包成一個「完成」

SeriesClosureDecisionV0_1 {
  series_id: "SMPDC", series_range: "00-11"
  document_source_status
  cross_paper_contract_status
  mock_contract_validation_status
  formal_model_check_status
  executable_compiler_status
  executable_runtime_status
  real_CPU_benchmark_status
  real_GPU_benchmark_status
  AI_quality_validation_status
  cross_platform_replication_status
  hardware_implementation_status
  unresolved_counterexamples[], known_negative_results[]
  limitations[], evidence_index_ref
  closure_kind: ResearchProtocolClosure | FormalSystemClosure |
                SoftwareValidationClosure | EmpiricalDomainClosure |
                HardwareValidationClosure
  admitted_claims[], forbidden_claims[], future_work_refs[]
}

25.2 本稿應採用的結案類型

ResearchProtocolClosure（第一系列形式研究及可證偽規劃結案）。

其意義是 Paper 00–11 以九元中觀模型、持續 PWN、typed bounded diffusion、typed redundancy、authoritative commit、PDAIS 指令／語言、OS/AI 控制、CPU/GPU 映射、AI 品質及完整反證計畫建立了第一輪完整研究路線。它不授予其他 ...Closure 的保證。後續若完成 V0 有界模型與 V1 實測，可以再發布 Validation Report v0.2 或獨立工程報告，不必為了讓第一系列看起來完整而杜撰已完成的工程。

25.3 結案不是把未來全部控制起來

研究系列可以完成，而理論、程式語言或硬體不必因此被封成永遠不變的最終版本。此系列給出的是可檢查的起點，讓後續工程與研究者有權依負面實驗修正甚至淘汰局部假設。若 SMPDC 最後只在少數 verifier／Agent 類負載有價值，也足以成為一個可清楚描述、可重現的技術結果，而不必冒充普遍的 CPU 取代架構。

26. 結論：完成可反駁性，才有資格討論下一個處理器

SMPDC 的起點是把每個 CPU 大核／小核視為可能承載一個主要且持續性的工作流的物理資源，再以中宏觀「群星」描述其局部自治、動態邊、相位呼叫、冗餘資訊傳遞、主節點合併及 GPU 並行協作。第一系列從這個設想發展到形式模型、資訊協議、指令集、程式語言、OS/AI 控制、硬體局部性與 AI 工作負載適用域。它的真正價值尚非某個尚不存在的加速數字，而在於已經清楚指出哪些變數能改變、哪些安全邊界不可越過、哪些實體硬體成本不能忽略，以及何種結果足以反對自己最初的直覺。

本篇最後固定七項研究結論：

1. 多主工作流首先是邏輯自治與持續責任，不是每顆實體核心永遠獨占所有資源。
2. 相位擴散是有條件、有界且可追蹤的互動，不是無限制訊息廣播或神秘的高頻同步。
3. 冗餘提高可靠度或尾延遲的效果取決於冗餘型別、獨立性、資源競爭及有效驗證，不能把兩份同樣的資料當作兩個獨立真值證明。
4. GPU 可以加速某些批次關係計算，不代表它能繞過 CPU 快取、DRAM、PCIe、device/host synchronization 及權威提交。
5. 新指令集和程式語言首先是可執行的抽象／IR 語義，不能因此宣稱已有新實體 ISA。
6. AI 的效能應由等品質、等資源條件下合法完成的端到端結果判定；訓練必須包含 Time-to-Quality。
7. 第一系列的完成，是研究規範與可證偽方案完成；是否在實機上勝過現有技術，必須由後續公開、可重演、容許負結果的實驗決定。

因此，正式研究結案的最合理口徑不是「我們已重新發明比 GPU/CPU 更強的計算機」，而是：

我們已為一個具體的多主節點持續擴散計算候選架構，建立了型別、相位、信用、冗餘、權威、硬體、品質及實驗責任的整體研究閉環。接下來應讓實際 CPU／GPU 程式與成熟強基線決定其有效適用域；如果效果不足，收縮或放棄某些部分也是合法且應被完整報告的結果。

第一系列 Paper 00–11：ResearchProtocolClosure v0.1。

附錄 A｜從多主工作流到研究判決的逐事件完整示例

A.1 範例用途與限制

以下是手工構造、可在有限模型中重演的示意場景，不是已由現有桌機實測的速度或可靠度。示例選用兩個 PWN 和一條可選 GPU 批次路徑，避免以龐大的未實作拓撲遮蓋基本安全責任。合法結果應是可由測試 oracle 檢驗的 result_digest=D42，而非只根據訊息先後猜測答案。

A.2 初始化與研究規格

run_id            = illustrative-run-A
workload          = W11-22 restricted verifier branch
flows             = PWN-A(gen=5), PWN-B(gen=9)
epoch             = E7, initial credits = {C1,C2,C3}
message_id        = M1; candidate_key = CAND-X
redundancy_mode   = R1 (two delivery/compute candidates)
commit_domain     = test-results
commit_key        = TEST-K42
commit_generation = G4, base_version = V12
GPU path          = optional and not required for correctness
quality           = witness signed by configured test verifier

R1 中兩條結果如果來自同一模型版本或同一來源計算，允許在速度策略上競速，不能被計為 R2 的獨立正確性證據；當路徑恰好使用 GPU 時，還必須增加 device visibility witness。

A.3 正確路徑

示例清楚顯示：GPU kernelDone 與 HostReadable 中間是技術邊界，LocalReconciliationOutcome 與 DurableCommitted 之間是權威邊界。若省略其中一道，整個追蹤不合法，而不能因最後 digest 碰巧相同就認為安全。

A.4 三個反例

反例 A—舊 generation： 在事件 10 前 PWN-A 已遷移至新的 generation 6，但其舊實例仍持有 generation 5 的提案。合法 authority 需拒絕或要求新 generation 重新授權，不得因 commit_key 之前未出現就直接接受。

反例 B—R1 先到但無證據： Branch B 很早返回 D42，但它只有未經驗證的 checksum、缺少真正 verifier witness。Branch A 晚到且具有效 witness。R1 可以保留 B 的候選資料，但不得把 B 的速度轉化為「已驗證」的速度；若 A 未在期限內到達，結果應是超時或 INCONCLUSIVE。

反例 C—GPU 額外成本： CPU-only 已於 100 個任意時間單位完成全部功能；GPU branch 的關係 kernel 只花 15 單位，但 host dispatch、H2D、event、D2H、verification 與 queue 累積 140 單位。即使 kernel 明顯快，端到端仍然負收益。本示例數字純屬虛構示意，不得引用為 SMPDC 加速或降速的實測比例。

A.5 示意結果的合法 verdict

ContractTraceValidity: PASS (only if a real implementation passes its oracle)
GPUEndToEndPerformance: UNAVAILABLE (no real measurement)
AIQuality: NOT_APPLICABLE for this restricted deterministic verifier
HardwareCrossPlatform: UNAVAILABLE
SeriesClosure: ResearchProtocolClosure

注意第一行只是範例中應如何分類，不能因本段文字存在就填 PASS。若附錄 B 的有限 mock 在本輪執行通過，可另記為 V0 Mock Contract PASS，但不能與這個完整示意 trace 的真實重演混為一談。

附錄 B｜可獨立擷取執行的 V0 跨篇微型契約測試

B.1 目的與不涵蓋範圍

這段程式只使用 Python 3 標準函式庫，提供一個有限、手工建構的模型，演示 PWN generation、credit 一次性使用、R1/R2/R3 型別差異、提交權威、GPU buffer lease、AI model/KV/gradient 血緣、以及四態 verdict 的部分交叉行為。它是對本篇文字規則的可執行示例與防止自身規格錯誤的微型測試，不是完成的 PDAIS 虛擬機、MLIR 編譯器、OS scheduler、CUDA kernel、TLC 全狀態模型檢查或 AI 模型訓練。這些界線不能省略。

執行方式：從下方的 python fenced code 內容原樣保存成 UTF-8 .py，以標準 Python 3 執行。輸出應列出有限 mock assertion 的 PASS 計數。由於正式研究原始稿就是 Markdown，程式碼區塊的來源必須與這個檔案版本綁定；實際本輪已執行多少項測試須以驗證紀錄為準。

"""SMPDC Paper 11 limited V0 mock reference — no actual CPU/GPU/AI benchmarking."""
from dataclasses import dataclass

_COUNT = 0

def check(condition, message):
    global _COUNT
    if not condition:
        raise AssertionError(message)
    _COUNT += 1

class Flow:
    def __init__(self, flow_id, generation=1, owner="core0"):
        self.flow_id = flow_id
        self.generation = generation
        self.owner = owner
        self.active = True

    def migrate(self, target):
        old = self.generation
        self.generation += 1
        self.owner = target
        return old

    def admit(self, claimed_generation, observed_owner):
        return self.active and claimed_generation == self.generation and observed_owner == self.owner

class CreditLedger:
    def __init__(self, credits):
        self.unspent = set(credits)
        self.spent = set()
        self.logical = {}  # msg -> digest
        self.attempts = set()
        self.closed = False

    def send(self, credit, message, digest, attempt):
        if self.closed:
            return "EPOCH_CLOSED"
        if message in self.logical:
            if self.logical[message] != digest:
                return "MESSAGE_CONFLICT"
            if attempt in self.attempts:
                return "DUPLICATE_ATTEMPT"
            self.attempts.add(attempt)
            return "RETRY_SAME_LOGICAL"
        if credit not in self.unspent or attempt in self.attempts:
            return "NO_CREDIT"
        self.unspent.remove(credit)
        self.spent.add(credit)
        self.logical[message] = digest
        self.attempts.add(attempt)
        return "SENT"

class Reconciler:
    def __init__(self):
        self.r1 = {}
        self.r2 = {}
        self.r3 = {}

    def first_valid(self, key, version, expected_version, trusted):
        if version != expected_version or not trusted:
            return "REJECT_INVALID"
        if key in self.r1:
            return "ALREADY_SELECTED"
        self.r1[key] = version
        return "SELECTED"

    def attest(self, key, source, digest, independent_group):
        pool = self.r2.setdefault(key, {})
        if source in pool:
            return "DUPLICATE_SOURCE"
        if any(group == independent_group for _, group in pool.values()):
            return "CORRELATED_SOURCE"
        if pool and any(other_digest != digest for other_digest, _ in pool.values()):
            return "CONFLICT"
        pool[source] = (digest, independent_group)
        return "CONSISTENT_TWO" if len(pool) >= 2 else "NEED_MORE"

    def reconstruct(self, key, code_id, k, shards, known_bad=()):
        if k < 1 or not code_id:
            return "INVALID_CODE"
        good = {(shard_id, shard_code) for shard_id, shard_code in shards
                if shard_id not in known_bad}
        if any(shard_code != code_id for _, shard_code in good):
            return "CODE_MISMATCH"
        distinct = {shard_id for shard_id, _ in good}
        return "RECOVERABLE_SCOPE_ONLY" if len(distinct) >= k else "INSUFFICIENT_SHARDS"

class CommitAuthority:
    def __init__(self, generation=3, version=7):
        self.generation = generation
        self.version = version
        self.decisions = {}

    def commit(self, key, digest, generation, base_version, verified, scope):
        if not verified or scope != "canonical":
            return "UNAUTHORIZED"
        if generation != self.generation:
            return "STALE_AUTHORITY"
        if key in self.decisions:
            old_digest, _ = self.decisions[key]
            return "ALREADY_DECIDED" if old_digest == digest else "KEY_CONFLICT"
        if base_version != self.version:
            return "STALE_VERSION"
        self.version += 1
        self.decisions[key] = (digest, self.version)
        return "COMMITTED"

class DeviceLease:
    def __init__(self, generation=1):
        self.generation = generation
        self.alive = True
        self.users = set()
        self.kernel_done = False
        self.host_readable = False

    def submit(self, user, generation):
        if not self.alive or generation != self.generation:
            return "REJECT_LEASE"
        self.users.add(user)
        return "SUBMITTED"

    def record_kernel_done(self):
        if not self.users:
            return "NO_WORK"
        self.kernel_done = True
        return "KERNEL_DONE"

    def visibility(self, copied, synchronized):
        if not self.alive or not self.kernel_done or not copied or not synchronized:
            return "NOT_VISIBLE"
        self.host_readable = True
        return "HOST_READABLE"

    def import_host(self):
        return "IMPORTED" if self.alive and self.host_readable else "REJECT_IMPORT"

    def retire(self):
        if self.users:
            return "BUSY"
        self.alive = False
        self.generation += 1
        return "RETIRED"

@dataclass(frozen=True)
class Model:
    version: int
    tokenizer: str
    digest: str

@dataclass(frozen=True)
class KvLease:
    version: int
    tokenizer: str
    digest: str
    prefix: str
    alive: bool

def kv_usable(kv, model, prefix):
    return (kv.alive and kv.version == model.version and
            kv.tokenizer == model.tokenizer and kv.digest == model.digest
            and kv.prefix == prefix)

class GradientReducer:
    def __init__(self):
        self.gradients = {}

    def accept(self, run, step, batch, forward_v, backward_v, digest):
        if forward_v != backward_v:
            return "INVALID_WEIGHT_VERSION"
        key = (run, step, batch)
        if key in self.gradients:
            return ("DUPLICATE_IGNORED" if self.gradients[key] == digest
                    else "GRADIENT_ID_CONFLICT")
        self.gradients[key] = digest
        return "ACCEPTED"

def verdict(preregistered, evidence_tier, safe, quality, measured,
            meets_delta, enough_samples, required_device):
    if not required_device:
        return "UNAVAILABLE"
    if not preregistered:
        return "INCONCLUSIVE"
    if safe is False or quality is False:
        return "FAIL"
    if not measured:
        return "UNAVAILABLE"
    if evidence_tier == "V0_MOCK":
        return "INCONCLUSIVE"
    if safe is None or quality is None or not enough_samples:
        return "INCONCLUSIVE"
    return "PASS" if meets_delta else "FAIL"

# PWN: logical identity, placement, migration and fencing.
f = Flow("flow-A")
check(f.admit(1, "core0"), "01 original placement")
check(not f.admit(2, "core0"), "02 future generation unauthorized")
check(not f.admit(1, "core1"), "03 unadmitted owner unauthorized")
old = f.migrate("core1")
check(old == 1, "04 returned old generation")
check(f.generation == 2, "05 strictly increasing generation")
check(f.owner == "core1", "06 owner migrated")
check(not f.admit(1, "core0"), "07 stale owner fenced")
check(f.admit(2, "core1"), "08 current owner admissible")
f.active = False
check(not f.admit(2, "core1"), "09 stopped flow cannot run")

# Bounded logical sends: retry is not new logical work.
l = CreditLedger(["a", "b", "c"])
check(l.send("a", "m1", "D1", "t1") == "SENT", "10 initial send")
check(len(l.spent) == 1, "11 one credit consumed")
check(l.send("a", "m1", "D1", "t2") == "RETRY_SAME_LOGICAL", "12 retry")
check(len(l.logical) == 1, "13 retry not new message")
check(len(l.spent) == 1, "14 retry does not create credit")
check(l.send("a", "m1", "D1", "t2") == "DUPLICATE_ATTEMPT", "15 duplicate attempt")
check(l.send("b", "m1", "D2", "t3") == "MESSAGE_CONFLICT", "16 payload conflict")
check(l.send("a", "m2", "D2", "t4") == "NO_CREDIT", "17 double-spent credit")
check(l.send("b", "m2", "D2", "t5") == "SENT", "18 independent send")
check(len(l.logical) == 2, "19 distinct logical work")
check(len(l.spent) == 2 and len(l.unspent) == 1, "20 finite budget")
l.closed = True
check(l.send("c", "m3", "D3", "t6") == "EPOCH_CLOSED", "21 closed epoch")
check(len(l.spent) == 2, "22 close cannot mint work")

# R1 valid-first, R2 independent-source, R3 declared-code recovery only.
r = Reconciler()
check(r.first_valid("answer", 3, 4, True) == "REJECT_INVALID", "23 R1 version guard")
check(r.first_valid("answer", 4, 4, False) == "REJECT_INVALID", "24 R1 witness guard")
check(r.first_valid("answer", 4, 4, True) == "SELECTED", "25 first valid result")
check(r.first_valid("answer", 4, 4, True) == "ALREADY_SELECTED", "26 R1 dedup")
check(r.attest("proof", "A", "digest", "root-a") == "NEED_MORE", "27 one source")
check(r.attest("proof", "A", "digest", "root-a") == "DUPLICATE_SOURCE", "28 same source")
check(r.attest("proof", "B", "digest", "root-a") == "CORRELATED_SOURCE", "29 shared lineage")
check(r.attest("proof", "C", "other", "root-c") == "CONFLICT", "30 conflict")
check(r.attest("proof", "D", "digest", "root-d") == "CONSISTENT_TWO", "31 two consistent sources")
check(len(r.r2["proof"]) == 2, "32 conflicts not silently accepted")
check(r.reconstruct("blob", "C1", 2, [("s1", "C1")]) == "INSUFFICIENT_SHARDS", "33 insufficient shards")
check(r.reconstruct("blob", "C1", 2, [("s1", "C1"), ("s1", "C1")]) == "INSUFFICIENT_SHARDS", "34 duplicated share")
check(r.reconstruct("blob", "C1", 2, [("s1", "C1"), ("s2", "C2")]) == "CODE_MISMATCH", "35 code mismatch")
check(r.reconstruct("blob", "C1", 2, [("s1", "C1"), ("s2", "C1")]) == "RECOVERABLE_SCOPE_ONLY", "36 scoped recovery")
check(r.reconstruct("blob", "C1", 2, [("s1", "C1"), ("s2", "C1")], ["s2"]) == "INSUFFICIENT_SHARDS", "37 damaged share")
check(r.reconstruct("blob", "", 2, [("s1", "")]) == "INVALID_CODE", "38 invalid code")

# Commit authority: strict generation, version and commit-key behavior.
a = CommitAuthority()
check(a.commit("K1", "P", 2, 7, True, "canonical") == "STALE_AUTHORITY", "39 old authority")
check(a.commit("K1", "P", 3, 7, False, "canonical") == "UNAUTHORIZED", "40 unverified")
check(a.commit("K1", "P", 3, 7, True, "local") == "UNAUTHORIZED", "41 wrong scope")
check(a.commit("K1", "P", 3, 7, True, "canonical") == "COMMITTED", "42 authorized commit")
check(a.version == 8, "43 version advanced once")
check(a.commit("K1", "P", 3, 7, True, "canonical") == "ALREADY_DECIDED", "44 idempotent retry")
check(a.version == 8, "45 no double version bump")
check(a.commit("K1", "Q", 3, 7, True, "canonical") == "KEY_CONFLICT", "46 same-key collision")
check(a.commit("K2", "Q", 3, 7, True, "canonical") == "STALE_VERSION", "47 stale base")
check(a.commit("K2", "Q", 3, 8, True, "canonical") == "COMMITTED", "48 next legal commit")
check(a.version == 9, "49 version advanced twice total")
check(len(a.decisions) == 2, "50 one decision per key")

# GPU model: only an abstract event/lease state machine.
d = DeviceLease()
check(d.import_host() == "REJECT_IMPORT", "51 cannot import before submit")
check(d.submit("kernelA", 2) == "REJECT_LEASE", "52 stale device generation")
check(d.submit("kernelA", 1) == "SUBMITTED", "53 device submit")
check(d.import_host() == "REJECT_IMPORT", "54 submit is not visibility")
check(d.retire() == "BUSY", "55 no early retire")
check(d.record_kernel_done() == "KERNEL_DONE", "56 kernel completed")
check(d.import_host() == "REJECT_IMPORT", "57 kernel done not host readable")
check(d.visibility(False, True) == "NOT_VISIBLE", "58 copy missing")
check(d.visibility(True, False) == "NOT_VISIBLE", "59 synchronization missing")
check(d.visibility(True, True) == "HOST_READABLE", "60 required dependencies")
check(d.import_host() == "IMPORTED", "61 host import valid")
d.users.remove("kernelA")
check(d.retire() == "RETIRED", "62 retire after last user")
check(d.import_host() == "REJECT_IMPORT", "63 retired allocation invalid")
check(d.submit("kernelB", 1) == "REJECT_LEASE", "64 old generation invalid")

# AI model/gradient lineage: abstract correctness, not real training.
m = Model(7, "tokenizer-T", "weight-W7")
kv = KvLease(7, "tokenizer-T", "weight-W7", "prefix", True)
check(kv_usable(kv, m, "prefix"), "65 KV same identity")
check(not kv_usable(kv, Model(8, "tokenizer-T", "weight-W8"), "prefix"), "66 model version mismatch")
check(not kv_usable(kv, Model(7, "tokenizer-U", "weight-W7"), "prefix"), "67 tokenizer mismatch")
check(not kv_usable(kv, Model(7, "tokenizer-T", "other"), "prefix"), "68 digest mismatch")
check(not kv_usable(kv, m, "otherprefix"), "69 prefix mismatch")
check(not kv_usable(KvLease(7, "tokenizer-T", "weight-W7", "prefix", False), m, "prefix"), "70 expired lease")
g = GradientReducer()
check(g.accept("run", 12, "batch", 7, 8, "G") == "INVALID_WEIGHT_VERSION", "71 inconsistent fwd/bwd")
check(g.accept("run", 12, "batch", 7, 7, "G") == "ACCEPTED", "72 first gradient")
check(g.accept("run", 12, "batch", 7, 7, "G") == "DUPLICATE_IGNORED", "73 retried gradient")
check(len(g.gradients) == 1, "74 gradient not double counted")
check(g.accept("run", 12, "batch", 7, 7, "H") == "GRADIENT_ID_CONFLICT", "75 same ID mismatch")
check(g.accept("run", 12, "batch2", 7, 7, "G2") == "ACCEPTED", "76 distinct batch")
check(len(g.gradients) == 2, "77 valid accepted count")

# Verdict logic distinguishes unavailable, inconclusive, failure, and real-tier PASS.
V = lambda **kw: verdict(preregistered=kw.get("preregistered", True),
                         evidence_tier=kw.get("evidence_tier", "V1_CPU"),
                         safe=kw.get("safe", True),
                         quality=kw.get("quality", True),
                         measured=kw.get("measured", True),
                         meets_delta=kw.get("meets_delta", True),
                         enough_samples=kw.get("enough_samples", True),
                         required_device=kw.get("required_device", True))
check(V() == "PASS", "78 eligible claimed scope")
check(V(safe=False) == "FAIL", "79 unsafe candidate cannot win")
check(V(quality=False) == "FAIL", "80 lower-quality speed is not accepted")
check(V(meets_delta=False) == "FAIL", "81 below-effect threshold")
check(V(measured=False) == "UNAVAILABLE", "82 no experiment means unavailable")
check(V(required_device=False) == "UNAVAILABLE", "83 unsupported hardware unavailable")
check(V(preregistered=False) == "INCONCLUSIVE", "84 missing preregistration")
check(V(enough_samples=False) == "INCONCLUSIVE", "85 underpowered measurement")
check(V(quality=None) == "INCONCLUSIVE", "86 missing quality evidence")
check(V(safe=None) == "INCONCLUSIVE", "87 missing safety evidence")
check(V(evidence_tier="V0_MOCK") == "INCONCLUSIVE", "88 mock not physical performance")
check(V(evidence_tier="V0_MOCK", safe=False) == "FAIL", "89 mock still detects safety failure")

print(f"SMPDC Paper11 limited V0 mock assertions: {_COUNT}/{_COUNT} PASS")

B.2 輸出解讀

本例的 PASS 代表其個別 check(...) 條件在給定有限 Python 模型上成立。它沒有測試硬體記憶體順序、持久化 crash consistency、GPU device correctness、版本化 OS topology、帶真實資料的模型收斂或所有跨篇 ABI。尤其 verdict(...) 只是展示四態分類方式；其「有完整實機證據」的輸入值若由人為填入，不構成真正的性能證據。系統整合報告應把 model_result, evidence_grade, real_hardware_present 和 workload_quality_verified 另外記錄。

B.3 研究者可直接增加的負面測試

後續應加入 property-based stateful testing、fault injection、crash/restart persistent state、最小調度器、異步雙 worker 競爭、cuda stream 事件依賴及 replay differential testing。Python mock 的所有 successful cases 都可以構成日後真正 Runtime 的 regression candidates，但不能替代真實 lock-free queue、cache-coherence 或 driver 模型的檢查。

附錄 C｜研究 Manifest、Evidence 與 Verdict 的可解析 JSON 範例

C.1 限定作用域的 V0 測試 Manifest

此 JSON 僅描述 Paper 11 的有限 mock 測試，所有 null 都表示尚未取得，不代表實際硬體已量測到零值。predicted_assertions 是本原稿範例程式設計的檢查數；真實執行結果應由測試輸出確認。以下範例預留 canonical_source_sha256，必須等本篇正式原稿最後寫入並固定後再由外部程式計算，不可在正在變動的 Markdown 內自我嵌入不存在的 checksum。

{
  "schema": "ReproductionManifestV0_1",
  "study_id": "SMPDC-P11-V0-MOCK-REFERENCE",
  "experiment_tier": "V0_MOCK",
  "workload_family": "abstract_contract_state_machine",
  "semantics_kind": "ExploratoryPilot",
  "scope": [
    "flow_generation",
    "credit_identity",
    "typed_reconciliation",
    "commit_authority",
    "device_visibility_mock",
    "model_gradient_lineage",
    "verdict_classification"
  ],
  "source": {
    "canonical_file": "SMPDC_Paper11_System_Validation_Falsifiability_and_Series_Closure_v0.1_2026-10-17.md",
    "embedded_code_section": "Appendix B",
    "source_commit": null,
    "canonical_source_sha256": null
  },
  "runtime": {
    "language": "Python 3",
    "required_packages": ["python_standard_library"],
    "real_cpu_profiling": false,
    "real_gpu_execution": false,
    "real_model_training": false,
    "real_disk_wal_crash_recovery": false
  },
  "execution": {
    "random_seed": null,
    "randomness_used": false,
    "planned_assertions": 89,
    "actual_assertions": null,
    "actual_mock_test_verdict": "UNAVAILABLE_PENDING_EXECUTION_RECORD",
    "hardware_speedup_verdict": "UNAVAILABLE",
    "ai_time_to_quality_verdict": "UNAVAILABLE"
  },
  "claims_prohibited": [
    "SMPDC is faster on real hardware",
    "SMPDC GPU orchestration is empirically validated",
    "SMPDC training converges earlier",
    "all unbounded executions are safe"
  ]
}

正式執行後，應以新建的 evidence report 記錄實際 assertion 數量、使用的 Python interpreter、退出碼、原始輸出、執行環境、程式雜湊以及操作者。為保持 Markdown source 的自我一致性，此靜態示例不在寫稿過程中自動回填會改變原稿的執行結果。

C.2 未來 V1 的最低預註冊研究範例

此份是預註冊樣板，不是已執行的真實實驗。包含的「10%」只是一個候選實質採納門檻，研究者在正式執行前應根據 pilot 變異與使用情境確認或修改，並封存 pre-registration 版本。

{
  "schema": "SMPDCValidationProtocolV0_1",
  "study_id": "SMPDC-P11-W11-22-PILOT",
  "claim_id": "H11-VERIFIER-R1-LATENCY",
  "workload": "W11-22",
  "experiment_tier": "V1_CPU",
  "semantics_kind": "EquivalentExecution",
  "baseline_ids": ["B11-02", "B11-08"],
  "candidate_ids": ["A11-00", "A11-06"],
  "hardware": {
    "owner_reported": "older AMD desktop CPU; 32 GB RAM; RTX 3070",
    "actual_cpu_sku": null,
    "physical_core_count": null,
    "OS_build": null,
    "gpu_driver": null,
    "measured_topology_digest": null
  },
  "quality": {
    "oracle": "frozen_deterministic_test_verifier",
    "semantic_equivalence_required": true,
    "unauthorized_commits_allowed": 0,
    "invalid_answers_allowed": 0
  },
  "performance": {
    "primary_metric": "p99_authorized_completion_latency_ms",
    "lower_is_better": true,
    "practical_improvement_fraction_candidate": 0.10,
    "measured_value": null,
    "baseline_measured_value": null
  },
  "resources": {
    "CPU_budget_same_for_both": true,
    "RAM_budget_same_for_both": true,
    "energy_meter_available": null,
    "all_retry_and_duplicate_costs_included": true
  },
  "reproduction": {
    "source_commit": null,
    "dataset_digest": null,
    "seed_policy": "locked_before_confirmatory_run",
    "paired_run_plan": "locked_before_confirmatory_run",
    "minimum_sample_plan": "requires_pilot_variability_analysis",
    "warmup_policy": "identical_and_preregistered",
    "exclusion_policy": "errors_and_timeouts_not_silently_excluded"
  },
  "result": {
    "status": "UNAVAILABLE",
    "reason": "not yet implemented or measured"
  }
}

C.3 假想 ExperimentRunVerdictV0_1 不能當作真實結果

{
  "schema": "ExperimentRunVerdictV0_1",
  "run_id": "UNRUN-EXAMPLE",
  "workload_manifest_ref": "SMPDC-P11-W11-22-PILOT",
  "baseline_id": "B11-08",
  "candidate_id": "A11-00",
  "semantics_kind": "EquivalentExecution",
  "primary_metric": "p99_authorized_completion_latency_ms",
  "quality_status": "UNAVAILABLE",
  "resource_budget_status": "UNAVAILABLE",
  "safety_invariant_status": "UNAVAILABLE",
  "timing_scope": "request_arrival_to_authoritative_accepted_result",
  "raw_trace_digest": null,
  "reproducibility_manifest_ref": "SMPDC-P11-W11-22-PILOT",
  "verdict": "UNAVAILABLE",
  "unsupported_capability": "no V1 measurements in this paper",
  "failure_refs": [],
  "claims_allowed": ["study protocol specified"],
  "claims_prohibited": ["observed speedup", "measured reliability improvement"]
}

C.4 正式回填規則

若同一個 study 已執行 12 個 seed 或不同的硬體 session，不應把全部 run 壓成一筆沒法追溯的最終 PASS。每個 run 分別具 RunEvidenceBundle，統計報告引用集合的 digest 與分析程式版本。任何 one-sided cherry-pick 或手動覆寫 quality_status 都應在自動化報告中被拒絕。

附錄 D｜統計與實驗分析的最小再現程序

D.1 正式分析的固定順序

1. Load frozen preregistration and allowed comparator set.
2. Validate environment, source commits, model, dataset and quality contract.
3. Validate each RunEvidenceBundle and its raw trace digest.
4. Classify INVALID / OOM / TIMEOUT / CENSORED / ACCEPTED outcomes.
5. Apply only pre-registered exclusions; keep all original rows.
6. Group runs by platform, workload, seed, paired session and semantics kind.
7. Verify primary safety and quality constraints before latency/throughput.
8. Calculate primary endpoint from end-to-end accepted results only.
9. Estimate uncertainty at the independent-run level; report effect size.
10. Report negative results, resource amplification, and tail tradeoffs.
11. Compute workload-specific verdict; retain UNKNOWN or UNAVAILABLE.
12. Produce analysis code digest, report and link to raw evidence.

D.2 可信的重現與統計檢查

• 基線調優公平性： 在 development run 調整參數，確認性測試之前凍結 baseline／candidate 參數；不得只給新系統最新的 best effort。
• 吞吐與延遲區分： 對到達率固定的 serving workload，要求同一 arrival trace／request distribution；離線大批吞吐不能直接代表互動 p99。
• 設限： 訓練未達品質目標，應按事前 censoring 計畫報告；不能依任意失敗次數直接給出虛假的有限 $T_Q$。
• CPU／GPU 時間： 使用 host end-to-end 作主要時間；device timer 只能輔助解釋。
• 負載變化： 系統 10% 負載與 95% 負載可能出現不同最佳方案，須報告每個區間而不是挑最有利數字。
• 穩定性： 對多次 A/B 觀察到的方向反覆改變，不應說取得穩定收益。
• 數值容差： 在同演算法但不同浮點 reduction order 下，事前確定容差與品質對照；不可事後任意放寬。
• 統計顯著不等於工程有用： 即使巨量請求使非常小的 latency 差達統計顯著，仍需符合預先指定的實質增益門檻。
• 工程有用也不等於理論普遍： 在狹窄負載上大幅改善，可以是一個有價值的 domain-limited 結論，但必須保留 domain。

D.3 Safety-fail 的優先級

分析程序必須先檢查安全關鍵 failure，不能因平均 latency 改善便忽略 stale owner commit、R3 誤解碼、GPU use-after-free 或梯度雙加。Safety-fail 會令相關候選的合規性能判決無效或為 FAIL，縱使裸時間仍可被保留為診斷數據。診斷數據可以幫助修復，卻不能作正式採納證據。

D.4 情境性效能圖的輸出建議

當未來存在真實數據時，可以將 x 軸定義為 batch size、message fanout、CPU core count、GPU residency ratio、conflict rate 或 arrival rate，y 軸為相同品質下的 end-to-end speedup，並額外標示 p99、VRAM、energy 和 failure rate。圖上應畫出 confidence intervals、null effect line 與不可測區域。沒有實測資料時，禁止生成看似真實的連續效能曲線；僅能展示符號模型或標明 synthetic example。

附錄 E｜公開來源、既有技術及內部前作

E.1 第一系列 canonical 前作（本地 UTF-8 Markdown）

本稿的直接技術前置材料均為 SMPDC 第一系列先前完成的原始檔，並非以模型對話摘要替代：

• [I00] SMPDC_Paper00_Stellar_Multi_Primary_Persistent_Diffusive_Computing_v0.1_2026-10-16.md：九元中觀模型、研究主張邊界與系列依賴。
• [I01] SMPDC_Paper01_Multi_Primary_Workflow_Nodes_v0.1_2026-10-16.md：PWN、generation、owner lease。
• [I02] SMPDC_Paper02_Phase_Coupling_and_Bounded_Persistent_Diffusion_v0.1_2026-10-16.md：PhaseDiffusion、credit、背壓與靜止。
• [I03] SMPDC_Paper03_Redundant_Information_Flow_and_Primary_Node_Reconciliation_v0.1_2026-10-16.md：R0–R3、result／message／attempt 身分、LocalReconciliationOutcome。
• [I04] SMPDC_Paper04_Speculative_Execution_and_Deterministic_Commit_v0.1_2026-10-16.md：權威、版本、推測與外部效果。
• [I05] SMPDC_Paper05_Persistent_Diffusive_Instruction_Set_and_Executable_Semantics_v0.1_2026-10-16.md：PDAIS-IR、資源效果與抽象指令。
• [I06] SMPDC_Paper06_Diffusive_Programming_Language_and_Verifiable_Compiler_v0.1_2026-10-16.md：語言、型別效果、語義降階。
• [I07] SMPDC_Paper07_OS_and_AI_Dynamic_Control_Plane_v0.1_2026-10-16.md：OS 與可選 AI 控制、資源權威、降級。
• [I08] SMPDC_Paper08_CPU_GPU_Heterogeneous_Collaboration_v0.1_2026-10-17.md：GPU event、buffer lease、同步和批次淨收益。
• [I09] SMPDC_Paper09_Memory_Hierarchy_and_Microarchitectural_Mapping_v0.1_2026-10-17.md：快取、CCD／NUMA、局部性、硬體成本。
• [I10] SMPDC_Paper10_AI_Training_and_Inference_Domains_v0.1_2026-10-17.md：AI Workload Validity、Time-to-Quality、品質與四態 verdict。

前作實際 bytes 應保留在同一研究版本庫或同一系列發行包。本文只引用其明確的原始檔名，不虛構雲端檔案 ID、Commit 或外部分享連結。若單獨下載本篇，外部複驗者需要取得上述原始文件後才能執行完整跨篇契約核對。

E.2 相鄰 EveMissLab 理論的定位

先前《群星模型》《群星架構在計算機系統中的應用與改良計畫》提供節點式與動態硬體協作的思想來源；PCMT 提供相位本體／表示／演化／承載分層；GCCFT 提供全域耦合計算場、Phase-Aware Interaction、Runtime／Planner 與可證偽研究；GCCWT、GCCF、GCM 提供更廣義的跨資源計算及資源治理；ISQL-CMF 等則可作為將來的資料表示或 AI 工作負載對照候選。本篇不將這些相鄰理論的存在當成 SMPDC 性能證據，也不聲稱本系列取代它們的原有研究任務。

E.3 公開技術與學術文獻（查核日期：2026-10-17）

• [E1] MLCommons, MLPerf Training Rules. 品質目標、時間量測、系統與 framework 公平性、run 定義及預處理等；原始規則：https://github.com/mlcommons/training_policies/blob/master/training_rules.adoc。本篇借鑑其公平性和品質優先原則，沒有宣稱 SMPDC 參加正式 benchmark。
• [E2] MLCommons, MLPerf Inference Rules. SingleStream、Server、Offline 等測試場景、負載、延遲與 LoadGen 定義；https://github.com/mlcommons/inference_policies/blob/master/inference_rules.adoc。
• [E3] NVIDIA, CUDA C++ Best Practices Guide, Performance Metrics／Timing. 區分 CPU timers、device events、非同步 API 與同步成本；https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html。
• [E4] NVIDIA, Nsight Systems User Guide. CPU/GPU Timeline、CUDA API／kernel／copy trace；https://docs.nvidia.com/nsight-systems/UserGuide/index.html。
• [E5] Linux perf stat manual. Performance Monitor Units、可用事件及 counters 之適用範圍；https://man7.org/linux/man-pages/man1/perf-stat.1.html。
• [E6] Intel, VTune Profiler. CPU/GPU／NPU、microarchitecture、memory 與平台層分析；https://www.intel.com/content/www/us/en/developer/tools/oneapi/vtune-profiler.html。
• [E7] Leslie Lamport, TLA+ Tools／TLC Model Checker. 有限狀態安全與活性檢查的正式工具先例；https://lamport.org/tla/tools.html。
• [E8] E. W. Dijkstra and C. S. Scholten (1980), “Termination Detection for Diffusing Computations.” Information Processing Letters 11(1), pp. 1–4, DOI: 10.1016/0020-0190(80)90021-6；https://research.tue.nl/en/publications/termination-detection-for-diffusing-computations/。證明本篇的 diffusing/termination 術語具有成熟先例，不能據此單獨宣稱原創。
• [E9] Jeffrey Dean and Luiz André Barroso (2013), “The Tail at Scale.” Communications of the ACM 56(2), pp. 74–80；https://research.google/pubs/the-tail-at-scale/。作為 hedging 與 tail latency 的成熟研究對照。
• [E10] StarPU, “A Unified Runtime System for Heterogeneous Multicore Architectures.” 具有異質 task scheduling、資料搬移與複製、非同步執行等特性；https://starpu.gitlabpages.inria.fr/。SMPDC 必須在同功能範圍與可實作平台上公平比較，而非忽略現成成果。
• [E11] LLVM/MLIR, “Operation Definition Specification.” 具型別 operation／dialect／verifier 的現成擴充機制；https://mlir.llvm.org/docs/DefiningDialects/Operations/。PDAIS-IR 的 proposed dialect 需經實際 parser/verifier 實作，不能只靠概念語法。
• [E12] ACM SIGSIM PADS Artifact Evaluation (2024). Artifact 的 documented、consistent、complete、exercisable 與驗證要件；https://sigsim.acm.org/conf/pads/2024/blog/artifact-evaluation/。
• [E13] MLCommons, MLPerf Training Working Group. 針對品質門檻及多硬體訓練基準的制度參照；https://mlcommons.org/working-groups/benchmarks/training/。
• [E14] NVIDIA, CUDA C++ Best Practices Guide, Getting the Right Answer. GPU reference comparison、unit testing、浮點 non-associativity；https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/contents.html。
• [E15] Hypothesis, Property-based Testing Documentation. 未來 stateful／generated counterexample 測試候選；https://hypothesis.readthedocs.io/en/latest/。本篇只以 Python 標準函式庫示例，未聲稱使用該程式庫實測。

引文定位： 上述文獻支持它們自身的技術事實與公認方法，不會自動構成 SMPDC 性能／形式安全已成立的外部證據。若未來依特定版本進行正式 benchmark，必須記錄當次實際規則版本與 commit；以上網頁可能在後續更新，不應把不斷演進的 master 連結當成不可變的實驗版本。

附錄 F｜Canonical Source、語義版本與研究完整性閘門

F.1 正式原稿必須符合的內容規則

• 檔案需為真正 UTF-8，不能以 ChatGPT 渲染畫面複製公式當作論文原始碼。
• 數學原始碼只使用 $...$ 與 $$...$$，不以 \\(...\\)／\\[...\\] 混用 canonical 分隔符。
• 不使用 unicode-escape 來回轉換公式，不把 LaTeX 數學轉成 Unicode 後再當來源。
• 各項 V11-P1...P12 均註明前提／限制，不把安全局部性推廣為普遍加速。
• 各項 C11-01...48 與 F11-01...48 編號唯一且連續。
• 程式碼區塊成對、例示 JSON 可解析、Python 嵌入範例可執行。
• 不能因 Python mock 的 PASS 把 CPU／GPU／訓練的正式驗證狀態自動升級。
• 本篇引文編號與來源 URL 可追溯，禁止杜撰實測數據、硬體持有情況或 GitHub commit。

F.2 驗證通過與尚未取得的證據需分欄報告

正式文件在完成原始碼檢查後，應另留 CanonicalSourceValidationRecord，至少具有 filename、byte_size、sha256、utf8_check、math_delimiter_check、fence_check、heading_check、json_check、embedded_python_mock_result。即使這些項目都 PASS，real_CPU_performance、real_GPU_performance、real_AI_quality 若沒有執行便仍為 UNAVAILABLE。

F.3 版本更新原則

本系列第一輪採 v0.1，正式原稿完成不代表所有建議永遠固定。後續應以 v0.2 或 SMPDC Validation Report 保存新的實驗，讓早期假說、成功、失敗及修訂具有完整時間序列。若某跨篇 typed ABI 必須破壞性修改，應提供 migration specification，不可靜默改寫先前已封存的原稿。

F.4 最終結案聲明

Paper 11 v0.1 的正式結案類型為 ResearchProtocolClosure。 在有限概念模型與文件規格之外，沒有宣稱完成新型 CPU、實體擴散指令集、跨平台高階運算、AI 更快收斂或普遍的正收益。這並非保守措辭，而是本系列最基本的可證偽研究不變量：結論只能與其證據等級相稱。

SMPDC 第一系列 Paper 00–11｜研究規範閉環（2026-10-17，v0.1）