v0.7.3

What's new in v0.7.3

v0.7.3 is a GreenOps reference data refresh. The Rust API, the daemon wire protocol, the report JSON schema, and the entire CLI surface are preserved byte-for-byte from v0.7.2. Carbon numbers will shift on existing workloads because the embedded coefficients are aligned with newer upstream sources, see the per-architecture breakdown below.

Per-provider PUE refreshed from the latest sustainability reports

The four Provider::pue constants are aligned with each cloud provider's most recent published average. The sources are cited inline in crates/sentinel-core/src/score/carbon.rs and docs/design/05-GREENOPS-AND-CARBON.md.

Provider	v0.7.2	v0.7.3	Source
AWS	1.135	1.15	AWS 2024 global fleet, sustainability report
GCP	1.10	1.09	Google data centers efficiency, TTM 2024
Azure	1.185	1.17	Microsoft FY25 owned-and-controlled fleet
Generic	1.2	1.2 (unchanged)	industry midline

Impact on operational CO2: approximately +1.3 percent on AWS regions, -0.9 percent on GCP regions, -1.3 percent on Azure regions. The new vintage is exposed at runtime via score::cloud_energy::embedded_specpower_vintage() and via the PUE_VINTAGE const for release procedure audits.

Cloud instance coefficients aligned with CCF 2026-04-24

The embedded INSTANCE_POWER table (crates/sentinel-core/src/score/cloud_energy/table.rs) is regenerated from the Cloud Carbon Footprint coefficients snapshot 2026-04-24 (commit b0032d928c78) across AWS, GCP, and Azure. About 390 instance types covered with a single homogeneous methodology: idle_watts = vCPU * idle_per_vCPU and max_watts = vCPU * max_per_vCPU. The AWS-specific baseboard overhead column from the 2023-05-01 snapshot is no longer published upstream and is dropped uniformly.

Modern entries (Sapphire Rapids, EPYC Genoa, Graviton, Emerald Rapids on supported providers) are cross-checked against CCF with a 5 percent rule: re-aligned to CCF on divergence, kept on the previous SPECpower_ssj 2008 direct compute otherwise. Architectures absent from a provider's CCF CSV (Azure Sapphire Rapids, Azure Emerald Rapids, Azure Genoa, GCP Turin, GCP Ampere Altra, Azure Cobalt 100) keep their SPECpower direct value and are labelled in the table.

Practical impact, expect carbon scores to change on existing workloads:

• AWS legacy families (m5, c5, r5, m6i, etc.) drop 30 to 60 percent on operational CO2 because baseboard overhead is no longer layered on top.
• Sapphire Rapids on AWS (m7i, c7i, r7i) and GCP (c3) rise about 19 percent on max watts and 48 percent on idle watts, the previous SPECpower estimate was below the CCF aggregate.
• EPYC Genoa on AWS (m7a, c7a) and GCP (c3d, n2d) rise about 11 percent on max watts and 85 percent on idle watts for the same reason.
• Graviton 2 / 3 / 3E / 4 align with CCF's EPYC 2nd Gen proxy, the absence of measured SPECpower for these cores forced a conservative mapping that erases the AMD vs Graviton vs Intel differentiation across generations on idle.
• Azure legacy entries are unchanged, the CCF Azure CSV happened to publish the same values we already embedded.

New instance families

Family	Provider	Architecture	Notes
m8a, c8a	AWS	EPYC 5th Gen Turin	Proxied to Genoa pending an upstream CCF correction. The CCF 2026-04-24 Turin row is 5x higher than neighbouring architectures, likely a chip-vs-thread measurement error in the upstream SPECpower submission. See docs/LIMITATIONS.md section "EPYC 5th Gen Turin".
m8i, c8i	AWS	Intel Emerald Rapids	CCF Emerald Rapids row, no override.
r7a	AWS	EPYC 4th Gen Genoa (memory-optimized)	Mirrors m7a/c7a plus the DRAM premium below.
c4a	GCP	Google Axion ARM (Neoverse V2)	No native ARM row in the GCP CSV. Proxied to AWS Graviton 4, itself mapped by CCF to EPYC 2nd Gen as a conservative placeholder.

Granite Rapids (m9i) is intentionally out of scope for this release, the silicon has not landed broadly enough on AWS to justify embedding coefficients.

