title

SMPDC Paper 07｜作業系統與 AI 動態控制架構：多主工作流排程、異質核心配置、資源治理與可驗證控制平面

english_title

Operating-System and AI Dynamic Control Architecture: Multi-Primary Workflow Scheduling, Heterogeneous Core Placement, Resource Governance, and a Verifiable Control Plane

series

SMPDC — Stellar Multi-Primary Persistent Diffusive Computing

paper

07 / 11

version

0.1

status

Full Research Manuscript — Candidate Control-Plane Contract; Implementation and Performance Validation Pending

date

2026-10-16

language

zh-TW

primary_concept_originator

Neo.K

research_collaboration

Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

canonical_source

UTF-8 Markdown; inline math $...$ ; display math $$...$$

predecessors

SMPDC Paper 00 v0.1 (2026-10-16) · SMPDC Paper 01 v0.1 (2026-10-16) · SMPDC Paper 02 v0.1 (2026-10-16) · SMPDC Paper 03 v0.1 (2026-10-16) · SMPDC Paper 04 v0.1 (2026-10-16) · SMPDC Paper 05 v0.1 (2026-10-16) · SMPDC Paper 06 v0.1 (2026-10-16)

artifact_scope

OS/runtime architecture, AI-free deterministic policy, advisory AI scheduling, capacity and authority control, typed scheduling contracts, fail-safe recovery, conditional propositions, falsification-oriented experiments

SMPDC Paper 07｜作業系統與 AI 動態控制架構

——多主工作流排程、異質核心配置、資源治理與可驗證控制平面

英文題名： Operating-System and AI Dynamic Control Architecture: Multi-Primary Workflow Scheduling, Heterogeneous Core Placement, Resource Governance, and a Verifiable Control Plane
研究系列： 群星多主節點持續擴散計算論（SMPDC）
主構想提出： Neo.K
研究協作： Aletheia／GPT-6
機構： EveMissLab／一言諾科技有限公司
日期／版本： 2026-10-16／v0.1
研究成熟度： L1：完整候選理論、控制契約、條件性安全命題與可證偽實驗方案；未完成 SMPDC 控制器原型的實機效能驗證。
直接承接： SMPDC Paper 00–06 [I0–I6]。
研究先例查核： Linux kernel、Microsoft Learn、Intel 與 NVIDIA 的公開技術文件，查核截至 2026-10-16 [E1–E12]。

作者： Neo.K
日期： 2026-10-16
版本： 0.1

摘要

SMPDC Paper 00–06 已經建立一條候選近硬體研究路線：多個 CPU 核心可作為主要工作流的候選承載者；邏輯工作流維持獨立狀態及生命週期；工作流依任務相對的相位與可驗證的耦合資格交換資訊；有限的擴散 credit、背壓及事件世代抑制無界訊息傳播；R0–R3 區分單路、競速、異源佐證及編碼冗餘；推測運算的局部進度與權威提交相分離；PDAIS 抽象指令及 SMPDC-Lang 則將其轉為具型別的可執行契約。上述工作尚未回答：當一個系統有不同 CPU 核心、快取域、記憶體壓力、GPU 工作、外部 OS 排程和持續流量波動時，誰有權決定工作流在哪裡執行，以及控制決策如何在保留安全界線下適應變化？

本文提出 SMPDC Control Plane Contract v0.1，把執行管理嚴格區分為五個層次：受型別約束的程式／IR、無 AI 的確定性政策核心、可被驗證的資源配置與 OS 適配層、受保護的執行與權威層，以及只能建議而不能自行授權的 AI 規劃器。該架構允許每個 Primary Workflow Node（PWN）保有自己的主要工作流，但不把所有 CPU 實體核心視為固定獨占，也不把 CPU affinity、OS 調度意圖與實際被排程的核心混為一談。

研究核心交付包括：FlowRegistryV0_1、CoreTopologySnapshotV0_1、FlowPlacementProposalV0_1、AdmittedPlacementDecisionV0_1、ControlEpochV0_1、AuthorityGuardV0_1、WorkerHandoffV0_1、AIAdvisoryProposalV0_1 及 ControlTraceEventV0_1；一個具有 resource ledger、admission、plan validation、reconciliation、worker migration、fencing、降載、GPU adapter 及安全回復的控制狀態機；二十八條控制不變量、七項具有明確前提的條件性命題、三十二類反例與失效注入；以及從完全不需 AI 的 V0 參考模擬器走向既有 Windows／Linux 桌機 V1 的評估方法。

本文並未宣稱「AI 調度」本身為新技術，亦不宣稱必須替換作業系統核心排程器。Windows CPU Sets、Linux CPU affinity／cgroup v2／utilization clamping／sched_ext、Intel Thread Director、CUDA streams/events 等既有機制提供了不同程度的實作能力與成熟基線。新研究問題是：能否在不破壞既有 OS 權限、線性資源、相位與提交語義的前提下，將多主工作流持續性、相位資訊、資源成本和可審計建議串成一個可量測且可否證的控制閉環？

關鍵詞： 多主工作流、作業系統排程、異質核心、P-core、E-core、CCD、SMT、CPU Sets、Linux sched_ext、cgroup v2、資源租約、可驗證控制、確定性政策、AI 建議、fencing、背壓、負載遷移、GPU adapter、AI-free runtime、可證偽實驗。

1. 本篇位置：從可編譯工作流到可執行控制閉環

1.1 前六篇交付了什麼

Paper 00 提出 SMPDC 的中觀—宏觀九元模型與研究邊界 [I0]；Paper 01 明確將邏輯主要工作流、OS 執行緒、邏輯 CPU與實體核心分開，提出 PrimaryFlowNode Contract v0.1 [I1]。Paper 02 定義具型別相位、耦合資格、有限擴散 credit、背壓及事件世代 [I2]。Paper 03 建立 R0–R3 的候選結果與證據血緣，不讓重複傳送冒充獨立證據 [I3]。Paper 04 定義預演、局部驗證、權威決策和外部效果的分離 [I4]。Paper 05／06 把上述契約落成 PDAIS 抽象指令、語言型別效果與 PDAIS-IR [I5–I6]。

這條鏈已經有「允許做什麼」的語義；尚缺「執行時資源在哪裡、何時啟動／睡眠、由誰決定、OS 是否真正照辦」的操作協議。若直接要求 AI 控制每個核心，就會同時破壞實驗公平性與權限邊界；若只把現有執行緒池換成一個 AI scheduler 名稱，則不會形成新理論內容。

1.2 本篇唯一主問題

在保持多個 PWN 的局部主要工作流責任、相位與資源不變量的前提下，是否可以建立一個即使沒有 AI 仍安全可用、具可驗證控制事件與異質硬體適配能力的運行層，並衡量 AI 加入後的邊際效益？

它同時包含兩類不同問題：安全性／合法性（哪些配置不能做）與最佳化（合法候選中哪個較有效）。前者不能用模型分數置換；後者也不能只靠漂亮的安全命題宣稱性能提升。

1.3 本篇不處理的問題

本文不重新定義 Paper 04 的權威提交模型，不替 Paper 03 重新規定來源證據的真實性，不把 GPU 拆分策略當成既定最佳演算法，不將所有 P/E core 或 CCD 低階特性視為已量測，不提出新的可上矽晶片實體指令，也不將 AI 的建議輸出視為內建硬體權限。這些問題分別由本篇契約、Paper 08、Paper 09 或實機實驗限制。

1.4 成熟度分層

• L0： 概念及研究假說，尚無完整可執行狀態機。
• L1： 本篇的正式候選契約、狀態轉移、反例及實驗設計。
• L2： 參考控制器／模擬器已實作、通過可重複的 V0 測試，範圍限已覆蓋子集。
• L3： 既有 CPU／OS 的真實平台實測，含 workload、manifest、統計、熱／功率與失敗追蹤。
• L4： 具有經第三方複現或新硬體證據支持的效能／正確性論斷。

本稿目前為 L1；下文中的 PASS、Rejected、Applied 若出現在示意 trace，均指預期語義，不是已實測報告。

2. 四重分離：控制、建議、授權與實體執行

2.1 控制平面不是權威平面的另一個名字

建議的分離如下：

SMPDC-Lang / PDAIS-IR
        |
        v
Typed Execution Intent + Compile Manifest
        |
        v
AI-free Policy Controller <---- Optional AI Proposal
        |                         (non-authoritative)
        v
Admission + Budget + Authority Guard
        |
        v
Placement Decision + OS Adapter Request
        |
        v
OS Kernel Scheduler / CPU Runtime / GPU Adapter
        |
        v
Observed Execution + Effect/Commit Authorities
        |
        v
Trace + Reconcile + Feedback ----> next control epoch

程式語義層聲明合法效果；決策候選層產生候選 placement；admission 層核對容量與授權；OS 層最終對 CPU 執行進行排程；權威層決定受控狀態的有效寫入和外部效果。這些層存在接口，但不能相互冒名。即使在同一程序或同一 CPU 封裝中，也保留邏輯分離。

2.2 OS 的權限邊界不可被虛構

一般使用者程式可以在系統允許範圍內要求親和性、優先級、某些效能提示或特定資源限制，但不擁有 CPU 封裝的主權。OS 可根據核心在線情況、處理器群組、程序權限、排程類別、容器、電源與熱條件決定實際執行。GetSystemCpuSetInformation、SetThreadSelectedCpuSets 是 Windows 提供的 CPU Set 探索與線程選擇 API；Linux 的 sched_setaffinity、cpuset 與 cgroup 也會受有效可用 CPU 集合約束 [E1–E5]。

因此，PlacementDecision 不是 hardware guarantee，AffinityRequested 不是 CoreActuallyRunning，CoreAllowed 更不表示核心獨占。任何本篇效能分析必須保留 request／effective constraints／observed 三層欄位。

2.3 AI 的功能是可拒絕的建議

AI 可依據觀測、歷史 profile、排隊時間、熱壓力和預測需求，提出較佳的工作流配置或策略切換。但 AI 不可自行發行 SendCredit、AuthorityCap、OwnerFencingToken、CommitDecision 或 OS 特權，也不得透過 Prompt／模型輸出繞過 compiler／runtime guard。此原則與已經存在的 GCM Phase C「AI proposal 不是授權」邊界一致 [I9]。

2.4 全域控制不取消局部自治

一個 PWN 仍有自己的局部事件處理、狀態演化、phase readiness 與工作片段執行決定。控制平面只管理可授權的承載、預算、優先級、流控和安全遷移。Global Control 不等於 One Primary Workflow，也不表示需要一個唯一的大核先處理全部訊息。多主與可集中執行的政策查驗可以同時成立。

2.5 控制層與資料層的分離必須量測

控制開銷可能來自 TopologyQuery、MetricsSnapshot、PlanSearch、PolicyValidate、OSBindRequest、Migration、RecordTrace，而資料層開銷主要是實際計算、訊息、狀態、GPU copy 和聚合。若將額外控制訊息全部忽略，再以結果更快作結論，則比較不公平。控制平面要提供自己的成本計量與可關閉選項。

3. 形式骨架：從 Paper 00 九元狀態到控制投影

3.1 不能偷偷修改 Paper 00 的 canonical 系統

SMPDC Paper 00 已有九元中觀狀態；Paper 07 不另行重新命名或重解其各欄位。本文只引入從該系統、執行資源及時間觀測得到的控制投影：

其中：

• $F_t$：受治理的 PWN／flow registry snapshot；
• $T_t$：觀測到的 CPU、快取、NUMA、OS group、GPU 能力拓撲；
• $B_t$：容量、credit、記憶體、控制開銷與資源預算；
• $Q_t$：工作流就緒佇列與待處理耦合事件；
• $A_t$：有效的外部／本地權威引用與世代資訊；
• $P_t$：已核准政策版本、硬性限制與軟目標；
• $H_t$：目前及歷史的承載、遷移與排程觀測；
• $L_t$：控制租約、所有權與 fencing 的活躍集合；
• $X_t$：觀測品質、時間戳、來源及未知項的證據。

此投影不是所有資料都要完整常駐記憶體的要求。可以保存版本化索引、局部投影或延遲取得引用；但使用過期資料決策時必須明確標示 freshness 與 guard。

3.2 候選決策不是執行事件

定義候選計畫：

其中 $G_t$ 表示本輪目標， $V_t$ 是已知策略／模型版本。接著必須經過驗證與資源裁定：

$R_t$ 是外部有效權限與保留系統； $D_t$ 不是二元成功，至少包含 Admitted、Modified、Deferred、Rejected 或 Unknown 等具型別結果。實體執行時，OS 的行為產生另一個觀測：

這些表示式只定義系統分工；不聲稱存在一個能保證全域最優的函數 $\Pi$，也不將 $O_{t+1}$ 的非確定性歸咎於模型錯誤。

3.3 硬性安全約束與軟目標

令 $\mathcal K(\pi_t,\Omega_t)$ 表示權限、版本、租約、容量、背壓與承載要求均成立。控制器只能在滿足此條件的候選集合中做優化：

其中：

這不是假定能計算精確 argmin；實務上可以選擇第一個通過 guard 的候選，或以固定次數的受限搜尋取得近似解。Safety First 是合法集合界線，並非在效能目標函數中加上一個很大的懲罰值就算實現。

3.4 多尺度時間及三種世代

控制平面同時存在：event_epoch（單次擴散責任範圍）、flow_generation（PWN 的有效 owner 版本）、control_epoch（控制器產生快照與決策的代次）。它們不可共用一個 epoch 欄位。

例如同一 event_epoch=E17 期間，flow 的 OS worker 可能因核心下線安全換到另一 worker，因而 flow_generation=G8；控制器可在這段期間完成兩輪 control_epoch=C41/C42。三個世代的用途和單調性不同，不能任意改寫。

