外观
Process Energy Cost（进程软件能耗成本分）
作用域属性：[进程级 · 目标专属]（Process Scope ）
Owner恢复验收 · 2026-10-26： 网络能耗成本恢复为首项，正式0/5；定位、显示、Overhead按顺序等待。总能耗、CPU和GPU已验收结论不变。旧网络attempt不复用；当前App Build227，逐轮baseline与Build绑定的验收工具修复尚待验证。恢复验收方案 · 网络专项方案。
当前验收 · 2026-10-25： 正式55/66、剩11项。GPU能耗评分新独占完整5/5通过，600/600固定1Hz槽、1,475条Energy源、1,050样本及20,281次真实Metal完成，全部消费者与原件SHA核同（E4当前持续GPU受控场景）。保留NO_REFERENCE_ACCEPTED_OWNER_POLICY、referenceAccuracyValidated=false、ownerReviewRequired=false、deviceEnergyWindowVerified=false；下一网络能耗评分。同步/网站/Webhook交付另列，公证暂缓，仅内部测试。 结果。其余四分项仍待专项验收。
1. 定义与业务价值
Process Energy Cost 是 Xcode Debug Gauge Energy 通道给出的一组 source-native 成本值，细分为 Total/CPU/GPU/Network/Location/Display/Overhead 七项。它适合观察目标 App 在这些维度上的相对成本趋势，但 Apple 未公开完整量纲和加权算法。它不是物理单位瓦特（W）或焦耳（J），不能直接换算为毫安时（mAh）耗电量。
2. metricID / scope / unit / source
| 指标 | metricID | sourceKey | definitionVersion |
|---|---|---|---|
| Total Energy | ios.process.energy.total_cost | energy.cost | energy-total-gauge.candidate.v1 |
| CPU Energy | ios.process.energy.cpu_cost | energy.cpu.cost | energy-cost-gauge.candidate.v2 |
| GPU Energy | ios.process.energy.gpu_cost | energy.gpu.cost | energy-cost-gauge.candidate.v2 |
| Network Energy | ios.process.energy.network_cost | energy.networking.cost | energy-cost-gauge.candidate.v2 |
| Location Energy | ios.process.energy.location_cost | energy.location.cost | energy-cost-gauge.candidate.v2 |
| Display Energy | ios.process.energy.display_cost | energy.display.cost | energy-cost-gauge.candidate.v2 |
| Overhead | ios.process.energy.overhead | energy.overhead | energy-cost-gauge.candidate.v2 |
全部 scope = process，unit = source-native-cost，source = dvt.debug-gauge.energy。取自当前 Registry 。
3. iOS 系统原理
这些 Energy cost 字段的具体量纲、组成关系和加权算法未公开。Perfowl 无法、也不应该根据字段名称自行推导“某个分值对应多少瓦特”或“某个子系统权重是多少”，因此只保留系统给出的 source-native 值及其相对变化。
4. 系统服务 / 通信通道 / 采集命令与实现
通道：com.apple.xcode.debug-gauge-data-providers.Energy（DTX debug gauge）。采集：pymobiledevice3 原生 EnergyMonitor(provider, [pid])。
5. 原始字段与字段语义
energy.cost / energy.cpu.cost / energy.gpu.cost / energy.networking.cost / energy.location.cost / energy.display.cost / energy.overhead：Debug Gauge 按目标 PID 上报的七个能耗成本分字段，语义由 Apple 私有定义。
6. 精确公式
text
value = 对应 energy.*.cost 字段原样透传（不做二次计算）Total 不是六个分项简单相加：Apple 的加权算法闭源，Perfowl 尊重系统原值，不做人为加减重算。
7. Clock / Window / Freshness
Gauge 类型，每个 Energy gauge 独立采样，不做插值、不做单位换算、不取整。
8. Baseline / Reset / Discontinuity
无 counter 语义，无前值依赖。
9. Quality：valid / candidate / missing
- 负值视为源哨兵（
source-sentinel）：Total 为负时七项优先整帧关闭；单项为负时只使该项missing； - 身份未核验 →
identity-unverified； - 字段存在且通过门禁的真实 0 予以保留，不当作缺失处理；
- 不插值、不换算、不取整。
10. 合法 0 的条件
源端报告的 0 是合法数值，需与负值哨兵、missing、identity-unverified 区分；0 只表示该 source-native cost 字段当前为 0，不等价于对应硬件物理功耗为 0。
G14A 分项可用性补充 · 2026-10-05
一次受控测试中六个cost字段在固定测量窗的有值/质量槽门通过，但不代表物理耗电校准。Overhead来源114条均为 -10.0 哨兵，139行CSV保持 source-sentinel 缺值；本项未通过。历史E4来源观察与当前七项全部可用须区分，不以存在回包、Total或其他六项推算缺失Overhead。 受控测试与未关门清单。
11. 当前证据、校准与平台覆盖
CORE-19（2026-09-05）已完成产品化：iOS 17/18 真机证明了原始来源、目标身份核验、负值哨兵处理与交付闭环，但静止短场景未产生可用于数值校准的非零变化。截至最新已整理的 devlog 时间线，七项指标在 iOS 17/18 Wi-Fi 场景均已有真机 E4 源，iOS 18 场景观察到 23 个有效回包并观察到负载变化——这是 Energy/Battery/Thermal 领域中证据状态相对最好的一组。与 PerfDog 等第三方工具的同窗数值对齐仍未完成，不得描述为已交叉验证。
12. 如何分析：能得到什么结论，不能得到什么结论
能得到：目标 App 各 Energy cost 字段的相对趋势与同版本回归比较；可以观察哪个 source-native 维度的成本值相对更高。
不能得到：
- 不能直接换算成毫安时（mAh）——Apple 从未公开底层能耗加权公式，评估真实电量损耗需要参考 Battery Electrical 的放电电流/功率（在 battery-only 门禁成立时）；
- 不能把 Total 当作六分项之和验证；
- 不能把当前分值与其他工具的同名指标直接数值对比。
13. 常见误区
- 把 Energy Cost 分值当作物理瓦特/焦耳单位；
- 把 Total 与分项之和的差异当作"计算错误"。
14. Legacy / 历史实现
energy-total-gauge.candidate.v1 / energy-cost-gauge.candidate.v2 是当前实现版本，CORE-19 起正式产品化。
15. 版本历史与来源批次
本页由 site/knowledge/metrics/energy-battery-thermal.md 拆分而来，历史沿革见 Energy/Battery/Thermal 技术演进与实验。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| v1（本页） | 2026-09-18 | 从 energy-battery-thermal.md 拆出，成为 Process Energy Cost 独立 Canonical；补充 CORE-19 真机证据与外部对齐未完成的现状披露。 |
| 证据更新（算法未改） | 2026-10-05 | G14A单轮来源及未校准边界，完整54项独立误差/正式五轮仍pending。 |
2026-10-05 G24–G27来源复核（算法未改）
G27一次Start/两次sample/一次Stop真实来源，第一total=-10.0、第二52.21176470588235；overhead两次均-10.0。负数来自原生服务，不是导出计算错误，哨兵应保持missing；正分值仍candidate，不称瓦特/焦耳或外部独立校准。原elapsed字段0/2与host sleep1s分列。Energy thermalstate.cost也不替代整机热状态枚举。 全54/独立误差/正式五轮100%仍待验收。完整方法、失败阶段与资源。
2026-10-25 · 当前总成本验收准备与USB状态边界（E1）
整体52/66，唯一总成本正式0/5，其余六分项不随同验收。静态发现产品USB路由会把Energy来源准备状态标为not-applicable，但该ledger本身不能证明实际服务未采集，也不能把软件成本分等同物理功率；历史USB原生正值与负哨兵均保留。判断方法是分别核对实际请求/执行源/Raw身份与新鲜度/发布和消费者，不仅检查准备标签。当前代码的真实适用性仍待新专项软件与资格诊断，不能由“连USB”直接宣布Energy不可能或用0补空。CPU时间、任务power计数与设备电学量都不是同口径独立总成本参考。来源：当前专项方案。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 总成本专项准备 | 2026-10-25 | 精确透传/哨兵/合法0及USB准备ledger与实际来源分离，E1；正式0/5，无完整参考结论尚未作出。 |
2026-10-25 · Gauge透传仍需身份和时效门（E2）
本地合成控制已复现：把source-native字段原样透传不自动保证当前性，若只缓存latest，99秒未收到新源仍可能显示candidate；单字典fallback也可能在缺目标PID时错误接收另一PID字段。判断方法是对同一次源连续snapshot、替换payload目标并核实际Raw→Metric→发布结果。新Total专项先补显式新源/身份/时效收据及反控，不改变原生分值公式或用0补缺。当前仅E2软件控制，未宣称本机手机已出现此现象，也未增加正式验收数。来源与修复决定。
2026-10-25 · 原生负哨兵与控制通道分离（E2/E4）
Total独立source-once策略已通过软件及真实Session消费者控制（E2），新Build218内部包已安装；这不表示指标通过。两次未完成CPU负载的真机诊断中，原生总成本同时出现非负值和负哨兵，发布保持负哨兵为null，不能用最后正值或0填补。该观察只适用于这两次未施加受控CPU负载的采集，不能推断负载期分布或USB恒不可用。
Apple CLI控制通道连接失败时，产品DTX采集仍可能有数据。诊断应分别记录命令解析、连接、负载确认、目标生命与实际源值；连接成功或系统前台字段都不足以证明负载已运行。替代入口必须先核安装版本与既有参数合同、冻结单次操作和身份门；失败原件保留，不重复发送同一请求来拼成功证据。当前总成本仍0/5。诊断与新入口决策。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 总成本来源与控制分离 | 2026-10-25 | E2专项修复已验证；E4未完成负载的负哨兵及Apple控制失败边界，正式0/5。 |
2026-10-25 · 完整负载、来源健康与报告封存分别判定（E2/E4）
完整CPU阶梯负载结束且释放，不保证Energy源连续可用。本次总成本资格中237个原生封包含112个非负值与125个负哨兵；产品168个发布样本含83个candidate与85个source-sentinel，负哨兵仍为null。非负值证明该USB场景存在来源，不能推出全窗健康；轮次仍未通过。当前未证实哨兵产生机制，不能写成硬件故障、USB必然无源或低负载阈值规律。
目标生命切换还可能影响会话收尾：若把前生命清理deadline沿用到最终Stop，会在数据已落盘时错误耗尽封存预算。判断应核实际control时间、每生命清理、writer落盘/join与最终seal，而不能只看界面样本数。修复按前生命清理结果决定是否继续，清理失败不清错，真正Stop仍使用原8秒预算；Startup控制等待同时响应rebind，避免把旧生命等待误当源阻塞。上述修复仅有E2聚焦控制，新的安装及E4完整资格仍待核。来源、失败保全及修复记录。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 总成本来源与收尾分门 | 2026-10-25 | E4完整负载仍含原生哨兵，资格未通过；E2生命周期预算与Stop竞争修复，正式0/5。 |
2026-10-25 来源与时间配对补充（正式验收尚未通过）
- 相同数值可以来自不同新封包；重复消费旧封包则不能当新样本。Total新增source-once收据能核host到达新鲜度和身份，但
deviceWindowVerified=false，不证明设备内部能耗测量窗。 - 两台设备的单调时钟不能仅因前后查询很快就假设整段有相同频率。当前资格a05全量来源/消费者/封存一致，但前后constant-offset区间没有交集，仍按原门拒绝；末尾Stop迟到也独立保留为执行失败。不能移动固定窗或改小数精度来掩盖失败。
- 新资格在原生启动前后直接查询设备tick，以prepared事件在设备tick中的顺序建立host往返包围。该方法避免跨设备固定offset拟合；包围过宽、timebase变化或事件不在查询之间均拒绝。不把此host阶段配对当私有Energy测量窗证明。
- CSV使用既有六位小数序列化，Raw/Wire/Swift比较未取整值；跨进程生命的样本键为(generation,sequence)。应先核真实消费者合同，不能把正常序号重置或约定精度误判为数据损坏。
- 当前Apple Power Profiler已具有进程power impact通道，但要求较新系统，当前设备不满足；MetricKit长窗累计量不等于本项逐1Hz私有成本。参考不可用的结论须绑定当前环境，不能笼统写成所有Apple工具都无进程能耗数据。
来源：2026-10-25专项方案及增量。以上仅E1/E3调查及E4失败资格知识，不代表Total正式通过，整体仍52/66、Total0/5。
2026-10-25 · 温控中止和冷却准入（E4失败证据／E2工具）
连续受控高CPU场景中，Fixture在101.776秒收到系统温控保护并释放全部worker；产品同期cost数据正常不能覆盖负载提前终止。与持续负载和冷却不足存在合理关联，环境温度、充电及散热贡献未隔离，不能断言手机硬件故障或唯一原因。应核真实summary、最后事件和worker释放，整组首失败即停止，保留原数据，不减负或补轮凑通过。
后续准入使用自有App显式零负载观察的真实ProcessInfo.thermalState，不能用Energy私有cost或未知Diagnostics枚举替代。每轮至少300秒不施压且最近至少30秒nominal/active、相邻记录≤3秒才准入；若900秒仍不成立则停止同配置重试。观察器本身须通过OFF/ON开销门，此资源条件不证明能耗准确度或温控指标通过。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 总成本温控准入 | 2026-10-25 | E4失败整组保留、温控归因边界及显式真实状态冷却门；正式仍0/5。 |
来源：当前专项方案与失败原件记录。
2026-10-25 · 零负载观察也要区分启动预热与稳定活动（E4工具证据）
原生启动成功、系统前台字段为true，不表示应用最早的UIKit状态读数已经active。本次真实零负载观察首条在启动后0.001163秒inactive，后续每2秒均active、全程nominal；旧“所有记录必须active”的主机工具因此错误拒绝。应保留首点，并明确有限启动预热：首active必须≤3秒，只允许其之前的inactive；首active后任何inactive仍拒绝，不能把中途退后台称预热。新实验使用独立前缀，不把旧失败改判或拼接。
冷却资格仍须实际≥300秒，末尾连续≥30秒全nominal且active、相邻记录≤3秒，最新设备tick年龄≤3秒，准入到CPU启动≤15秒。开销比较仍计算整个观察区间的CPU时间，保留最早读数和启动成本；live append前缀不冒称关闭封存，进程转换后另保全最终源及host SHA。仅改善资源准入工具，不证明成本精度或Total指标通过。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 温控观察启动预热 | 2026-10-25 | E4首点inactive证据、有限预热/稳定段与live前缀完整性分离；正式仍0/5。 |
来源：温控工具a01失败与新实验方案。
2026-10-25 · 工具交接等待和实际设备时序分开（E4工具证据）
跨工具的READY通知至真正点击Start之间可能已有明显等待，不能把这段时间误归为手机连接或客户端冷启动。应同时记录READY、真实Session产生、首稳定源以及实际设备指令前后的单调时钟；本次21.834秒主要出现在READY至实际Session的交接，首样本是在启动后约2秒。资源新鲜度应在实际Session确认后重新读取真实末段，再开始既定限时；旧观察生命按计划结束也不能让旧值冒充当前新读数。源age不达标仍拒绝，不能放宽为“连接正常就通过”。
工具预先写下attempt计数，或将cpuWorkloadConfirmed预设true，都不能证明实际发令。应区别配方意向、真正dispatch、返回ack、Fixture真实run及完整终态，失败时根据实际意向/派发收据报告，并用增量更正保留错误旧收据。此方法适用于判定“无负载的控制失败”，不改变数据/完整负载/封存等验收门。
来源：a07保护拒绝与a08更新时点决策。当前仍52/66、Total0/5。
2026-10-25 · 切换后的新读数与直接时间包围（E4资格）
在实际Session建立后重新读取仍可核验的真实温控末段，可以排除跨工具等待造成的准入过期；必须同时保留READY前缀、新准入前缀及观察生命结束后的完整原件。新的a08资格确认120个固定槽来源/消费者/封口一致，175秒负载完整释放，prepared直接查询包围58.874ms，CPU准备在准入新读数后不超过3.468秒。该结果验证当前资格流程，不计正式五轮，也不证明私有Energy设备测量窗或独立精度。正式仍52/66、Total0/5。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 温控切换资格 | 2026-10-25 | E4新读数/最终原件与prepared直接包围成立；新正式attempt仍须完整五轮。 |
2026-10-25 · nominal准入不保证后续持续负载完成（E4失败证据）
新实验在真实零负载320.071秒、连续nominal/active282.034秒后仍于负载第165.387秒触发thermal-limit；145秒工作段已join，但15秒恢复尚未完成。固定120槽与消费者一致不能豁免完整负载失败。ProcessInfo的nominal是离散状态，不是内部温度或热裕量读数；采集前状态合格并不承诺后续高负载不触发保护。不能据此断言USB通道失败或手机硬件损坏。
判断应同时核准入原件/最新tick、实际准备时限、阶段事件、系统保护取消路径和全部资源释放。后续先加强被动冷却到实际600秒及连续300秒nominal/active，保持负载、恢复与热保护不变；若仍失败则停止同配置重试，等待散热条件变化。该加强方案尚待新资格，正式仍52/66、Total0/5。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| nominal与持续负载边界 | 2026-10-25 | E4原准入成立仍热中止；恢复期属于完整合同，不以窗口正常覆盖失败。 |
2026-10-25 · 加强被动冷却后的单次资格（E4）
更严格冷却资格a09已完成：实际观察624.088秒、连续nominal/active尾621.991秒，175秒原负载完整释放，120固定槽与全量消费者/封口核同。该单次结果支持采用600秒实际零负载＋300秒连续尾段的新资源门，不能据此断言已找到唯一热中止原因，或保证后续五轮不会触发温控。观察模式、负载、系统热保护均保持；旧失败attempt不改判、不拼轮。正式仍52/66、Total0/5。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 加强冷却资格 | 2026-10-25 | E4单次资格完整通过，正式另起attempt03五轮；资源准入不等于精度校准。 |
2026-10-25 · 冷却就绪与恢复后的实际活动分开（E3）
主机执行句柄及其排队输出不能证明手机观察当前仍在进行。本次冷却ready距新的准入已有超过3小时，有限900秒观察已结束；启动前真实live检查拒绝，0新Session、0CPU派发。两个较早合格轮仍保留，但按本组首失败停止规则不能拼成新五轮。判断应核ready的真实时间、同启动周期单调时钟、最终closed状态、当前手机新读数及进程生命；不以恢复后读到的旧stdout代替这些条件。
主机可将有界观察成功、准备及控制器启动串行自动衔接，减少跨工具等待；ready的单调年龄及文件wall年龄均须非负且≤15秒，准备后再次检查，控制器仍重新读取真实手机状态。自动交接不代替标准GUI操作、不延长900秒或降低600/300秒冷却门；时钟变化、陈旧、子进程失败均停止，不能自动重启旧请求。此门仅管理实验资源与执行时序，不证明能耗精度或指标通过。
| 版本 | 日期 | 修订要点 |
|---|---|---|
| 冷却就绪恢复门 | 2026-10-25 | E3陈旧观察启动前拒绝及完整保全；E2自动交接6控制通过，正式仍52/66。 |
2026-10-25 · Total正式五轮通过（E4限定场景）
新独占5/5、600/600固定槽、1,444条源/1,025个样本及全部消费者/封口核同。每轮新生命、175秒受控负载与≥600秒真实零负载恢复、≥300秒nominal/active尾；最终全部1,881件CPU证据及51件温控证据源/host SHA核同。Total正式计入53/66，六分项仍待验。标记NO_REFERENCE_ACCEPTED_OWNER_POLICY、referenceAccuracyValidated=false、ownerReviewRequired=false，不能解读为物理W/J精度校准。
长期测试中，冷却ready是有限时效的资源条件，必须在实际Session后重新读取当前生命与状态；历史正常窗口不能覆盖同组热中止。新来源唯一消费与0..2秒主机到达年龄共同防止旧值重复发布，但仍不证明设备测量窗。完整负哨兵保持null，真实0保留；不靠裁掉尾部取得通过。
| 版本 | 日期 | 修订要点与来源 |
|---|---|---|
| Total正式验收/source-once.v1 | 2026-10-25 | 新完整五轮及最终SHA通过；当前设备/系统/220/Lab33高CPU场景，独立精度未校准。结果 |
2026-10-25 · CPU分项来源质量专项（E2，未验收）
CPU分项与Total虽共用Energy服务，各指标仍需独立目标和发表收据。软件反例显示，未启用CPU专属新鲜度时，一次CPU成本可在9秒/99秒后重复发布，单个错目标字典也可能被旧fallback接受；这不是当前手机已发生异常的证据。新energy-cpu-source-once.v1只对CPU请求启用，严格目标/生命/epoch/序列及host arrival age0..2秒，每Raw至多发表一次，无新来源保持null。公式仍为energy-cost-gauge.candidate.v2，不是物理功耗。
保留既有有限负Total整帧哨兵门：即使CPU字段为正，也不自行解除该门；CPU自身负值或缺失同样null，真实0合法。旧未标记Raw不回改；双policy各自消费，不把Total的5/5作为CPU5/5。新56软件控制与实际Swift消费者专项通过仅E2，CPU正式仍0/5、整体53/66，当前独立参考及新真机资格待完成。
| 版本 | 日期 | 修订要点与来源 |
|---|---|---|
| CPU source-once.v1 软件质量 | 2026-10-25 | E2严格目标、唯一消费、时效及Total负哨兵兼容；CPU尚未验收。方案与实施 |
2026-10-25 · CPU新真机资格增量（E4，正式0/5）
221内部包的新独占资格诊断通过120个预冻结1Hz槽：每槽CPU使用新来源，全部来源与Session消费者及封口核同；完整保存281条Energy源、199样本、17,504条负载事件和温控原件。该结果证明当前设备/系统和受控高CPU场景下这一次采集链正常，不代替CPU完整新五轮，仍53/66。
独立参考须逐分项调查：CPU时间、指令数、线程工作量及电池功率与私有CPU cost不同定义；同一Energy服务的第二客户端也不是独立真值。当前系统不满足Power Profiler要求，Energy Gauge图示没有完整逐1Hz原值导出，因此本批确认没有可用于同定义逐槽精度对照的完整独立参考。不能在自有App内设定一个预期cost来伪造参考；仅后续新五轮正常性全过，才适用Owner的无参考正式接受标记，且仍保留referenceAccuracyValidated=false。
| 版本 | 日期 | 修订要点与来源 |
|---|---|---|
| CPU资格与参考边界 | 2026-10-25 | 新E4资格120槽通过，正式0/5；不同物理量不能替代CPU cost参考。方案及资格记录 |
2026-10-25 · CPU正式五轮通过（E4限定场景）
新独占完整5/5、600固定槽、1,504源/1,067样本与全部消费者及封口核同；最终1,917件CPU原件与63件温控原件全源/host SHA一致。CPU计入正式54/66，保留NO_REFERENCE_ACCEPTED_OWNER_POLICY、referenceAccuracyValidated=false、ownerReviewRequired=false。仅当前17.0/221/Lab33持续高CPU场景正常性，不证明物理能耗或独立精度。其余五Energy分项分别待验。
| 版本 | 日期 | 修订要点与来源 |
|---|---|---|
| CPU正式验收/source-once.v1 | 2026-10-25 | 完整新五轮及最终保全/独立重算通过，CPU1Hz候选来源唯一消费与合法缺值保持。结果 |
GPU来源质量调查增量 · 2026-10-25（E2，尚未正式验收）
软件合成控制确认旧GPU快照可重复发表同一源值，旧Raw单字典回退也可接收非目标键；不能据此认定手机已发生异常。GPU专项新增独立source-once策略：严格目标与来源身份，每源至多一次、arrival age为0至2秒，无新源保留null，真实0合法，负Total仍整帧哨兵。复现与避免方式见专项方案。聚焦86项及实际Swift Session/CSV消费者控制通过仅为E2，不证明GPU值准确或真机可用；当前正式0/5。CPU/GPU/Total共享adapter改动须分别验证only-request与三策略并存，防止条件分支误移使其他策略缺来源序号。
GPU参考边界与固定场景（2026-10-25）
当前iOS17.0/Xcode16.4/SDK18.5环境没有同定义、独立的逐1Hz GPU source-native-cost参考：SDK MetricKit给累计时长，Metal给命令执行时间与工作量；这些值不能乘一个自定系数变成私有成本。Power Profiler当前要求iOS26及以上；Debug Gauge组件占比和同源EnergyMonitor也不能构成独立准确度证明。自有测试App应设计真实三档Metal提交/完成用例，独立证明工作量、阶段和排空，保留计数器不可用原因；不能预设分值随负载线性变化或以0替代缺值。
资格窗口预先冻结为baseline阶段直接时钟包围上界+10秒后首槽开始120个1Hz槽，缺值不能向后移窗补齐。18项独立软件控制通过不代表真机验收，GPU仍0/5。当前参考缺失决定仅适用于上述环境；未来系统/API改变须重新调查。来源：专项方案与参考矩阵。
| 版本 | 日期 | 修订要点与来源 |
|---|---|---|
| GPU来源与参考准入 | 2026-10-25 | E2来源质量及独立审计，当前参考定义边界；正式0/5。见专项方案。 |
GPU固定窗口与空闲哨兵陷阱（2026-10-25，E4当前资格）
140秒场景不等于140秒有效GPU负载：原三档各30秒，仅90秒在负载。若120个固定槽跨越baseline/recovery，底层Total=-10可能使GPU非负值也必须置空。此次资格120槽95candidate/25哨兵，未通过；Raw与消费者一致、2704次成功Metal完成也不能解除来源门。避免方式是在采集前确保实际负载时长容纳完整窗口和两侧保护，超出Fixture上限须正式修改方案/版本并重新资格，不能后移窗口挑数据、删失败样本或放松负Total规则。host-arrival内部区间没有负Total是本次证据，不能外推所有设备或因果。来源：完整资格失败与后续方向。
GPU持续负载新资格合同（2026-10-25，待验）
针对旧资格的固定窗口跨空闲问题，新Lab34前瞻合同采用20秒baseline、三档各45秒GPU负载及30秒recovery，总185秒；真实GPU负载135秒。固定120个1Hz槽从baseline直接时钟包围上界+30秒后的首计划槽开始，末槽不超过下界+151秒。窗口在采集前固定，不随观测值移动；负Total整帧哨兵、缺失保持null及每源唯一发表语义继续成立。旧140秒资格95/120候选的失败保持原结论。
当前已完成新版本安装前后全数据SHA与六次OFF/ON开销资格，三组CPU增量0.0582/0.0450/0.0398个百分点，内存增量均未超门；这些是工具资格证据，GPU正式仍0/5。每次新指标资格仍需新温控准入、实际Metal提交/完成与全消费者核对；五轮正常性通过后才适用无参考接受政策。新方案与实际进展。
| 版本 | 日期 | 修订与来源 |
|---|---|---|
| GPU sustained qualification plan | 2026-10-25 | 新185秒场景/固定120槽合同，Lab34工具资格通过，GPU正式未通过；见持续负载方案。 |
2026-10-25新Lab34资格增量（E4当前场景，非正式轮）：新185秒/135秒GPU场景的120固定槽全部通过，4,056次提交均完成、8,297事件、308源/219样本及全部消费者封口核同；最终温控与冻结输入SHA成立。该结果支持持续负载修订在当前设备上的单次资格，旧a01失败不回改；正式仍0/5、整体54/66。完整新五轮、最终保全及无参考标记仍待完成。来源。
GPU持续负载正式五轮结论 · 2026-10-25
GPU能耗评分在当前设备A、系统17.0、Mac222/Lab34持续GPU受控场景新完整5/5正式通过（E4）：600固定1Hz槽、1,475条Energy源、1,050样本、20,281次Metal提交全部完成；完整Raw/derived/wire/Session/CSV与封口核同。五轮结束后1,959件/3,858,518,054B旧新三根全源/原host SHA和95件温控原件SHA通过，10份审计分离重算一致。此前资格和未完成轮次段落为历史快照。
当前确认没有完整独立同定义参考，按Owner政策计入，标记NO_REFERENCE_ACCEPTED_OWNER_POLICY；referenceAccuracyValidated=false、ownerReviewRequired=false、deviceEnergyWindowVerified=false。Metal实际工作量和计时只用于负载资格，不是每秒cost真值；累计GPU时间、Energy Gauge最近10秒活动与物理电池功率不能替代本字段。下一网络能耗评分须独立来源/质量/参考和新场景资格，不复用本五轮。
| 版本 | 日期 | 修订与来源 |
|---|---|---|
| GPU source-once正式五轮 | 2026-10-25 | 当前持续GPU场景正式通过，保留无参考与设备窗未校准边界；结果。 |
网络能耗来源唯一消费合同 · 2026-10-25（实现前，未正式验收）
ios.process.energy.network_cost读取energy.networking.cost，process/source-native-cost，公式energy-cost-gauge.candidate.v2不变。新增energy-network-source-once.v1只在请求网络能耗时启用：严格目标身份及Energy来源、每源最多发布一次、host arrival age为0..2秒；真实0合法，无新源/错误身份/缺失为null，有限负Total整帧哨兵继续优先。主机到达新鲜度不是设备测量窗，deviceEnergyWindowVerified=false。网络字节、URLSession耗时与服务端正文SHA仅证明实际负载，不可换算或预设本cost真值。
已通过真实软件链合成复现单源1.25在age9/99秒仍发布、错目标单字典22.5被接受（E2，非手机异常）。计划修正后仍须软件、内部包、参考资格、真实负载和完整新五轮，不因其它Energy分项通过而接受网络项。服务端节流也不能直接证明手机持续发包，需双端实际时间和回执资格，避免固定窗口跨空闲后放宽来源门。方案。
| 版本 | 日期 | 修订与来源 |
|---|---|---|
| Network source-once contract | 2026-10-25 | 实现前记录网络专属来源/唯一消费/参考与负载边界，正式0/5；见网络专项方案。 |
2026-10-25 · 网络工作量与能耗来源覆盖的边界
当前设备的资格实验真实完成50MiB上传，URLSession请求发送约130.71秒，服务端接收约133.34秒且双端正文SHA一致；205个产品样本中仍有108个整帧source-sentinel，仅97个candidate，未达到固定120槽要求（E4当前局域网上传场景，未验收）。这证明传输完成量和持续时间不能替代source-native能耗来源覆盖；是否由系统采样窗口、负载分布或其他因素导致，尚未确定。判断时应同时检查原Energy帧的Total负哨兵、分项、真实进程生命及固定窗口，不能因网络分项非负而放松整帧质量规则。阶段计时须直接包围实际设备事件；native参数启动的ack相对阶段会包含启动和取证耗时，按ack延迟开始取证可能错过事件。本次宽13.01秒的包围不符合750毫秒门槛，须新资格前修正。来源：网络资格方案与增量。
2026-10-25 · 请求节奏与实际来源频率
独立单EnergyMonitor诊断保留204条完整原回复，三个上传时间块采用响应后等待0.5/1.0/0.5秒，全部请求52/40/72，其中Total负哨兵26/1/41（E4当前场景诊断，非正式验收）。服务响应中位约0.213秒，因此响应后等1秒的实际周期约1.213秒，不能当作固定1Hz或通过复用旧来源凑齐1Hz。该差异支持调查查询节奏，但时间段及实际传输结束仍为混杂因素，因果未建立。复现时记录请求/响应时刻、实际设备事件、全部原回复与进程生命，失败和负哨兵均入分母；下一比较须预先冻结绝对请求起点，不事后选相位。来源：网络专项诊断增量。
| 版本 | 日期 | 修订与来源 |
|---|---|---|
| 网络节奏诊断边界 | 2026-10-25 | 区分响应后等待与实际频率，保留混杂与未验收边界；来源同上。 |
2026-10-25绝对1Hz增量（E4当前诊断，非正式验收）：新单Monitor完整176回复，实际请求间隔约998.07..1002.00ms、最大调度偏差2.584ms；上传145请求仍有56次Total负哨兵。该受控场景证明固定请求起点不足以消除缺值，不能据此把问题归为主机定时误差、硬件故障或某个唯一根因；负哨兵保持missing，不重用旧源凑槽。来源为上述网络专项a03终态增量。
2026-10-25静态溯源增量（E1，规则未变）：本机Xcode Energy UI的version1分支独立读取网络cost，将热状态整数另存，以分项/开销合计图表总量；不能将该图表总量等同原生energy.cost。此消费路径提示需核实负Total整帧missing的适用边界，但未证明原生0或服务完整语义，当前网络规则不变。研究时应区分设备原生字段、客户端图表合成和产品质量门，不能以分量相关性或UI反汇编替代独立同定义精度对照。来源为网络专项Xcode静态证据增量。
2026-10-25 · 网络字段质量修订合同（实现前，未验收）
新显式energyNetworkQualityPolicy=energy-network-field-local.v1限定energy.version为整型1时，网络有限非负原值直接候选（含真实0），网络负值missing/source-sentinel，缺失/非有限/类型或版本错误保持missing；Total负数不否决该独立网络字段，Total自身规则不变。算法energy-network-field-local.candidate.v1，无聚合/截零/换算；来源身份、单源一次和2秒到达age继续约束。旧无标记回放保留原整帧规则与公式。依据为Xcode完整消费路径E1和新原始字段诊断E4，不是设备算法或独立精度证明，尚未新五轮验收。见网络专项修订决策。
网络字段质量实现进展 · 2026-10-26（E2，尚未正式验收）
该版本已进入 Sidecar 的 Raw adapter、RawMetricEngine 与 Realtime 投影，并贯通 Swift Session、CSV 和 Export。定向 Python 36项、Session artifact Swift 11项通过；这些软件合同检查不代表真实设备精度或本指标通过。网络能耗评分仍正式0/5，旧无标记回放继续原有 Total 负值门，当前字段级语义仅用于显式新策略。
| 版本 | 日期 | 修订与来源 |
|---|---|---|
| Network field-local E2 implementation | 2026-10-26 | 显式 version 1 网络字段质量进入产品路径；36项 Python 与11项 Session 消费者回归通过（E2），正式仍0/5；方案与实现增量。 |
| Owner恢复顺序验收 | 2026-10-26 | 网络能耗恢复为第一项，仍0/5；不改公式、来源或验收门；总方案。 |
2026-10-26 Owner范围更新（历史状态）
当时总能耗、CPU及GPU能耗已有正式结果保持；网络/定位/显示/Overhead四项暂停，不计通过。该暂停状态已被2026-10-26最新Owner指示覆盖，恢复情况见本页顶部。