Memory-optimized DRAM premium

Memory-optimized SKUs now carry an additive DRAM premium on top of the per-vCPU CPU coefficient: 0.02 W/GB idle and 0.05 W/GB max, sourced from Crucial DDR4 RDIMM datasheets and the Boavizta DIMM model. At the 8 GB / vCPU ratio of these families, that translates to per-vCPU uplifts of +0.16 idle / +0.40 max. Applied on AWS r5, r5a, r6i, r7i, r7a, GCP n2-highmem-*, and Azure Standard_E* v3 through v6. Compute-optimized (c*) and general-purpose (m*) families do not receive the premium and are documented as carrying a small idle under-count, inside the 2x uncertainty bracket. This is the only methodology departure from the CCF CSV in v0.7.3 beyond the Turin override above.

Binary SPECpower vintage surfaced in disclosure reports

Periodic disclosure reports produced by perf-sentinel disclose now include a new optional field methodology.calibration_inputs.binary_specpower_vintage. The value is populated automatically from the running binary via score::cloud_energy::embedded_specpower_vintage() and is independent from the operator-declared methodology.calibration.specpower_table_version in the org config TOML. Consumers can compare both strings to detect drift between operator disclosure and embedded data.

For reports with intent = "official", the validator now rejects the report when the declared specpower_table_version does not match the binary's vintage on an ISO date prefix exact match. Substring matches that previously slipped through ("2026", "CCF", and similar) are now flagged. Operators upgrading to v0.7.3 should update their org config TOML to specpower_table_version = "2026-04-24" before producing Official disclosures. Internal-intent reports are unaffected, the validator is a no-op there.

The JSON schema docs/schemas/perf-sentinel-report-v1.json adds the field with maxLength: 64 defense-in-depth and bumps the example fixtures G1 and G2.

Documentation

• docs/LIMITATIONS.md and docs/FR/LIMITATIONS-FR.md: section "Cloud SPECpower precision bounds" rewritten around the single homogeneous methodology. New paragraphs cover the Turin override rationale, the DRAM premium, and the m-series / c-series under-count.
• docs/design/05-GREENOPS-AND-CARBON.md and FR mirror: table.rs description updated to reflect the methodology after the refresh, with the explicit split between CCF-aligned modern entries and SPECpower direct-compute exceptions.
• docs/SCHEMA.md and FR mirror: new field binary_specpower_vintage documented under methodology.
• docs/RELEASE-PROCEDURE.md and FR mirror: step 2.5 updated, both CCF_LEGACY_VINTAGE and SPECPOWER_VINTAGE now point at the 2026-04-24 snapshot, with bump rules clarified.
• CI templates and docs/CI.md / FR mirror: PERF_SENTINEL_VERSION pinned to 0.7.3.

Why this is a patch and not a minor

The only externally-visible schema addition is one optional field on periodic reports (binary_specpower_vintage), forward-compatible with v0.7.2 consumers via additionalProperties: true at the report root. Every CLI subcommand keeps its v0.7.2 surface byte-for-byte. The validator tightening on Official intent is a strict-mode-only change, Internal disclosures keep accepting any operator value. Numerical carbon shifts on existing workloads come from upstream reference data, not from a model or formula change, the cloud_specpower energy model tag is intentionally not bumped.

Verifying this release

# Binary integrity via SLSA Build L3 attestation
gh attestation verify perf-sentinel-linux-amd64 \
  --owner robintra --repo perf-sentinel

# A periodic disclosure produced by this binary
perf-sentinel verify-hash --report perf-sentinel-report.json \
  --expected-identity "https://github.com/robintra/perf-sentinel/.github/workflows/release.yml@refs/tags/v0.7.3" \
  --expected-issuer "https://token.actions.githubusercontent.com"

# Confirm the binary advertises the new SPECpower vintage
perf-sentinel disclose --config .perf-sentinel-org.toml --from 2026-04-01 --to 2026-04-30 \
  --output report.json
jq '.methodology.calibration_inputs.binary_specpower_vintage' report.json
# Expected: "2026-04-24 (CCF aligned)"

gh CLI 2.49 or newer required for gh attestation verify (unchanged from v0.7.2).

Full Changelog: v0.7.2...v0.7.3