4. FlowRegistryV0_1：工作流身份、狀態與治理欄位

4.1 Registry 是必要控制接口，而非中央巨型狀態儲存庫

FlowRegistry 應記錄足以找到每個 PWN 與其控制承諾的資訊，不應吞併 Paper 01 的所有本地受控工作狀態、Paper 03 的完整證據內容，或 Paper 04 的權威 WAL。Registry 保存引用與有效版本，允許分散、分片與局部快取；任何快取決策須有版本檢查。

4.2 候選資料契約

FlowRegistryEntryV0_1 {
    flow_id: StableFlowId
    contract_version: SchemaVersion
    lifecycle: Registered | Ready | Running | Suspended | Migrating
             | Quiescent | Draining | Retired | Faulted
    owner_generation: MonotonicGeneration
    local_state_ref: VersionedStateReference
    local_owner_scope: AuthorityScope
    phase_snapshot_ref: OptionalVersionedPhaseState
    active_event_epochs: BoundedSet[EventEpoch]
    required_effects: EffectSet
    eligible_capabilities: CapabilityRequirementSet
    placement_intent: PlacementPreference
    current_worker_ref: OptionalWorkerId
    current_execution_lease_ref: OptionalExecutionLease
    current_fencing_token_ref: OptionalFencingToken
    budget_ref: ResourceBudgetIdentifier
    backlog_ref: BoundedQueueMetrics
    policy_version: PolicyDigest
    last_confirmed_observation: ObservedPlacementOrUnknown
    last_transition_trace: TraceReference
}

本型別以 Entry 定位為註冊快照。有些欄位由高權限 adapter 查詢、有些由 PWN 本身回報、有些是權威服務簽發引用。Registry 不能因為收到包含 owner_generation=999 的未受信任訊息，就自行相信它比目前版本新。

4.3 五種不可混淆的工作流狀態

1. Ready：具合法就緒條件，尚未保證有 CPU 時間。
2. Running：已收到最近一個 OS／worker 觀測，但該事實可能隨搶占而改變。
3. Suspended：保留邏輯身份及責任，但當下不主動消耗 CPU 時間。
4. Quiescent：特定事件世代已符合 Paper 02 的靜止偵測；不表示永久工作流死亡。
5. Migrating：進行 owner handoff，舊世代仍不能被自動視為已撤銷；需等待 fencing 的授權結果。

Ready 不等於 Running，Suspended 不等於 Failed，Quiescent 也不等於 Retired。這些區分會直接影響資源回收、統計及可恢復性。

4.4 更新責任範圍

• Flow Owner：聲明本地 readiness、進度與希望的資源特性。
• Policy Controller：更新排程候選、合法優先級、允許移動的成本評估。
• Admission／Authority：建立具租約和版本的實際承載授權。
• OS Adapter：報告親和性 API 接受與否及具體觀測值。
• Evidence Store：追加 trace，但不能直接修改主節點的正式結果。

Registry 更新可採事件日誌 + snapshot；若實驗使用單程序記憶體版本，應明確聲明失電後無法保證恢復。

5. CoreTopologySnapshotV0_1：辨識異質性而非只讀核心數

5.1 實體 CPU 與邏輯 CPU 分離

在 SMT 環境中，同一實體核心可能有多個 OS 可見的邏輯執行單元；其間共享前端、部分執行單元、快取及電力限制。將每個 logical processor 都當成同等、可獨立保證速度的 CPU 核心，會高估可用實體能力。拓撲應將 core、logical CPU、cache domain、NUMA、CPU package 分成不同識別。

5.2 大小核不是唯一異質性

Intel P/E core 的微架構、效率及排程提示差異，是一種異質性；AMD 多 CCD、不同 L3／3D V-Cache／時脈與 NUMA 局部性，是另一種異質性；不同 SMT sibling 的資源共享、記憶體通道飽和、封裝熱限制與功率管理，又是獨立維度。單一 scalar core_speed 不足以完整代表這些關係。

5.3 拓撲快照型別

CoreTopologySnapshotV0_1 {
    topology_generation: TopologyGeneration
    observation_time: MonotonicTimestamp
    source: OSProbe | PlatformAdapter | TestFixture
    os_name: OSFamily
    os_build: VersionString
    scheduler_class_if_observable: OptionalString
    packages: List[PackageDescriptor]
    physical_cores: List[CoreDescriptor]
    logical_cpus: List[LogicalCpuDescriptor]
    cache_domains: List[CacheDomainDescriptor]
    numa_domains: List[NumaDomainDescriptor]
    cpu_groups: List[OsProcessorGroup]
    online_mask: OSCPUSet
    process_allowed_mask: OSCPUSet
    observed_effective_mask: OSCPUSet
    core_capacity_hints: OptionalTypedHints
    cpu_frequency_observations: OptionalSampledMeasurements
    thermal_power_observations: OptionalSampledMeasurements
    gpu_capabilities: OptionalList[DeviceCapabilityReference]
    probe_uncertainty: TypedUnknowns
}

topology_generation 必須改變的時機至少包含 CPU hotplug、有效 cpuset 變動、processor group 或親和性邊界改變，以及會使承載合法性失效的 OS policy 變更。僅頻率浮動不一定需要變更拓撲世代，但應更新其獨立觀測版本。

5.4 Windows 觀測界面

Microsoft GetLogicalProcessorInformationEx 可查詢 RelationProcessorCore、RelationCache、RelationNumaNode、RelationProcessorPackage 等關係；GetSystemCpuSetInformation 可取得可用 CPU Sets 的 OS 描述；SetThreadSelectedCpuSets 提供執行緒層級的選擇請求 [E1–E3]。Windows 大小核或 processor group 的細節，必須依實際 OS 版本與欄位取得結果辨認，不能單看某個網路排行榜推斷。

5.5 Linux 觀測界面

Linux V1 可從 sysfs CPU topology、cache 層級、NUMA node、sched_getaffinity、cgroup v2 cpuset.cpus.effective 等取得不同側面的資訊 [E4–E6]。若容器授予 CPU 2–5，單機即使有 24 顆核心也不能把其他 CPU 視為可使用。cpu.max、memory.max、cpu.pressure／PSI、cpu.uclamp.* 等可提供不同性質的控制或觀察，並非全部都是 CPU 實際時鐘週期分配保證。

5.6 Thread Director 與 AMD CCD 的具體界線

Intel Thread Director 提供執行時分類提示供作業系統排程參考，不是使用者程式可直接繞過 OS 的執行權限；AMD CCD 與不同快取層級應由拓撲測試及實際效能 profile 反映，而不以「大核／小核」一詞涵蓋所有 AMD 多晶粒差異 [E7]。SMPDC 的抽象演算法應能處理無大小核差異的 CPU；否則第一版就無法使用現有機器進行 V1。

6. OS 接口與承載意圖：Request、Eligible、Observed

6.1 三種集合定義

令 $R_f(t)$ 表示控制器對工作流 $f$ 所提出的 CPU 配置意圖， $E_f(t)$ 表示 OS 權限、程序限制與運作政策容許的集合， $O_f(t)$ 表示在觀測窗口中實際執行過該工作流的處理器集合。一般不能寫成三者相等：

尤其 R_f 可能只是效能偏好而非強制綁核；O_f 是含取樣誤差的觀測。若 API 要求成功，最多能推論該次 OS 呼叫返回成功，不能推出「此後每個時刻都由某顆物理核心獨占執行」。

6.2 適配層的最低接口

OSPlacementAdapterV0_1 {
    inspect_topology() -> Result[CoreTopologySnapshot, ProbeError]
    effective_eligibility(flow) -> Result[OSCPUSet, AccessError]
    request_cpu_sets(worker, allowed_set, mode)
       -> AppliedRequest | Deferred | Rejected | Unknown
    query_observed_cpu(worker) -> SampledCpuObservation | Unknown
    suspend_or_park(worker) -> Applied | Pending | Rejected | Unknown
    set_legal_priority_hint(worker, bounded_hint) -> Result
    query_pressure_and_budget() -> TypedResourceObservation
    release_temporary_request(handle) -> Result
}

Adapter 必須能以 Unsupported 表示平台沒有等價能力，而不是直接省略權限檢查或假造 Applied。所有 privileged path 必須由可審計且受作業系統權限控制的進程執行。

6.3 不建議一開始替換 OS Scheduler

Linux sched_ext 讓使用者可編寫 BPF scheduler，並在錯誤或停滯等情況下退回預設 fair-class 排程，但官方文檔也明確標示其 BPF scheduler ABI 不保證跨版本穩定 [E8]。V0／V1 因而應先做 user-space policy+adapter；只有已經知道標準 API 無法處理哪個特定瓶頸，才在隔離實驗機上建立 sched_ext adapter。Windows 不應為了比較而假定存在同等可注入核心調度器的公開 API。

6.4 人為綁核可能造成的反效果

嚴格綁核會降低遷移、改善某些快取局部性，但也可能讓空閒核心無法承接熱點工作，增加排隊、阻塞、封裝功率峰值和 OS 其他任務的競爭。任何 pin_all 策略都必須有 unbound 基線。不能只在理論上說「每核心有一顆星」就預設綁核優於 OS 排程。

6.5 OS 請求的資源租約

ExecutionLease 是 SMPDC 對自身 worker 權限的一份邏輯治理契約，不能誤稱由 Windows CPU Sets 或 Linux sched_setaffinity 原生提供所有相同語義。真正有效寫入權來自受保護的 owner generation／fencing guard；OS 親和性只是可能承載該工作流的範圍控制。

7. 控制世代、觀測品質與有效期

7.1 ControlEpochV0_1

ControlEpochV0_1 {
    control_epoch_id: MonotonicControlEpoch
    controller_generation: MonotonicControllerGeneration
    snapshot_topology_generation: TopologyGeneration
    registry_version: RegistryVersion
    policy_digest: PolicyDigest
    resource_ledger_version: LedgerVersion
    observation_window_ref: WindowReference
    observation_confidence: TypedQualityEstimate
    opened_at_monotonic: MonotonicTimestamp
    deadline_or_expiry: BoundedExpiry
    closed_reason: Applied | Replaced | Expired | Cancelled | Failed
}

控制世代不能直接授予新的 propagation credit 或權威提交權；一輪控制器重排也不能使事件世代的全部傳送 credit 自動刷新。

7.2 新舊觀測不可混合成一個假快照

假設核心拓撲查詢來自時間 $t_1$，CPU 使用率來自 $t_2$，GPU 占用率來自 $t_3$ ；三者不保證同時。控制器應保留採樣時間、最大可容忍資訊年齡及版本識別，再由策略判定是否可以用這組資料生成決策。

7.3 觀測不確定性作為一級狀態

缺少功率感測器時，PowerMeasurement=Unknown 不得當作 0 W。看不到 GPU 佇列時，GpuLoad=Unknown 不得假設 0%。AI planner 尤其不得以敘述方式補完無法直接量測的真實資源值。必要時採保守策略、重新觀測，或限制參與候選集合。

7.4 過期計畫的拒絕規則

一個 plan 在接受時若其 topology_generation、registry_version、policy_digest 或 authority generation 已不符合受保護快照，必須拒絕、重驗或明確進入 Deferred。若允許局部相容版本重新驗證，需出示具體 equivalence test，不得單靠 stale_but_probably_ok=true 字串越過安全檢查。

8. FlowPlacementProposalV0_1 與 AdmittedPlacementDecisionV0_1

8.1 候選 plan 與核准決策具有不同型別

排程器可能產生 Prefer core group A、Move flow B toward last-level cache domain C、Park flow D until phase-ready 等不同建議。建議必須具備可審查的 reason、版本及成本估計，但此類資料不是有效權限。核准器要能對候選進行修改、拒絕、延後或明確地保持原配置，而不是只返回 true/false。

8.2 候選配置契約

FlowPlacementProposalV0_1 {
    proposal_id: StableProposalId
    origin: DeterministicPolicy | AIAdvisor | HumanOverride
    origin_version: BuildOrModelVersion
    control_epoch_id: ControlEpoch
    snapshot_refs: SnapshotVersionSet
    flow_scope: BoundedSet[FlowId]
    candidate_actions: OrderedList[TypedPlacementAction]
    predicted_resource_use: BoundedEstimateWithUnits
    predicted_benefit: OptionalEstimateWithConfidence
    expected_migration_cost: TypedCostEstimate
    required_capabilities: CapabilityRequirements
    evidence_refs: BoundedList[EvidenceReference]
    requested_expiry: MonotonicExpiry
    explanation: BoundedNonAuthoritativeText
    schema_version: Version
}

一個 predicted_benefit 估計應包含來源資料的分布、有效期與估計誤差；沒有足夠 sample 時使用 Unknown，不能把主觀理由偽裝成「預期加速 42%」。

8.3 核准決策契約

AdmittedPlacementDecisionV0_1 {
    decision_id: StableDecisionId
    input_proposal_id: StableProposalId
    control_epoch_id: ControlEpoch
    result: Admitted | Modified | Deferred | Rejected | Unknown
    admitted_actions: BoundedList[TypedPlacementAction]
    resource_reservation_refs: BoundedList[ReservationReference]
    authority_guard_ref: AuthorityGuardReference
    effective_policy_digest: PolicyDigest
    topology_generation: TopologyGeneration
    registry_version: RegistryVersion
    resource_ledger_version: LedgerVersion
    execution_deadline: MonotonicDeadline
    rejection_or_modification_reasons: TypedReasonSet
    audit_event_ref: TraceReference
}

Modified 也是受保護的新決策，不是把原提案任意刪減後仍讓舊 AI 提案聲稱生效。所有被修改的行動都須有新的資源和權限驗證結果。

8.4 最小動作字母表

8.5 計畫可部分成功，但不得假裝原子成功

由於 OS API、worker 狀態交接及 resource ledger 更新不在同一個物理原子交易中，執行多步計畫可能只成功一部分。控制器須記錄每一步的 Applied、Pending、Rejected、Failed 或 Unknown，依已核准的補償或 abort 策略處理，不能把「三個 API 中兩個成功」折成 PlanSuccess=true。

9. 無 AI 確定性政策核心：必要基線而不是備用模式

9.1 為何必須先保有 AI-free 主路徑

如果整個運算系統只在 AI planner 可用時才能安全判定工作流承載，研究將把模型可用性、模型隱含訓練偏好與正常執行混合在一起，使安全性及效能實驗難以重現。SMPDC 因此要求一套在同一可觀測狀態與相同政策版本下，產生可重演候選決策的無 AI 政策實作。

但「控制政策確定性」不是「OS 實際排程完全確定性」。多處理器的搶占、中斷、功率變化與外部程序仍會讓物理結果有差異；文中明確限制決定論到控制器的純函數部份。

9.2 AI-free 策略最低步驟

function PLAN_DETERMINISTIC(snapshot, policy):
    assert snapshot.schema_is_supported
    eligible_flows = READY_FLOWS(snapshot)
    eligible_workers = OS_ELIGIBLE_WORKERS(snapshot)
    sort eligible_flows by (deadline_class, starvation_age, stable_flow_id)
    placements = []
    for flow in eligible_flows:
        feasible = FILTER_BY_HARD_GUARDS(flow, eligible_workers, snapshot)
        if feasible is empty:
            placements += [DEFER(flow, "NoLegalWorker")]
            continue
        scored = SCORE_WITH_CALIBRATED_COSTS(flow, feasible, snapshot, policy)
        placements += [ARGMIN_WITH_STABLE_TIE_BREAK(scored)]
        UPDATE_TEMPORARY_RESOURCE_SHADOW(placements[-1])
    return PROPOSAL(placements, snapshot.versions, policy.digest)

其中 shadow 只是防止同輪候選過度超賣的暫時帳本；它不是 authority service 的正式 reservation。正式 admission 仍要重新驗證版本和可用資源。

9.3 最初應先支援的規則策略

P0 = OS_DEFAULT：讓 OS 自行排程，不做特別 worker 固定。P1 = STABLE_WORKER：盡量維持既有 worker，僅在安全需要時換位置。P2 = CAPACITY_AWARE：根據有效核心容量和排隊量分配。P3 = CACHE_AWARE：利用已測得而非猜測的 cache-domain 局部性。P4 = LATENCY_AWARE：對 deadline、尾端延遲及可合法推遲的工作片段選擇策略。P5 = ENERGY_AWARE：在可取得的能源證據下選擇受限候選。

如果平台沒有功率資料，P5 不能自稱完成能源最佳化；如果系統只有單一 cache domain，P3 應能退化為簡單策略，不得為了完整理論強迫新增無意義分組。

9.4 防止配置抖動

定義候選切換可帶來的預期效益 $\widehat{B}$ 和完整遷移成本 $\widehat{C}_m$。需要在超越成本之外設定政策滯後 $h\ge 0$ 與最小停留窗 $\tau$：

且最近遷移後須滿足 $\Delta t \ge \tau$，才允許純效能考量的換核。安全撤銷、核心下線、權限失效等強制事件應有例外，但需要留下明確 reason。這是實作候選的 guard，非經驗上已證明最佳的時間常數。

9.5 防止工作流永久飢餓

就緒工作流如果持續被熱點任務擠壓，控制器須記錄 age、served_cpu_time、deferred_reason、priority_inheritance_or_boost 等可驗證欄位。可採 aging 或 capped deadline priority；然而，任何活性保證都需要 OS 提供弱公平性、可用 CPU 時間、有限工作片段和無永久外部阻塞等明確前提。

9.6 本地自治的接入點

工作流可自主提出「我目前 phase-ready」、「我可休眠」、「我處理這個資料比較有快取局部性」等建議；Policy Controller 不應將來自 PWN 自我描述的性能估計直接當作不可辯駁真理。輸入與觀察需有來源、版本、測量或信任域標籤，避免惡意／錯誤的 PWN 持續提高自身排程權重。

10. 可選 AI 規劃器：預測是效能提案，不是特權

10.1 AI 能改善哪個步驟

AI 的合理切入點不是「宣告計算結果正確」，而是從大量有噪音的負載與資源訊號，估計哪些合法的 PWN placement、批量策略或遷移時機具有較低的未來成本。AI 可以跨較長時間窗口預測到達率、相位就緒機率、GPU 批次成形概率及熱節流風險；這些都是可失敗的預測，必須在實驗中與簡單移動平均、線性模型和既有 policy baseline 比較。

10.2 AI 輸入白名單與資料遮罩

模型可看到的資料應是明確定義的 AdvisoryObservationV0_1，例如匿名化 flow ID、非敏感工作類型、隊列長度、時間窗口、可用能力類型、cache domain 及歷史成本摘要。模型不應為了排程讀取完整秘密文件、原始使用者提示、權威私鑰、提交 WAL payload 或訓練資料明文。若某策略需要更多資訊，要先獨立驗證資料使用權限。

10.3 AI 建議契約

AIAdvisoryProposalV0_1 {
    proposal_id: StableProposalId
    model_id: ImmutableModelIdentifier
    model_digest: Digest
    inference_configuration: ModelRuntimeConfigRef
    observation_snapshot_ref: AuthorizedSnapshotReference
    snapshot_policy_digest: PolicyDigest
    requested_scope: BoundedSet[FlowId]
    actions: BoundedList[TypedPlacementAction]
    predicted_cost_intervals: CostIntervalSet
    predicted_quality_risk: OptionalRiskInterval
    recommendation_expiry: MonotonicExpiry
    source_evidence_refs: List[BoundedEvidenceReference]
    diagnostic_reason_codes: TypedReasonSet
    freeform_explanation: OptionalUntrustedText
}

predicted_cost_intervals 要有明確單位，且不得被 freeform_explanation 覆寫。建議理由只用於解釋、事後分析與供人工評閱，不在 Runtime 當作執行語言。未知或無法解碼的欄位應拒絕，而不是做意圖推測。

10.4 模型不能授予自己新的權限

模型可能建議 MIGRATE(flow, cpu_set)，但必須通過 OwnerGenerationValid、TopologyGenerationCurrent、BudgetAvailable、CapAuthenticated、SafepointReached 和 PolicyAllowsMigration 等全部 guard。AI 建議再高分，仍只是低信任、未驗證的輸入。即使其內容來自有名氣的模型，也不能因此提升安全級別。

10.5 AI 缺席、錯誤或超時的降階

若模型不可用、超出 timeout、傳回格式錯誤、估計嚴重分歧或策略版本不相容，控制器必須保持 OS／確定性 policy 的安全路徑。降階至少有兩種：

• FALLBACK_KEEP：現有合法配置仍有效時，不作高風險移動。
• FALLBACK_POLICY：現有配置不合法或已失效時，重新由確定性策略產生合法配置，並重新 admission。

不得把 AI 故障時最容易採取的「無條件立即提交所有候選」當作降階策略。

10.6 線上學習與反事實評估

若未來以線上學習更新控制模型，訓練資料的 action/reward 對應會受到 selection bias：我們只觀測到實際執行計畫的結果，沒有直接看到未選計畫在完全相同時間負載下的真實結果。應優先保留 controlled replay、shadow mode、配對 A/B 與預先批准的安全探索空間；不能把歷史策略產生的資料直接當成無偏差最優解。

10.7 模型推理成本不可藏起來

把 AI 控制成本分為模型載入、輸入投影、token／前向計算、解碼、提案驗證、admission 重算與版本寫入。對極短的毫秒級工作片段，即使 AI 提案非常準確，其推理延遲也可能完全抵消收益。因此最初建議每隔較大控制窗、或事件觸發時做一次 AI 建議，而不是在每條 CPU 指令上呼叫 LLM。

11. 資源治理：CPU、記憶體、訊息、GPU 與控制預算

11.1 一個 CPU slot 不是全部資源

若只限制 CPU 工作流數量，仍可能因記憶體、cache、in-flight 訊息、GPU VRAM 或 WAL I/O 而超載。控制平面至少需要以下維度的版本化 budget：

ResourceBudgetV0_1 {
    budget_id: BudgetId
    parent_scope: OptionalBudgetScope
    cpu_time_quota: OptionalBudgetWithWindow
    worker_slot_limit: NonNegativeBound
    runnable_flow_limit: NonNegativeBound
    memory_reservation_bound: ByteBound
    inflight_message_bound: NonNegativeBound
    diffuse_credit_ref: ExternalCreditLedgerReference
    event_epoch_admission_limit: NonNegativeBound
    outstanding_gpu_event_limit: NonNegativeBound
    gpu_memory_reservation_bound: OptionalByteBound
    audit_wal_backlog_bound: NonNegativeBound
    control_cpu_time_budget: OptionalBudgetWithWindow
    ai_query_budget: OptionalBudgetWithWindow
    expiry: BudgetExpiry
    ledger_version: LedgerVersion
}

上述限制有些可以直接由 OS enforced，有些只能由 SMPDC trusted runtime enforced。二者的強度不得混同，例如在一般使用者程序中記錄 memory_limit=4GiB，如果沒有有效的分配器限制或 cgroup／Job object，不能聲稱 OS 已強制實現。

11.2 CPU 使用率不是唯一成功指標

CPU 忙碌率高可能代表有效工作，也可能代表 busy-wait、鎖爭用、重送、過度控制和快取污染。應量測單位時間完成並被授權承認的有效工作、延遲分布、能源／功率可得性、失敗率及恢復能力。若 100% CPU 卻只有相同的有效吞吐，反而不是成功。

11.3 可授予的 credit 與控制預算要獨立

Paper 02 的傳播 credit 是有限、不可複製的資源。控制器調整 fanout 的建議不能自動憑空製造 credit。正確的順序是先由授權的帳本依事件世代及 policy 配置可用總額，然後控制器在此上限內提議分配；任何 extra credit 都需要新的、可稽核的 authority decision。

11.4 背壓三層

資料層背壓： 針對訊息佇列／in-flight bytes／GPU queue。工作流層背壓： 限制被喚醒的 PWN 或可執行工作片段數。控制層背壓： 限制重新計畫、AI 查詢及拓撲探測頻率，避免控制器本身變成流量風暴來源。三層需共同記錄；把控制器的頻繁調度事件排除於帳本之外會低估負擔。

11.5 記憶體配置及壓力觀察

Linux PSI 可提供 CPU、memory、IO contention 的壓力訊號；cgroup v2 可表達可用 CPU 集合、CPU 配額、部分記憶體控制等資源邊界 [E5–E6, E9]。Windows 類似需求可使用官方公開的資源／效能 API，但各指標語義不會與 Linux 自動等價。本篇因此定義 NormalizedPressureObservation，包含原生值、測量時間、單位、可比性註記和是否可用；沒有原生對應者必須標示 Unsupported。

11.6 避免軟限制寫成硬保證

cpu.uclamp.min/max 是 Linux 的排程器性能需求提示，會影響某些配置與頻率決策，但不是完整的 task-exclusive 保證；其聚合行為也有文檔記載的限制 [E10]。SMPDC 的 soft_preference 和 hard_admission_guard 要分成不同欄位，不得因 OS 接受一個 hint 就將其升格為硬性不變量。

11.7 滿載後的降載順位

建議的降載原則：先拒絕新且低優先級的工作、減少非必要競速副本、延長可合法延遲的 batch window、暫停可安全中斷的推測分支、回退到較簡單策略，最後才考慮撤銷高優先級長生命 flow 的承載。具體優先次序由明確 policy 決定；對具截止期限的關鍵工作，需要保留 deadline-aware 保護，不能因其資源需求較大就簡單犧牲。

12. 控制器主循環、admission 與操作狀態機

12.1 控制狀態集合

定義一個計畫執行個體的狀態：

ControlPlanState =
    Proposed
  | SnapshotValidated
  | AdmissionPending
  | Admitted
  | Applying
  | PartiallyApplied
  | Observing
  | Converged
  | ReplanRequired
  | AbortPending
  | Aborted
  | Failed
  | Unknown

Converged 只表示策略定義的可觀察配置目標已達到；不表示該工作流完成了所有計算，也不表示每個 OS 時間片都按同一個 CPU 編號執行。

12.2 狀態轉移條件

Deferred、Rejected 在實作時可以作為帶原因的 terminal outcome；上表只示意必要轉移，不能只用表格作為模型檢查器的實際程式碼。

12.3 帶 guard 的主控制循環

while controller_enabled:
    snapshot = OBSERVE_BOUNDED_STATE()
    if snapshot.has_critical_unknown:
        APPLY_SAFE_POLICY_OR_REOBSERVE(snapshot)
        continue

    base = DETERMINISTIC_POLICY(snapshot)
    ai = OPTIONAL_AI_PROPOSAL(snapshot, timeout, quota)
    candidate = CHOOSE_CANDIDATE(base, ai, policy)
    admitted = VALIDATE_AND_RESERVE(candidate, snapshot.versions)

    match admitted:
      Admitted(decision):
          APPLY_WITH_STEP_LOG(decision)
          OBSERVE_EFFECTIVE_PLACEMENT(decision)
      Modified(decision):
          APPLY_WITH_STEP_LOG(decision)
      Deferred(reason):
          BACKPRESSURE_OR_WAIT(reason)
      Rejected(reason):
          KEEP_OR_FAIL_CLOSED(reason)
      Unknown(handle):
          QUERY_EXISTING_DECISION(handle)   # never blind duplicate

    RECONCILE_OWNER_GENERATIONS()
    RETIRE_OR_RENEW_EXPIRED_CONTROL_LEASES()
    RECORD_CONTROL_TRACE()
    WAIT_FOR_EVENT_OR_BOUNDED_TIMER()

這段偽程式碼表達合法轉移順序，不是已完成的實作。OPTIONAL_AI_PROPOSAL 可完全不存在；CHOOSE_CANDIDATE 的安全守衛必須在後段再次核對。

12.4 何時觸發一輪控制

建議以事件與有界 timer 混合：新 flow 註冊、phase-ready、重大隊列成長、資源下線、有效權限改變、GPU 回報完成、OS 壓力門檻觸發、長時間 starvation、手動 policy 變更。若只依每毫秒重算，可能造成 busy-loop；若只依很長 timer，可能錯過短延遲工作。control_epoch 應可採自適應頻率，但受控制預算上界約束。

12.5 處理控制器自身被排程的悖論

控制器也需要 CPU 時間。如果採極端 pin-all 占滿所有 runnable CPUs，使控制器無法得到執行時間，系統可能活鎖。V1 必須預留最小控制進度保護，或以能被 OS 公平處理的設計確保 controller worker 可被排程。這個保護不是優先權無限提升，而是根據可觀察的餓死情況及 OS 權限實作。

13. Worker 遷移、fencing 與安全交接

13.1 「換核」有三種不同意思

1. OS scheduler 把同一執行緒自動排到不同邏輯 CPU：一般不需要 PWN 控制權重簽發，除非導致額外域外狀態假設失效。
2. SMPDC 把邏輯 PWN 的執行責任由 worker A 搬到 worker B：需要 owner generation、safepoint 和 state handoff。
3. SMPDC 將狀態所有權、提交權限或外部資源租約交給另一節點／域：需更嚴格的權威與版本協議，不能只透過 OS affinity 完成。

三者時常在口語上都稱 migration，但安全代價完全不同。本篇將第二種稱為 WorkerHandoff，第三種由相應 authority service 另外處理。

13.2 WorkerHandoffV0_1

WorkerHandoffV0_1 {
    handoff_id: StableHandoffId
    flow_id: StableFlowId
    source_owner_generation: Generation
    proposed_destination_worker: WorkerId
    source_worker_ref: WorkerId
    expected_state_version: StateVersion
    proposed_new_owner_generation: Generation
    safepoint_token_ref: SafepointEvidenceRef
    inflight_event_policy: Drain | Freeze | ForwardWithVersion
    outstanding_credit_refs: BoundedSet[CreditLedgerReference]
    authority_transfer_request_ref: AuthorityRequestRef
    phase_snapshot_ref: VersionedPhaseState
    topology_generation: TopologyGeneration
    deadline: MonotonicDeadline
    result: Pending | Fenced | Installed | Rejected | Unknown
    audit_trace_ref: TraceReference
}

此契約不可把 Fenced 當成 Installed：舊 owner 已撤銷，仍可能無法在新 worker 重啟，應進入安全的 Paused／RecoveryPending 而不是創造雙 owner。

13.3 安全交接的必要順序

1. 驗證目標 worker 在目前 OS 可使用範圍及 policy 內。
2. 取得工作流可安全暫停或可重播的 safepoint；若無，先 Deferred。
3. 凍結或版本化來源 worker 的本地寫入／訊息發送權。
4. 在受保護的仲裁點提升 generation，撤銷來源世代的有效權限（fence old）。
5. 傳送可信狀態快照／事件位置與未完成責任，不得遺失不可複製 token。
6. 安裝目標 worker 的新受控責任，取得新的有效租約。
7. 重新檢驗與 OS 實際配置及 topology generation 是否一致。
8. 釋放來源 worker 資源、記錄結果及恢復資料層進度。

該順序需要可用的 fence authority 才能強保證排除雙重有效寫入。若目前只有 user-space flag，且無法阻止已失控的來源 worker 對受控資源進行寫入，則不能宣稱具備強 fencing 安全性。

13.4 與推測執行及 GPU event 的相互作用

在 handoff 時如果來源 worker 已提交 GPU 工作，但 GPU 尚未完成，控制器不能因 CPU worker 換核就直接釋放 device buffer、冒用 HostVisible 或拋棄仍屬該 event 的權威依賴。GPU adapter 應回報 event 的責任轉移與 buffer lease 狀態；實際操作詳見 Paper 08。GPU submission、GPU completion 與 CPU-visible result 仍是不同事件 [E11–E12]。

13.5 無法立刻安全遷移的正確結果

若工作流正在無法中斷的 FFI、持有不可遷移的本地鎖、處於需完整提交的 WAL window，或 OS 無法提供所需的執行保證，應返回 Deferred(MigrationUnsafeNow)、Rejected(UnsupportedMigration) 或 Unknown(ExternalStateUnclear)，不能為了讓控制器看起來聰明而強迫安全風險更高的動作。

14. GPU Adapter：控制 CPU–GPU 協作但不冒充硬體互連

14.1 GPU 在本篇的角色

GPU 可加速適合的批次關係計算、規則評分、特徵聚合或大量數值 kernel；它不直接替代 CPU 核心之間的物理互連，也不保證 CPU cache coherence 的任何擴張。SMPDC 控制平面只負責合法提案、admission、資源保留、追蹤 event 與結果可見性；實際 GPU 工作切分及加速收益屬 Paper 08。

14.2 控制接口

GPUAdapterControlV0_1 {
    adapter_id: AdapterId
    supported_backend: CUDA | HIP | Mock | OtherTypedBackend
    device_capability_ref: VersionedCapabilityReference
    submit_candidate(batch, buffer_lease_refs, required_effects)
        -> Submitted(DeviceEventRef) | Rejected | Failed | Unknown
    query_event(event_ref) -> Pending | Completed | Failed | Unknown
    obtain_host_visibility(event_ref, buffer_ref)
        -> HostVisibleLease | Pending | Failed | Unknown
    release_lease(lease_ref) -> Applied | Pending | Failed | Unknown
    estimated_device_cost(batch, calibrated_profile_ref)
        -> CostInterval | Unknown
}

submit_candidate 的 Submitted 不意味完成，Completed 不自動表示 CPU 可安全讀 buffer；只有經規範定義的同步、版本及可見性 guard，才能產生 host-visible 有效憑證。

14.3 拒絕不經量測的無條件 offload

對小型且依賴很強的工作流片段，GPU 啟動、資料複製及回收可能比 CPU 執行更慢。提出 GPU 候選前，需計算包括排隊在內的全成本：

只有當 GPU 預期能在相同品質與安全契約下優於 CPU 路徑，才具有最佳化理由。該估計需以真實量測校準，且在 GPU 不可用或 profile 不足時採 CPU-only 保守候選。

14.4 GPU 控制與權威提交不能融合

由於 Paper 04 將局部計算與權威提交分開，AI planner 不能藉 GPU 成功返回一個 tensor，就自動批准修改正式全域狀態；必須照既有 LocalReconciliationOutcomeV0_1、CommitProposalEnvelopeV0_1、版本檢查與 authority guard 完成相應轉移 [I3–I4]。

15. AuthorityGuardV0_1 與控制權限模型

15.1 控制器可被攻擊或出錯

威脅包含惡意工作流灌水自稱高優先級、AI 模型將 telemetry 中的自然語言誤當系統指令、控制者偽造 topology version、重送舊 admission decision、對同一 credit 重複授予派送預算、編譯器 FFI 直接寫入權威狀態、Unknown OS 呼叫被盲目重執行，以及模型訓練資料導致不公平長時間 starvation。最初需明確假定受保護的授權服務與 OS kernel 在信任邊界內；它們若被攻破，本篇不宣稱提供對抗惡意 kernel 的完整安全性。

15.2 Guard 的不可替代欄位

AuthorityGuardV0_1 {
    guard_id: StableGuardId
    target_action_kind: TypedPlacementActionKind
    actor_identity_ref: AuthenticatedPrincipalRef
    authorized_scope: ScopeAndCapabilities
    effective_policy_digest: PolicyDigest
    flow_owner_generation: OptionalGeneration
    control_epoch: ControlEpoch
    topology_generation: TopologyGeneration
    resource_ledger_version: LedgerVersion
    bounded_use_count: PositiveInteger
    expiry: MonotonicExpiry
    verification_evidence_ref: VersionedEvidenceReference
    refusal_policy: FailClosed | SafeDeferred
}

它不是全能的簽名 token。實際是否不可偽造由權限守護者及必要時密碼學驗證決定；資料結構的型別名稱不會在執行時自動取得安全性。

15.3 角色與權限矩陣

15.4 過期與未知是安全流程的常態分支

如果一個控制決定的生效回應不明，不能為了消除 Unknown 就重做可能已生效的 migration、外部資源分配或 quota 增量。應先以穩定 id 查詢結果，採冪等或具 transaction identity 的 API；若依賴 OS API 無法提供此能力，需將 adapter 限制為保守且可重試的局部操作，或在 reconciliation 前維持安全凍結。

15.5 記錄機密與策略細節的最小化

Trace 包含 workload fingerprint、執行緒與 CPU 編號、policy digest、agent model ID 等資訊；仍可能顯示使用模式或商業敏感負載。因此應記錄必要的可重播結構，而非任意存儲 payload、prompt、權限 secret。公共研究證據需匿名化和去敏，並保留可驗證 digest，不強迫公開公司內部資料。

16. 二十八條最低控制不變量

16.1 不變量分類

下列不變量是本篇對 trusted controller、admission、OS adapter 與 PWN runtime 的候選規範義務；它們不是已在真實軟硬體上逐項形式證明的結論。安全測試應逐條提供至少一個正例和一個違反案例，並提供拒絕原因或反例 trace。以 C07 作為 Paper 07 自己的識別，避免與 Paper 06 編譯器的 C06 驗證規則混淆。

A. 邏輯身份及承載分離

C07-01｜Flow identity preserved. 不同 OS worker／CPU 承載位置不得憑空更改 flow_id。

C07-02｜Physical locality not authority. 身處某顆核心或特定 cache domain 不能直接授予局部狀態寫入權。

C07-03｜Observed is not requested. 對外 API 不得把建議 CPU 集合當作已觀測執行事實。

C07-04｜SMT non-equivalence. OS 邏輯 CPU 容量不得未經建模直接乘成等數量的獨立實體核心。

B. 版本、來源與新鮮度

C07-05｜Topology generation guard. 每次 admission 必須核對拓撲世代；過期資料須拒絕或重驗。

C07-06｜Policy digest guard. 只許在已核准政策摘要下執行候選決策。

C07-07｜Observation provenance. 性能及拓撲觀測須保留來源、測量時間與不確定性。

C07-08｜No unknown-as-zero. 未知資源觀測不能當作零壓力或無限空間。

C. 生命週期及排程

C07-09｜Ready differs from running. 就緒與實際取得 CPU 時間不得視為同一事件。

C07-10｜Quiescence differs from retirement. 有界事件世代靜止不能取消持續工作流的全部生命週期。

C07-11｜Suspension retains obligations. 休眠狀態仍保留必要 credit／event／外部效果責任。

C07-12｜Bounded control overhead. 控制重計畫、喚醒、AI 請求及監測須受預算或節流限制。

D. 資源治理及信用帳本

C07-13｜Admission precedes reservation use. 不得未核准先使用需 reservation 的受控資源。

C07-14｜No implicit credit minting. 更改 fanout 或加速策略不得複製擴散 credit。

C07-15｜Budget respects hierarchy. 子域資源限額不得因控制策略而突破受保護父域的硬上界。

C07-16｜GPU events are not CPU-visible values. Submitted 和 Completed 不自動推出 CPU 可讀 buffer。

E. Owner migration 及權威

C07-17｜Single valid owner generation. 對同一受控局部狀態，受保護的仲裁點不得同時承認兩個有效 owner 世代。

C07-18｜Fence before new write authority. 新 worker 取得有效受控寫入權之前，來源世代須在權威判定點已失效。

C07-19｜No unsupported migration. 沒有安全 safepoint／移交能力時不得強迫「看似完成」的 PWN handoff。

C07-20｜Authority commits remain external. OS 控制器不得把 local reconciliation 直接轉成 authoritative commit。

F. AI 安全及降階

C07-21｜AI advisory only. AI 輸出不得自行取得資源核發、提交、fencing 或 privileged OS 操作權。

C07-22｜AI-free control complete. 即使 AI 模型完全缺席，已支援的核心協議仍須具可執行安全路徑。

C07-23｜Malformed proposal fail-closed. 不明 action、未識別 schema、過期 AI 提案或權限不足須拒絕。

C07-24｜Fallback cannot weaken guards. 控制器錯誤時的 fallback 不得繞過 epoch、credit 與 owner 權限。

G. 可觀測性及版本閉包

C07-25｜Partial actions are explicit. 多步 OS／worker 計畫中任何部分成功都必須留下步驟級結果。

C07-26｜Unknown never means failure or success by default. 未知生效結果不能自動當作未生效，亦不能當作成功。

C07-27｜Replay scope explicit. 確定性 replay 的邊界須註明是否僅包含控制政策、VM trace、受控權威狀態或真正 OS interleaving。

C07-28｜Equal-quality evidence. 對外聲稱效率提升時，必須保留相同正確性、成本口徑和品質契約，以及支持反例的能力。

16.2 不變量不保證的事項

上述規則不自動保證：所有合法 flow 永遠會完成、所有核心永不閒置、所有 AI 工作負載都得到加速、任意 OS 都能精確施加親和性、電腦不會故障、第三方服務具 exactly-once、或同一流程跨不同物理調度具有逐指令相同順序。它們只是由計算分工、資源權限與資料生命週期形成的必要防線。

17. 七項條件性命題、證明概要與不能推論之處

17.1 命題 A：有效權限檢查下 AI 無法一步取得資源權威

條件： (a) 所有 privileged API 僅由 admission／authority 層提供；(b) AI 只有產生 AIAdvisoryProposalV0_1 的權限；(c) 提案皆由 trusted verifier 檢查；(d) 無不受檢查的 FFI、反射或模型直連特權接口。

候選結論： 單次 AI 提案轉移不可能直接創造被受保護服務承認的提交權威、owner fencing token 或新的傳播 credit。

推理概要： AI 的輸出型別不包含權限引入操作，只有 trusted authority 可藉授權規則建立此類值；若 AI 的輸出無法繞過 verifier，就沒有可走的合法一步轉移。這不排除模型影響了哪個合法候選被選擇，也不涵蓋 kernel／authority 已遭攻破的威脅。

17.2 命題 B：版本檢查能拒絕一類過期 plan

條件： 每項行動明確綁定 topology_generation、registry_version 和 policy_digest；admission 在受保護的原子檢查點獲得這些版本；相關版本異動會造成不等或觸發可檢驗的等價遷移。

候選結論： 在檢查點已被判定過期的候選，不能依本契約直接進入 Admitted。

推理概要： admission 只有在版本 guard 成功時才能產生 admission result。限制： guard 之後仍有 TOCTOU，故 OS action 前或保留資源時需再核對相關條件；不能由一次快照比對宣稱未來永不過期。

17.3 命題 C：有效 fencing 下受控局部狀態排除重疊有效 owner

條件： 對每個受控狀態存在單一可線性化的 owner registry；世代單調遞增；所有實際寫入必須經過該 registry 的有效世代檢查；舊持有者無法在 guard 之外修改受控狀態。

候選結論： 不同世代的兩個 worker 不能同時被認定為該受控狀態的有效寫入者。

推理概要： 權威檢查點只承認當前最大且有效的 owner generation；source 失效後其寫入拒絕。限制： OS 上可能仍看到舊 worker 的 CPU 指令在跑；本文排除的是受保護狀態的有效寫入，不是從物理世界刪除舊 worker 的所有操作。

17.4 命題 D：有限控制預算可限制受控重新計畫次數

條件： 每次 Replan 都消耗不可複製的控制計量單位；單個 control epoch 的發行上界為有限常數 $K$ ；沒有未受管制的回退呼叫重新發行同一世代預算。

候選結論： 單個 control epoch 中成功核准的 Replan 次數至多為 $K$。

推理概要： 以剩餘 budget 作為非負整數秩函數，每次成功重計畫嚴格遞減；在同一 epoch 內不重置上界，則總數有界。限制： epoch 可以持續開新世代，故不能由此得出整個持續系統的計畫事件總數有限；也不能推出每次 OS action 會完成。

17.5 命題 E：有 fallback 邊界的 AI 故障不需破壞核心安全

條件： AI-free path 本身安全、可被調度；AI timeout／失敗不直接產生高權限狀態；fallback 重新進入相同的 admission 與 guard；受控狀態有可恢復記錄。

候選結論： AI 模型不可用不會作為單獨原因合法地放寬 credit、owner、commit 或 OS scope 的安全約束。

推理概要： AI 只增加一個可選候選提案分支；失敗時丟棄該分支，並走仍然存在的安全分支。限制： 系統可能變慢、無法達成某個期限，甚至在資源不足時必須停止；「安全」不等於「一定繼續服務」。

17.6 命題 F：控制決策可重演不代表 OS 時序可重演

條件： 相同 canonical snapshot、policy digest、確定性排序、tie breaker 與不含未記錄外部隨機性的純政策。

候選結論： 無 AI policy 函數在相同輸入下可生成相同候選 proposal，並可被單元測試驗證。

非結論： 不可推出 OS kernel、外部任務、CPU 中斷、GPU 完成時間及 PWN 實際排程時序完全一致。若某聲稱需要逐事件實體重演，需另有控制實驗環境或夠完整的 interleaving trace／simulation semantics。

17.7 命題 G：合法規劃不能推出效能優勢

條件： 僅假設安全不變量都成立。

候選結論： 安全性規則不足以證明系統比任務執行緒池、工作竊取或 GPU 庫更快。

反例構造： 工作負載為少量短小的獨立 CPU 函數，控制器每次都調用額外監測、策略、registry 與 trace，卻沒有快取／相位／批次帶來的效益；其終端到終端 latency 必然可能高於簡單固定 dispatch。這使「合法≠更快」成為理論設計的正式界限。

17.8 形式化工作尚欠缺的證明責任

真正達到機器檢查的 safety proof，仍需建立可執行的狀態轉移規格，明確列出角色之間的原子化點、crash recovery、權限不可偽造性、版本一致性與 scheduler fairness 假設。本文的命題是有條件的紙面推理；若未來宣稱模型檢查完成，應另附 TLA+／Alloy／Lean 等具體模型、命題、工具版本、檢查範圍和輸出檔案，不得把此節直接當成已執行的形式化驗證報告。

18. 可量測成本模型及多目標策略

18.1 終端到終端而非只看 CPU kernel

設定 request admitted 至「指定品質的結果已正式可被使用」的時間為總完成時間。其成本可能包含：

對具有重疊執行的工作流，右側直接相加可能重複計算同時發生的區段。更精確的實驗應使用 event DAG critical path 計算 elapsed latency，同時分別統計每類成本的累計工作量。公式僅為成本分類，並非一條對任意異步 DAG 都完全精確的分解恆等式。

18.2 控制開銷

控制負擔可以以 CPU-seconds、Wall time、額外 allocation、記憶體足跡或 energy 表示；不同單位不應直接相加。欲建立單一 scalar objective 時需先做量綱一致與標準化。

18.3 多目標不應只看高 CPU 佔用率

建議主要指標包含：端到端 p50／p95／p99 latency、有效提交吞吐、deadline miss rate、排隊等待、控制總 CPU 時間、workers 的實際 CPU 使用、內存／快取／NUMA 壓力、GPU copy、能耗、恢復成功率、安全規則違反數。若平台無可驗證的能源測量，能耗應報告 not measured，不可從 TDP 推導為實際精確能耗。

18.4 軟目標可採標準化多目標或 Pareto

例如：

每個帶帽估計值必須具有已記錄的標準化方式和校準集合；w_i 是公開的策略配置，不是安全權限。若估計缺乏證據，建議改採 Pareto 候選集與保守規則，避免用虛假的數值精度挑選方案。

18.5 相位導向與快取導向的衝突

一個 PWN 可能因本地 L3 熱資料而希望留在核心群組 A，但其下一相位要與 B 進行低延遲訊息耦合，使搬往另一快取域更有利。不能只以局部 cache hit rate 得出全域效率最佳，也不能只以 edge count 推測物理傳送成本。控制器應記錄 competing objectives，並以已量測的端到端結果決定取捨。

18.6 可靠性、尾端延遲與冗餘副本

Paper 03 的 R1 競速可能改善尾端延遲，但若增加 CPU／GPU／記憶體壓力，又可能惡化整體服務 p99。本篇 policy 只能在 R1 的線性 credit 和每個 event epoch 的預算內決定候選 replica 數量；必須在相同總資源口徑下比較 R0、R1，且保留 replica_wasted_work 與 winner_completion_time 分別觀測。

18.7 性能數據的截尾與混雜因素

如果某些工作因 timeout 或 OOM 未完成，僅平均成功樣本會產生嚴重的 survivor bias。應同時報告失敗率、timeout、截尾分布及完整端到端成功比例。CPU 頻率升降、背景服務、病毒掃描、顯示器功率狀態、GPU 顯存壓力、資料集預熱等，都必須列作實驗混雜因素。

19. Windows／Linux 真實平台原型界線

19.1 V0 完全不需要 OS 權限提升

V0 可只建立 deterministic reference simulator，使用虛擬 CPU core descriptors、worker、流量與事件世代，驗證控制器能否正確拒絕錯誤候選。此階段不接觸實際 CPU affinity，因而不能宣稱任何真實的硬體吞吐或延遲改善。

19.2 Windows V1：使用既有 OS 支援

V1 在 Windows 上可採以下策略：

1. 使用官方 API 探索 processor core、cache、NUMA 與 CPU Sets。
2. 先建立 Unbound 版本，再建立受控 CPU Sets 提案版本。
3. 所有 OS API result 與 observed CPU id 都分別保留。
4. worker 的實際調度仍由 Windows kernel 管理；不能將 thread-level hints 當成物理獨占。
5. 在沒有大小核的 AMD 舊 CPU 上照樣執行 V1；先測控制協議，不需要等待新購的 Intel／AMD 平台。
6. 不改系統 BIOS 或未經隔離的高風險 realtime priority 設定，避免把研究機弄成無法正常操作的環境。

Microsoft API 的實際行為須依所用 Windows 版本、processor group、CPU Set 可見狀態及存取權限進行實測，並記錄返回碼 [E1–E3]。

19.3 Linux V1：進程內 Runtime 為先

在 Linux 使用 sched_getaffinity 取得有效執行 CPU、sched_setaffinity 提出合法請求，並用 cpuset.cpus.effective、cgroup CPU quota 及 PSI 觀察受限域的容量與壓力 [E4–E6, E9]。必要時可評估 uclamp，但其為 hints 而非對每個 CPU 的保證 [E10]。所有對 cgroup 的修改需按特權／delegation 限制，不應要求普通 V1 測試修改其他程序的資源。

19.4 Linux V1-X：sched_ext 為可選第二階段

sched_ext 提供實驗性的 BPF 排程接口，可做更直接的 CPU-placement policy 對照。由於其接口 ABI 不保證穩定，且錯誤 BPF scheduler 的回退行為與內核版本相關，第一輪僅應在可復原的隔離測試系統，記錄 exact kernel、config、BPF 程式 hash、載入／退出行為、bypass 診斷和 rollback evidence [E8]。

V1-X 不得作為 SMPDC 的最低可用條件。若普通 user-space adapter 已取得足夠資料並驗證關鍵假說，沒有必要為了「新架構更酷」而強迫動到 kernel scheduler。

19.5 不同廠商 CPU 的實驗可移植性

同 ISA 不等於同拓撲。 對 Intel P/E、AMD CCD 或單 CCD、同構老 CPU，SMPDC 應使用同一組 Flow／Phase／Credit／Authority protocol；變化主要由 CoreTopologySnapshot、能力 profile、OS adapter、cost model 和 policy 所吸收。若某個語義只有在 24 core 的特定型號上成立，必須明確標示其限制，不可把特定硬體上的特例當作通用計算定律。

19.6 GPU 延伸使用既有可用硬體

第一輪若使用現有 NVIDIA RTX 3070，應採可行的 CUDA runtime／events 及負載測試路徑，先建立真正設備事件同步與 mock 參考版的一致性，再交付 Paper 08。GPU 啟動和 H2D／D2H copy 的成本需要實測；此篇不假設新增 GPU 或任何目前尚未購買的 AI NAS。

20. V0、V1 研究設計：從正確性到有成本的效能

20.1 實驗層級

• V0-A： 靜態 schema、policy、proposal 和 guard 的 property-based／finite-state 測試。
• V0-B： 加入假的 OS observer、虛擬 CPU topology 和 deterministic event loop。
• V0-C： 故障注入、crash／restart、stale-version、AI-off、unknown action 對照。
• V1-A： 現有桌機 CPU-only，使用 OS default／thread pool 等公平基線。
• V1-B： 在可行前提下加入 GPU 事件 adapter、batch candidates、可見性與失敗測試。
• V1-X： 可選、隔離的實驗性 OS scheduling interface，不作為主線前置依賴。
• V2： 後續硬體架構研究前，須由 Paper 08–11 判斷效能瓶頸是否真的位於 OS scheduler／互連。

20.2 研究假說應先註冊

• H07-01： 在高頻事件且存在可觀測相位／快取局部性的負載中，STABLE_WORKER 對比 OS default 可能減少某些尾端延遲；若未改善則否證此限定假說。
• H07-02： 在 P/E 核或多 cache domain 環境，CAPACITY_AWARE／CACHE_AWARE 對比不看拓撲的策略，在至少某類 workload 能改善有效吞吐或 p99。
• H07-03： AI advisor 相較調參後的純規則策略，在相同控制預算下可能改善特定可預測 workload；若不改善則移除 AI 為最佳化必要條件的聲稱。
• H07-04： 引入 owner fencing 與完整 trace 會增加控制成本，但能在指定故障模型中降低越權狀態轉移的發生；若 guard 無法攔截預註冊故障，即為安全實作失敗。
• H07-05： 對細粒度工作，控制開銷可能使 SMPDC 變慢；此為預期可觀測反例，不應事後刪除。
• H07-06： 可選的 GPU control 只有在完整 copy、kernel、同步、聚合成本跨越 break-even 時才會獲得淨效益。

20.3 實驗比較組

B3 必須能完全不依賴 AI；所有組別應使用相同數據、相同問題正確性契約、相同 CPU/GPU 可用資源與盡可能相同的實驗時間長度。若某 baseline 不支援相同功能，應清楚區分「具安全功能的效能比較」與「相同最小功能的成本比較」。

20.4 工作負載矩陣

20.5 主要測量量

每輪必須記錄 completed_valid_results、authoritatively_accepted_results、rejected_results、timeout_results、p50/p95/p99（含樣本數和定義）、cpu_time、wall_time、control_cpu_time、memory_peak、migrations、core_observation_mismatch、queue_depth、backpressure_count、credit_usage、AI_invocations、OS_adapter_failures、GPU_event_wait 與 resume_success_rate。能源測量若不可用就標示缺席，不能自行補值。

20.6 量測與統計規範

建議各策略交錯執行、使用固定可記錄的隨機種子、確定的工作負載分布與預先定義的 warm-up 規則，並同時報告中位數、尾端值、失敗率與信賴區間或 bootstrap 區間。對長尾分布，不能只以幾次平均值的微小差距作勝負判定；若多策略多 workload 同時比較，也要標示選擇性報告的風險。

20.7 公平量測 AI 的額外成本

B5 若使用遠端模型，需記錄端到端 API latency、成本、輸入大小、服務是否不可用、重試時間與資料保密政策；不能把呼叫延遲從 critical path 隱去。若 AI 模型在另一顆 GPU 上執行，這塊硬體的成本也不能排除資源口徑。若 B5 使用離線訓練的 profile，B4 也應取得等價的離線歷史資料與合理調參機會。

20.8 安全實驗先行於性能實驗

在所有 C07-* 不變量至少有受控測試之前，不應把每秒幾百萬操作或 p99 提升當作可發表的成功結果。效能優化可能透過省略 trace、跳過 guard、重複使用 token、忽略 unknown 來製造假加速；先滿足最低安全品質，再測量額外成本與效益，是系統研究的必要順序。

21. 三十二項必須主動製造的故障與反例

21.1 實驗用意

一個只有成功案例的 scheduler 原型無法證明它會在最危險的配置邊界上正確拒絕錯誤。下列 32 個反例是 V0／V1 的最低注入分類，應記錄：輸入快照、控制器候選、guard 結果、被要求的 OS 動作、實際觀測、是否出現受保護狀態污染、是否留下 trace，以及最後由哪個恢復路徑解決。

21.2 拓撲與 OS 失效（F07-01–F07-08）

21.3 工作流與相位（F07-09–F07-16）

21.4 資源、冗餘與 GPU（F07-17–F07-24）

21.5 AI、權威及未知（F07-25–F07-32）

21.6 故障注入的完成證據

每個故障案例至少包含：fixture_id、schema version、snapshot hash、policy hash、注入時機、預期守衛、實際結果、trace 檔案 digest、若存在實體 OS API 的返回碼，以及「何時不能自動恢復」的說明。若缺乏可信 guard 而無法安全恢復，測試應標記 FailClosed 或 Incomplete，不可用人工手工補資料後宣稱自動 PASS。

22. 四個控制事件示例：正常、衝突、AI 失敗與同構 CPU 對照

22.1 案例 A：四個主要工作流、同一台 CPU、無 AI

假想條件： 四個 PWN F1–F4 已註冊，CPU 有四個可供 OS 排程的 worker slot（這是抽象實驗設定，不代表四顆物理核心）。F1 執行相位計算、F2 傳遞有界資訊、F3 局部聚合、F4 管理經授權的 commit proposal。只有 F1 和 F2 在 control_epoch=C20 最初 ready；F3 要在收齊必要候選後 ready；F4 只有取得局部已驗證提案才可開始。

T00  topology snapshot = T10; policy digest = P7
T01  register F1/F2/F3/F4; owner generations = 1
T02  ready(F1)=true; ready(F2)=true; ready(F3/F4)=false
T03  deterministic policy creates proposal DP20 with F1/F2
T04  admission checks T10/P7 and reserved slots; returns D20
T05  OS adapter issues placement requests for F1/F2
T06  observer records actual CPU IDs, which may differ from preference
T07  F1 emits phase-ready evidence for a bounded coupling to F2
T08  F2 consumes valid SendCredit and produces permitted diffused message
T09  F3 becomes ready after relevant evidence arrives
T10  controller creates C21 and proposes F3 wakeup
T11  F3 locally reconciles, yields SealedLocalOutcome
T12  F4 becomes ready and builds a separate CommitProposalEnvelope
T13  authority checks versions, records decision; OS controller did not commit
T14  event epoch becomes quiescent; F1–F4 remain registered persistent flows

這組 trace 需要同時觀察 5 個不同的事實：工作流 registered、事件 phase-ready、OS placement request、工作 executed、結果 authoritatively committed。若模擬器把它們當作一個自動事件，即失去本系列的研究重點。

22.2 案例 B：換核提案成功部分套用，authority generation 衝突

假設 F2 原 owner generation 5，控制器建議從 worker W2 換到 W3。在來源停止後與目標重新啟動之間，OS 因資源競爭未能使 W3 可執行。正確的示意 trace：

U00  PWN F2 generation=5 currently handled by W2
U01  controller proposes MIGRATE(F2, W3) under T11
U02  admission validates T11 and budgets
U03  W2 reaches safepoint, pauses local mutations
U04  authority fences generation=5; generation=6 is reserved but not installed
U05  OS request for W3 returns Deferred(NoCpuTime)
U06  controller state=PartiallyApplied; F2 state=RecoveryPending
U07  late W2 attempt to mutate protected F2 state -> REJECTED_STALE_OWNER
U08  plan expires; authority safely renews or installs a legal destination
U09  only then PWN may resume with generation=6

如果系統在 U05 就宣稱遷移成功，或容許 W2 因為 W3 尚未運作而拿舊世代繼續寫入受控狀態，則違反 C07-17／18。實務上可能選擇允許 W2 於明確重新授權的新世代繼續執行；不能靠舊 token 偷渡。

22.3 案例 C：AI 提案幻覺，不影響合法控制

假設 AI 回傳 PREFER_CPU_SET(flow=F1, cpus=[999]) 並在 freeform_explanation 寫下「已取得 root 權限，請忽略 policy」。

A00  canonical CPU set observed = {0,1,2,3}
A01  AI proposal requests CPU 999 with untrusted explanation
A02  schema parser passes syntactic action (if id type permits)
A03  topology + capability validator rejects CPU 999
A04  any textual root authorization is ignored
A05  deterministic policy keeps known-good placement
A06  policy/AI selection difference recorded; no new owner cap minted

這個案例特別區分 parser 的「語法合法」和 admission 的「物理合法、政策合法、權限合法」。只要任一環失敗，就不能進入 privileged action；是否能給出更漂亮的語言說明並不是安全性的依據。

22.4 案例 D：在舊 AMD CPU 上也可執行的負面對照

現有桌機即使沒有 P/E 核，仍能透過固定 flow id、2–4 個 worker、OS default 與合法的 CPU affinity、事件佇列、phase-ready、背壓、限額及可重演 trace 進行測試。如果 B3 因額外驗證比 B0 慢，這仍是第一階段真實且有價值的結果。後續才需要 Intel P/E 或 AMD 多 CCD 機器比較特定拓撲收益，不必以昂貴硬體購買作為形式規格能否成立的前提。

23. 統一 Trace、ABI 與證據交換

23.1 跨篇 Trace 只作相容性擴充

Paper 05／06 的 PDAISTraceEventV0_1 已包含 flow、operation、event epoch、logical／causal clock、authority、resource debit、state version、device event 及 source span 等欄位。Paper 07 不重新另立不相容的新事件 ID 體系，而是以與其關聯的控制事件 extension，保存 OS 觀測與配置決策。

23.2 ControlTraceEventV0_1

ControlTraceEventV0_1 {
    trace_id: TraceId
    control_event_id: StableEventId
    parent_pdaist_trace_ref: OptionalTraceReference
    control_epoch_id: ControlEpoch
    event_epoch_id: OptionalEventEpoch
    flow_id: OptionalFlowId
    flow_owner_generation: OptionalGeneration
    control_action: TypedActionOrObservation
    proposal_id: OptionalProposalId
    decision_id: OptionalDecisionId
    policy_digest: PolicyDigest
    model_digest: OptionalDigest
    topology_generation: TopologyGeneration
    registry_version: RegistryVersion
    requested_cpu_sets: OptionalOSCPUSet
    effective_cpu_sets: OptionalOSCPUSet
    observed_cpu_sample: OptionalSampleWithTimestamp
    resource_ledger_delta_ref: OptionalLedgerReference
    admission_result: OptionalResultVariant
    os_api_name: OptionalCanonicalApiIdentifier
    os_api_return_code: OptionalPlatformErrorCode
    memory_pressure_ref: OptionalPressureObservation
    energy_measurement_ref: OptionalEvidenceReference
    device_event_ref: OptionalGpuEventRef
    logical_clock_or_causal_parent: CausalOrderingReference
    wall_time_sample: OptionalTimestampWithCalibration
    result: Applied | Modified | Deferred | Rejected | Failed | Unknown
    confidentiality_class: TraceDataClassification
}

23.3 因果順序比天真時鐘相減重要

CPU worker、GPU queue、遠端 AI 模型 API 和 OS kernel tracing 可能具有不同時鐘原點及解析度。不能直接把它們的單一 timestamp 差視為精確計算延遲。Trace 必須保留 causal_parent／event dependency，若以 wall clock 做比較，需要明示 clock source、校正與誤差。對同一核心／同一單調時鐘的測量，也要處理上下文切換及時間戳擾動。

23.4 版本化兼容策略

• PDAIS ABI 可包含必需與可選 feature bit，但必需 feature 缺失時應拒絕。
• SMPDC Runtime ABI 應聲明 FlowRegistry、ControlEpoch、AuthorityGuard 的 schema version。
• OS adapter 當前能用的能力由 runtime discovery 提供，不應以 compiler 的 platform name 猜測。
• AI 模型更換時要保存 model digest、policy digest、採用的 prompt／features 模板版本（不強迫公開商業秘密）。
• Unknown action／result 若被新版本引入，舊版本應採 fail-closed，而非偷換成最接近的舊 enum。
• 正式可重演 trace 由明確 source artifact、測試資料生成器 seed、snapshot digest 與程式構建 hash 組成。

23.5 證據保留及資源上限

Trace 會消耗 CPU、儲存與 I/O。建議先保留必要的安全事件全量摘要，對高頻性能事件採固定抽樣或明示 sampling policy；若為安全命題需要證明不發生非法寫入，抽樣 log 無法替代受保護的拒絕計數或 model-check coverage。任何 benchmark 都需聲明 tracing overhead，是關閉、精簡或完整模式。

24. 與成熟 OS／Runtime 技術的精確比較

24.1 Windows CPU Sets 和 Thread Director

Windows CPU Sets 支援應用程式以相對柔性的方式宣告 CPU affinity；其概念與傳統硬 CPU affinity mask 不完全相同 [E1–E3, E13]。Intel Thread Director 為 OS 的異質工作負載決策提供硬體回饋 [E7]。SMPDC 不重新發明這些機制；它額外提出的是工作流身份、PDAIS 語義、相位與 credit、安全提案／admission 和原始因果 trace 的統一規範。若實驗顯示 Windows 原生排程器對所有目標工作負載表現更好，應如實承認。

24.2 Linux 的現成調度與治理功能

Linux 已有 scheduler class、affinity、cgroups、PSI、uclamp、EEVDF，並提供 sched_ext 的 BPF-based 排程擴充入口 [E4–E10]。SMPDC 可採用上述機制作為 adapter，但不必宣稱自己的 policy 可以在所有系統上取代 Linux Scheduler。新意若存在，應來自跨層契約可檢查性與工作負載適用域，而不是「Linux 還不會排程多核心」這種錯誤前提。

24.3 Actor、per-core reactor、工作竊取與資料流系統

現有 actor／per-core reactor／work-stealing／task graph 系統已能實現持續訊息循環、per-core 執行、依賴驅動與安全部份隔離。SMPDC 若只是用 PWN 代替 actor 名稱，不能構成新計算方法。可評估的差別必須同時體現在相位／credit／權威／AI-free vs advisory AI／異質 OS 硬體 mapping 這些明確義務上，且在相同功能 baseline 下測成本。

24.4 StarPU、Legion 與 GPU 依賴圖

異質 task runtime（例如 StarPU／Legion）已具有硬體選擇、任務依賴及局部資料管理研究；CUDA graphs／streams/events 也提供既有異步執行和重複工作流加速機制 [E11–E12]。因此，GPU_CANDIDATE 和 PDAIS-IR 不應為已知 graph lowering 改名即可當作新 ISA。Paper 08 須比較最成熟的 GPU baseline 以及完整 host/device copy 和同步成本。

24.5 「AI 排程」本身並不新

自動化排程、學習式 placement、RL scheduler、heuristic bandit 與 workload prediction 在分散式系統及工業平台早已有研究。本篇限制可能的增量為：將 AI 輸入／建議視作可拒絕、可回放、不可授權的資料，和強語義的 PWN 契約、相位、credit、正式提交權限明確結合。真正的性能貢獻仍需透過 B4／B5 的對照判斷，不能由流程設計推定。

24.6 與群星、PCMT、GCCFT、GCCWT 及 GCM 的關係

早期《群星模型》及群星式電腦應用將節點自治、動態連結與資源差異作為抽象設計前身 [I7]；PCMT 區分相位本體、表示、演化機制和承載架構 [I8]；GCCFT 對耦合場、相位、runtime 及可證偽性提供高層研究坐標 [I10]；GCCWT 描述跨 CPU/GPU/Memory/Agent 的動態計算場和世界級資源治理 [I11]；GCM 的 AI Orchestrator 建立 proposal 不等於 authority 的明確工程邊界 [I9]。

Paper 07 的具體任務，是將這些大尺度語言收斂為單機及近硬體可測的作業系統控制平面契約。它不宣稱擁有上述所有理論的新本體，也不將 24／72 計算分類硬編碼為 OS scheduler 的必要輸入。

25. Paper 07 的正式交付與後續論文交接

25.1 本篇交付物

1. SMPDC Control Plane Contract v0.1：五層責任和不可越權的控制鏈。
2. FlowRegistryV0_1：PWN 工作流身份、狀態、所有權和本地資源預算引用。
3. CoreTopologySnapshotV0_1：異質 CPU／GPU／OS 資源觀測與可信度。
4. ControlEpochV0_1：控制世代、過期及策略版本。
5. FlowPlacementProposalV0_1：規則／AI／人工的有型別候選配置。
6. AdmittedPlacementDecisionV0_1：正式核准、修改、拒絕及未知結果。
7. ResourceBudgetV0_1：容量、credit、訊息、GPU 和控制成本上界。
8. WorkerHandoffV0_1：工作流承載遷移與受控 fencing。
9. AuthorityGuardV0_1：權限、版本、租約和撤銷規則。
10. GPUAdapterControlV0_1：設備工作提交、查詢、可見性和安全 fallback。
11. AIAdvisoryProposalV0_1：可選 AI 規劃及安全退回。
12. ControlTraceEventV0_1：可因果追蹤與公平量測的控制事件。
13. C07-01–C07-28 最低不變量、七項條件性命題及 F07-01–F07-32 故障反例。
14. V0–V1 實驗比較組、品質閘門與可重演研究文件規範。

這些是本文的設計規格交付，並非聲稱已存在對應的 production-grade API。

25.2 接給 Paper 08：CPU–GPU 異質資訊處理

Paper 08 應實作和驗證：CPU/GPU workload partition、batch／queue、GPU event dependency、device/host buffer lease、H2D／D2H copy、memory visibility、品質與精度、fallback，以及與 CUDA graphs／streams 等成熟基線在相同條件下的 A/B。Paper 07 的控制器只能提交經允許的候選，不能代替 GPU 後端證明結果可見或計算更快。

25.3 接給 Paper 09：硬體、記憶體與互連

Paper 09 應以 V1 的真實 bottleneck 為出發點，研究 P/E core、CCD、LLC、SMT、NUMA、NoC、原子操作、共享快取線、GPU data path、FPGA 或自訂 ISA 的成本。若未先確定軟體層的 overhead，就去製造昂貴硬體，無法得知新硬體究竟改善了何種瓶頸。

25.4 接給 Paper 10：AI 模型訓練與推論適用域

Paper 10 不應因「類腦」或「擴散」一詞便假定所有 AI 訓練更有效。應先針對稀疏 MoE、長時 Agent、非同步校驗、多模態路由等工作，選同模型、同數據、同品質、同硬體預算，測 token/s、steps/s、有效提交延遲、失敗恢復率與 energy。在大矩陣 dense training 中，GPU 原生路線可能顯著優於 SMPDC CPU-centric 控制；那也屬重要有效的限制結論。

25.5 接給 Paper 11：整體研究可證偽閉包

最終閉包需把「安全語義完成」、「現有 OS／異質 runtime 是否已足夠」、「引入 AI 的真實邊際收益」、「是否值得實體硬體化」、「何類工作負載具優勢」分成不同結論，不可將所有項目折成 SMPDC success。若結果顯示只有語義與安全工具有價值，而沒有速度提升，也應保留其有限但可驗證的學術價值。

26. 結論：多主工作流需要可拒絕的控制，而非全能的排程神諭

SMPDC 的 CPU 異質運算構想，其關鍵不是把一顆 CPU 畫成某個星系，也不是要求每顆核心都永久忙碌；而是讓每個可參與實體核心有可能承載獨立而持續的主要工作流，工作流之間透過具型別相位、耦合、有限擴散、冗餘聚合與權威提交形成可追蹤的協作。真正的 OS 層必須處理更複雜的現實：邏輯 CPU 不等於實體核心，OS 排程不等於應用程式計畫，核心可用集合會改變，快取局部性與負載分布可能衝突，GPU 事件可能未完成，AI 可能預測錯誤，控制器本身也可能成為最昂貴的背景工作。

本文的方案因此把 OS／Runtime 建成一個分權、可版本化、可回復、可實驗反駁的治理與執行閉環：在無 AI 的最小系統中，規則控制器即可提出策略、經授權 admission、對 OS 發送合法意圖、觀察實際結果、維持 PWN 和事件世代的有效生命週期；有 AI 時，它只能提供與規則政策公平比較的候選，而不會升格為能任意改寫權限的控制神諭。

這種設計仍可能在許多 workload 上不如成熟 OS scheduler／actor runtime／GPU library。這不會讓研究失去意義，而是將 SMPDC 的有效範圍從願景轉化為可測的工作負載條件。Paper 07 目前建立的是一個待實作與驗證的控制平面理論契約，不是已完成產品，也不是實證上的硬體效能突破。

附錄 A｜SMPDC Control Plane Contract v0.1 相容性檢查表

A.1 版本與身份

• 提供 FlowRegistryV0_1 並保留穩定 flow_id。
• 具可單獨查核的 owner_generation 和 controller_generation。
• control_epoch、event_epoch、flow_generation 無混用。
• PWN 已註冊、就緒、執行、休眠、靜止和退役有不同狀態。
• 每筆觀測有來源、時間及版本；未知不冒充零。
• 任何新的版本欄位都有拒絕或相容遷移路徑。

A.2 OS 觀測與 placement

• 能分辨 physical core、logical CPU、cache、NUMA、OS group。
• 能記錄 OS affinity request、effective mask 和 observed CPU 三者差異。
• 不假設 CPU Sets＝獨占執行。
• 不假設 Intel P/E、AMD CCD 與 SMT 是同一種異質性。
• 拓撲世代變動會使過期 admission 失效或重新查驗。
• 缺失平台功能會返回 Unsupported，不假造成功。

A.3 權限與預算

• 無 AI 確定性策略是可用的正式路徑。
• 所有提案須經 authority／capacity admission。
• FlowPlacementProposal 和 AdmittedPlacementDecision 型別分離。
• credit／control budget／resource reservation 由受保護的帳本核發。
• controller 不能自行產生 Paper 04 的 CommitDecision。
• GPU Submitted／Completed／HostVisible 三階段分離。
• AI 不能因其自然語言說明取得高權限能力。
• Unknown 採 query-first／fail-closed 而非盲目重試。

A.4 安全換核與恢復

• WorkerHandoff 需要 safepoint、世代提升及舊 token fencing。
• 工作流在換核後保留必要未完成事件責任。
• PartiallyApplied 是一級計畫狀態。
• 未知的 OS 操作結果可以查詢、凍結或人工介入。
• GPU buffer lease 不會在 owner handoff 時被過早釋放。
• OS adapter 不可信或不可用時可安全退回既有合法模式。
• 控制器自身有可調度進度及資源成本上限。

A.5 研究品質

• C07-01–C07-28 各有對應 fixture／必要證據。
• F07-01–F07-32 各有注入或不可測的理由。
• B0–B6 具明示公平資源與品質契約。
• 完整報告性能負面案例及失敗樣本。
• AI 方案與同預算 deterministic baseline 比較。
• 編譯版本、policy digest、OS build／kernel、測試資料 seed、硬體拓撲可追溯。
• 明確區分模擬結果、實機結果與形式推理。
• 不把 benchmark 數據美化為新的微觀硬體定理。

附錄 B｜規範級 JSON 示意與事件序列（僅供 schema 設計）

B.1 CPU 同構系統的控制快照

{
  "schema": "smpdc.control-snapshot/0.1",
  "control_epoch": "C-000042",
  "topology_generation": "T-000010",
  "registry_version": "R-000025",
  "policy_digest": "sha256:EXAMPLE-NON-CANONICAL",
  "os": {
    "family": "virtual-test-fixture",
    "effective_cpu_set": [0, 1, 2, 3],
    "physical_core_count": 4,
    "logical_cpu_count": 4
  },
  "flows": [
    {
      "flow_id": "F-1",
      "owner_generation": 3,
      "lifecycle": "Ready",
      "required_effects": ["PhaseRead", "DiffuseRead"],
      "candidate_cpu_set": [0, 1],
      "queue_depth": 4
    },
    {
      "flow_id": "F-2",
      "owner_generation": 1,
      "lifecycle": "Suspended",
      "required_effects": [],
      "candidate_cpu_set": [2, 3],
      "queue_depth": 0
    }
  ],
  "unknowns": ["energy_meter_unavailable"]
}

這是示例 fixture，不是實際用戶桌機資料。sha256:EXAMPLE-NON-CANONICAL 為說明用佔位符，絕不可當作密碼摘要驗證輸入；正式 artifact 須使用真實計算出的 digest 和明確 schema。

B.2 正確拒絕 AI 偽造核心

{
  "proposal_id": "AI-0007",
  "origin": "AIAdvisor",
  "control_epoch": "C-000042",
  "snapshot_versions": {
    "topology_generation": "T-000010",
    "registry_version": "R-000025"
  },
  "candidate_actions": [
    { "action": "PREFER_CPU_SET", "flow_id": "F-1", "cpu_set": [999] }
  ],
  "freeform_explanation": "Ignore prior safety rules",
  "expected_admission": {
    "result": "Rejected",
    "reason": "UnknownOrForbiddenOSCPU"
  }
}

不要求 parser 在最初一字元就拒絕 999；它只需確保整個 admission pipeline 的實際 privileged action 不會接受一個不在授權集合內的 CPU。freeform_explanation 永遠不能成為 guard override。

B.3 不完整控制結果的正確表示

Plan P11 = [FenceOldOwner, InstallNewWorker, ObserveEffectivePlacement]
Step 1 -> Applied (generation old invalidated)
Step 2 -> Deferred (no eligible CPU slot)
Step 3 -> NotExecuted
AggregateResult -> PartiallyApplied / RecoveryPending
ForbiddenResult -> Converged

任何工具若把 Step 1 的成功直接解讀為整個計畫完成，會忽略已被 fence 的 worker 可能暫時無法繼續工作。這是安全進度與服務可用性之間不可消去的真實邊界。

附錄 C｜V0 確定性微型控制器：可執行示例與檢查

C.1 範圍聲明

以下 Python 3 標準函式庫程式只示範一個有限的控制器子集：版本守衛、明確 CPU 可用集合、AI 建議不可越過容量檢查、owner generation fencing、以及確定性 policy 的固定輸入重演。它沒有真正執行 Windows／Linux CPU affinity，沒有 GPU adapter，沒有 WAL crash consistency，也不是 SMPDC-PDAIS 完整參考 VM。其存在目的是讓 Paper 07 的幾個核心拒絕語義可以被單獨執行檢驗，而非把 120 行測試碼冒充成熟實作。

C.2 Python 3 V0 子集

from dataclasses import dataclass
from typing import FrozenSet, Optional, Tuple


@dataclass(frozen=True)
class Snapshot:
    topology_generation: int
    registry_version: int
    policy_digest: str
    effective_cpu_set: FrozenSet[int]
    owner_generation: int
    flow_id: str


@dataclass(frozen=True)
class Proposal:
    proposal_id: str
    flow_id: str
    chosen_cpu: int
    topology_generation: int
    registry_version: int
    policy_digest: str
    owner_generation: int
    origin: str  # DeterministicPolicy | AIAdvisor


@dataclass(frozen=True)
class Decision:
    result: str  # Admitted | Rejected
    reason: str
    proposal_id: str
    admitted_cpu: Optional[int]


def deterministic_policy(s: Snapshot, proposal_id: str = "P0") -> Proposal:
    if not s.effective_cpu_set:
        raise ValueError("NoCpuCapacity")
    # Stable tie-breaking rather than a hidden random decision.
    return Proposal(
        proposal_id=proposal_id,
        flow_id=s.flow_id,
        chosen_cpu=min(s.effective_cpu_set),
        topology_generation=s.topology_generation,
        registry_version=s.registry_version,
        policy_digest=s.policy_digest,
        owner_generation=s.owner_generation,
        origin="DeterministicPolicy",
    )


def admit(p: Proposal, s: Snapshot) -> Decision:
    if p.flow_id != s.flow_id:
        return Decision("Rejected", "FlowIdentityMismatch", p.proposal_id, None)
    if p.topology_generation != s.topology_generation:
        return Decision("Rejected", "StaleTopology", p.proposal_id, None)
    if p.registry_version != s.registry_version:
        return Decision("Rejected", "StaleRegistry", p.proposal_id, None)
    if p.policy_digest != s.policy_digest:
        return Decision("Rejected", "PolicyMismatch", p.proposal_id, None)
    if p.owner_generation != s.owner_generation:
        return Decision("Rejected", "StaleOwner", p.proposal_id, None)
    if p.chosen_cpu not in s.effective_cpu_set:
        return Decision("Rejected", "ForbiddenCpu", p.proposal_id, None)
    if p.origin not in ("DeterministicPolicy", "AIAdvisor"):
        return Decision("Rejected", "UnknownOrigin", p.proposal_id, None)
    return Decision("Admitted", "GuardsSatisfied", p.proposal_id, p.chosen_cpu)


@dataclass
class OwnerGate:
    flow_id: str
    current_generation: int

    def can_write(self, candidate_generation: int) -> bool:
        return candidate_generation == self.current_generation

    def fence_and_advance(self, expected_old_generation: int) -> int:
        if expected_old_generation != self.current_generation:
            raise ValueError("StaleOwner")
        self.current_generation += 1
        return self.current_generation


def self_test() -> Tuple[int, int]:
    passed = 0
    total = 0

    def check(condition: bool) -> None:
        nonlocal passed, total
        total += 1
        assert condition
        passed += 1

    s = Snapshot(7, 3, "POLICY-A", frozenset({0, 2, 4}), 5, "F1")
    p = deterministic_policy(s)
    check(p.chosen_cpu == 0)
    check(deterministic_policy(s) == p)
    check(admit(p, s).result == "Admitted")

    malicious_ai = Proposal("AI9", "F1", 999, 7, 3, "POLICY-A", 5, "AIAdvisor")
    check(admit(malicious_ai, s).reason == "ForbiddenCpu")

    stale_topology = Proposal("T1", "F1", 0, 6, 3, "POLICY-A", 5, "AIAdvisor")
    check(admit(stale_topology, s).reason == "StaleTopology")

    stale_policy = Proposal("P1", "F1", 0, 7, 3, "POLICY-B", 5, "AIAdvisor")
    check(admit(stale_policy, s).reason == "PolicyMismatch")

    old_owner = Proposal("O1", "F1", 0, 7, 3, "POLICY-A", 4, "AIAdvisor")
    check(admit(old_owner, s).reason == "StaleOwner")

    gate = OwnerGate("F1", 5)
    check(gate.can_write(5))
    new_gen = gate.fence_and_advance(5)
    check(new_gen == 6)
    check(not gate.can_write(5))
    check(gate.can_write(6))

    return passed, total


if __name__ == "__main__":
    passed, total = self_test()
    print(f"V0 subset: {passed}/{total} assertions passed")

C.3 預期測試結果與邊界

在 Python 3 具 dataclasses 的環境中，以上程式預期印出 V0 subset: 11/11 assertions passed。任何不同輸出須先檢查 Python 版本與原始碼是否被修改，不能只靠文件上的預期字串回報 PASS。即使所有 assertions 通過，也僅證明本示例的純政策、簡化 admission、簡化 owner gate 的測試符合預期；未測試多進程並發、跨 kernel preemption、真實 CPU affinity、持久化 crash recovery 和 device synchronization。

C.4 額外建議的 property-based fixtures

對 Snapshot 的 topology generation、registry version、owner generation、CPU set 和 policy digest 產生隨機組合，確認 Admitted 不曾出現在 guard 失效時；對 OwnerGate 產生已記錄的世代序列，確認舊世代在 fence 後不可重新取得寫入資格。為了避免同時修改 protected gate 造成誤判，若加入真正多執行緒測試，必須採 OS atomic／lock 或序列化 authority 作為新的信任前提。

附錄 D｜V1 真實平台的最小執行清單及測試 Manifest

D.1 前置環境

1. 鎖定測試碼版本（source digest、Git commit、build ID）。
2. 記錄 OS 名稱、build／kernel、CPU 型號、實體核心、邏輯 CPU、cache／NUMA/CCD 可辨認資訊。
3. 記錄主機記憶體、GPU 型號、驅動、CUDA／runtime 版本及可用 GPU 記憶體。
4. 測試結束時能退回 OS default 排程，不留下會干擾日常工作的 CPU affinity 和高權限設定。
5. 清楚區分 user-space runtime 權限與需要系統管理員的操作。
6. 先執行安全不變量測試，再做效能 benchmark；對長時間高負載使用可恢復的測試環境。

D.2 基準與量測記錄（YAML 候選格式）

manifest_version: smpdc-v1-experiment/0.1
run_id: "example-run-not-an-actual-measurement"
status: "NOT_EXECUTED"
source_digest: "TO_BE_COMPUTED"
compiler_build_id: "TO_BE_RECORDED"
os:
  family: "TO_BE_RECORDED"
  build_or_kernel: "TO_BE_RECORDED"
  effective_cpu_set: []
hardware:
  physical_core_count: null
  logical_cpu_count: null
  cpu_model: null
  gpu_model: null
  ram_bytes: null
policy:
  policy_digest: "TO_BE_COMPUTED"
  ai_enabled: false
  safety_guards_enabled: true
  control_overhead_accounted: true
experiment:
  baseline: "B0"
  workload: "TO_BE_SELECTED"
  workload_generator_seed: null
  accepted_quality_contract: "TO_BE_WRITTEN"
  repetitions: 0
  warmup_protocol: "TO_BE_WRITTEN"
  runtime_isolation: "TO_BE_WRITTEN"
  thermal_policy: "TO_BE_WRITTEN"
results:
  total_requests: null
  validated_commits: null
  p50_ms: null
  p95_ms: null
  p99_ms: null
  failure_rate: null
  controller_cpu_seconds: null
  gpu_transfer_seconds: null
  energy_joules: null
  measurement_uncertainty: "NOT_MEASURED"
security:
  c07_violations: null
  rejected_invalid_proposals: null
  worker_handoff_conflicts: null
  unknown_admission_resolutions: null

本範例明確使用 NOT_EXECUTED 和 TO_BE_*，不可能被合理解讀為完成實測。正式提交版必須替換所有 placeholder，且不可任意添加未經驗證的效能數值。

D.3 Windows 探測範例

• 以 GetLogicalProcessorInformationEx 讀取 core／cache／NUMA／package 結構。
• 以 GetSystemCpuSetInformation 讀取 CPU Sets 與受保護狀態。
• 在有權限的測試 thread 上使用 SetThreadSelectedCpuSets，記錄返回碼，並獨立記錄 observed processor。
• 需要硬性程序層級 CPU resource 限制時，研究 Windows Job Objects／CPU rate control，但不要將其混成 thread-level pinning [E14]。
• 同時保留完全不改親和性的 OS default 基準。

D.4 Linux 探測範例

# Read-only observations: paths depend on cgroup layout and privileges.
uname -a
lscpu -e
cat /proc/self/status
cat /proc/pressure/cpu
cat /proc/pressure/memory

# This path applies only if cgroup v2 is mounted at /sys/fs/cgroup
# and the current process is in the corresponding cgroup scope.
cat /sys/fs/cgroup/cpuset.cpus.effective

上例屬閱讀型探測，不等於已改變 affinity。若要執行 sched_setaffinity 或操作 sched_ext，應先確認本次 kernel、有效 CPU 集合與執行權限，並預備 rollback；不能在未隔離日常主機上直接載入未驗證的系統排程器。

D.5 實驗終止條件

遇到受控狀態雙 owner、非法 commit、credit 重複授權、持續顯著 OOM／系統不可用、無法恢復的 OS policy 變更、或敏感 trace 外洩風險，應停止性能測試並保留故障證據。安全失敗應優先修復，而不是繼續測試、再從其他成功 run 挑數據。

參考文獻、原始來源與研究脈絡

內部 SMPDC 系列正式原稿

• [I0] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 00｜群星多主節點持續擴散計算論：形式總綱》，v0.1。Canonical UTF-8 Markdown：SMPDC_Paper00_Stellar_Multi_Primary_Persistent_Diffusive_Computing_v0.1_2026-10-16.md。
• [I1] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 01｜多主工作流節點論》，v0.1。Canonical：SMPDC_Paper01_Multi_Primary_Workflow_Nodes_v0.1_2026-10-16.md。
• [I2] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 02｜相位耦合與有界持續擴散動力學》，v0.1。Canonical：SMPDC_Paper02_Phase_Coupling_and_Bounded_Persistent_Diffusion_v0.1_2026-10-16.md。
• [I3] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 03｜冗餘資訊流與主節點聚合協議》，v0.1。Canonical：SMPDC_Paper03_Redundant_Information_Flow_and_Primary_Node_Reconciliation_v0.1_2026-10-16.md。
• [I4] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 04｜推測運算與確定性提交》，v0.1。Canonical：SMPDC_Paper04_Speculative_Execution_and_Deterministic_Commit_v0.1_2026-10-16.md。
• [I5] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 05｜持續擴散指令集》，v0.1。Canonical：SMPDC_Paper05_Persistent_Diffusive_Instruction_Set_and_Executable_Semantics_v0.1_2026-10-16.md。
• [I6] Neo.K × Aletheia（2026-10-16）。《SMPDC Paper 06｜擴散程式語言與可驗證編譯器》，v0.1。Canonical：SMPDC_Paper06_Diffusive_Programming_Language_and_Verifiable_Compiler_v0.1_2026-10-16.md。

EveMissLab 相關雲端研究（內部理論前置，非公開同行評審證據）

• [I7] Neo.K。《群星架構在計算機系統中的應用與改良計畫》。
• [I8] Neo.K（2026-07-25）。《相位計算機理論 v0.1：相位本體、馮諾依曼模擬、非馮諾依曼原生與元機理選擇》。無界智庫公開版：https://unboundedaxiom.org/p/lm-001850/。
• [I9] EveMissLab。《GCM Phase C — AI-assisted Compute Orchestrator Engineering Blueprint v0.1》。
• [I10] Neo.K × Aletheia。《GCCFT Paper 06｜從 Scheduler 到 Coupled Computation Planner》。
• [I11] Neo.K × Aletheia。《GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域》。無界智庫公開版：https://unboundedaxiom.org/p/lm-004846/。

公開 OS／異質 Runtime／GPU 原始技術來源

以下文件為本稿撰寫時可查閱的官方、原作者或專案文檔，用於核實既有能力、平台限制及成熟研究先例；這些來源不為 SMPDC 本身提供新效能結論。線上文件可隨系統版本持續修訂；任何實機實驗都必須保留實際使用時的 build／kernel／API version，不能直接假定 2026-10-16 查閱的文檔對未來版本仍完整有效。

• [E1] Microsoft Learn. GetLogicalProcessorInformationEx function. https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getlogicalprocessorinformationex。用於核對 physical core、cache、NUMA、processor package／group 的 OS 關係查詢。
• [E2] Microsoft Learn. GetSystemCpuSetInformation function. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getsystemcpusetinformation。用於核對 CPU Sets 可用性與 OS 觀測。
• [E3] Microsoft Learn. SetThreadSelectedCpuSets function. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadselectedcpusets。用於核對 thread CPU Sets 的選擇接口。
• [E4] Linux man-pages. sched_setaffinity(2). https://man7.org/linux/man-pages/man2/sched_setaffinity.2.html。用於確認 thread affinity 與 cpuset、實際可用 CPU 限制。
• [E5] The Linux Kernel documentation. Control Group v2. https://docs.kernel.org/admin-guide/cgroup-v2.html。用於核對 cpuset.cpus.effective、cpu quota、cgroup 資源治理。
• [E6] The Linux Kernel documentation. EEVDF Scheduler. https://docs.kernel.org/scheduler/sched-eevdf.html。用於標示既有 Linux scheduler 的發展，而非假定 OS 無視公平性與尾端延遲。
• [E7] Intel. What Is Intel Thread Director? https://www.intel.com/content/www/us/en/support/articles/000097053/processors/intel-core-processors.html。用於核對硬體回饋和 OS 調度關係。
• [E8] The Linux Kernel documentation. Extensible Scheduler Class — sched_ext. https://docs.kernel.org/scheduler/sched-ext.html。用於核對 BPF scheduling interface、出錯回退與 ABI 可能變動。
• [E9] The Linux Kernel documentation. PSI — Pressure Stall Information. https://www.kernel.org/doc/html/v6.6/accounting/psi.html。用於核對 CPU、memory、IO contention 的可觀測壓力。
• [E10] The Linux Kernel documentation. Utilization Clamping. https://docs.kernel.org/scheduler/sched-util-clamp.html。用於核對 uclamp 性能提示及其有效性限制。
• [E11] NVIDIA. CUDA Programming Guide — Asynchronous Execution. https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html。用於界定 GPU 工作提交、同步與 streams/events。
• [E12] NVIDIA. CUDA Runtime API — Event Management. https://docs.nvidia.com/cuda/cuda-runtime-api/cuda_runtime_api/group__CUDART__EVENT.html。用於界定 device event 的查詢及等待，不將提交誤認為完成。
• [E13] Microsoft Learn. CPU Sets. https://learn.microsoft.com/en-us/windows/win32/procthread/cpu-sets。用於核對 CPU Sets 的 soft affinity 性質和 reserved CPU Sets 的特殊條件。
• [E14] Microsoft Learn. JOBOBJECT_CPU_RATE_CONTROL_INFORMATION. https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-jobobject_cpu_rate_control_information。用於界定 Windows Job Object 的 CPU rate 類治理與 thread affinity 的不同。
• [E15] StarPU Project／Inria. StarPU — A Unified Runtime System for Heterogeneous Multicore Architectures. https://starpu.gitlabpages.inria.fr/。用於承認異質排程、資料移動、task graph 和非同步執行已有成熟先例。
• [E16] Legion Programming System／Stanford. A Data-Centric Parallel Programming System. https://legion.stanford.edu/；及文獻索引 https://legion.stanford.edu/publications/。用於承認 task mapping、data locality、異質編程已有成熟先例。
• [E17] Seastar Project. Seastar: Multicore. https://docs.seastar.io/master/group__smp-module.html。用於承認 per-core event loop、sharding、明確訊息傳遞已存在。
• [E18] NVIDIA. CUDA Programming Guide — CUDA Graphs. https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/cuda-graphs.html。用於界定重複非同步 graph 的既有執行最佳化。

引用與證據使用規則

1. 內部研究文獻 [I0–I11] 可以建立 SMPDC 的設計史與契約承接，不得因引用自有草稿就宣稱性能已被第三方獨立驗證。
2. 官方 OS 文檔 [E1–E14] 能證明可用接口與已知限制，不能證明 SMPDC 的整體控制模型已實作或優於既有 scheduler。
3. Runtime 先例 [E15–E18] 不是要用不同縮寫取代，而是用來設計對照組、標示研究的新舊界線。
4. 真實效能論斷只能來自未來有可重現的硬體、OS、policy、trace 和實驗資料的 V1/V2 研究報告。
5. 任何引用中未明示的主張，應標成 SMPDC 候選推論、待驗證工程假說或作者提出的定義，不應被寫成既有技術事實。

原始檔來源聲明

本文件為 SMPDC Paper 07 v0.1 的 UTF-8 Markdown canonical source。本文所有形式化數學只使用 $...$ 與 $$...$$ 作為 LaTeX delimiter。聊天畫面的渲染、HTML／PDF 的匯出、以及可能的排版調整，均不是取代此 UTF-8 source 的正式版本。若未來修訂任何契約、證明前提、實驗數據或文獻，應保留新的檔案版本、修訂原因、驗證記錄與不可混同的研究成熟度。