Metrics and Indicators Part 2 - 2026 Claim

As a Cedars user, I want the remaining metrics and indicators available with clear names, sector and quarter, so that I can filter and compare results without needing to interpret raw field names. Part two of the metrics and indicators work. Part one delivered the initial set of metrics; this ticket covers the remaining metrics that can be derived from data already held within Cedars, and adds friendly names, sector and quarter so they're easier to find, read and compare.

Onboard and add new PA - CCEA (CalChoice Energy Authority)

As a measure package developer, I want every gas and electric permutation in a measure package to be handled correctly during the eTRM sync to Cedars

As a measure package developer, I want every gas and electric permutation in a measure package to be handled correctly during the eTRM sync to Cedars, so that gas-only permutations don't hold back the whole package Background The new eTRM Sync History page lists measure packages that failed to sync and the reason. Some packages show a UEC of 0 for both the first and second baseline. The page made these cases visible for the first time. Issue raised (Chau) While checking these packages, Chau found that some permutations are gas-only. They have no electric UEC, so the electric value comes through as zero. Example: SWHC059. Chau also mentioned a water heating package. Chau asked whether the electric permutations synced and only the gas ones failed, or whether the whole package was held back. Sonja's understanding is that the whole package is held back. That isn't the behaviour we want. Chau wasn't sure whether these packages are meant to go through load shapes at all. Part of the reason for raising it was to rule out an error on the measure package side. How to identify gas-only permutations (Spencer) A gas-only permutation has a positive value in the therms column for first baseline savings and 0 in the kWh column. A common case is a building with gas heating but no air conditioning, where the measure controls only the gas heating. Some offerings split these out into separate permutations. Mixed-fuel packages (Henry) Some packages mix gas-only and electric permutations. One example is the smart fan controller package (SCE-led), which can have gas or electric savings depending on the product. Henry doesn't expect many packages to have this mix, but it's worth checking which ones do. Open questions What does the sync do today when a package contains gas-only permutations: hold the whole package, or only those permutations? Do gas-only permutations need a gas load shape or any other treatment, or can they simply be skipped for load shapes? Which measure packages are affected? Henry suggested checking the smart fan controller package first. How should permutations with both electric and gas savings be handled?

As a CEDARS claims reviewer, I want Measure.FuelID to be required in the 2027 claims spec, so that fuel substitution claims always go through fuel substitution validation

During 2026 Q1–Q2 QC, Corina found that many PY2026 fuel substitution measures are missing a Fuel ID and still pass CEDARS validation. Fuel substitution is no longer flagged in Delivery Type, so these claims now skip the fuel substitution logic whenever neither Fuel ID nor Measure Impact Type flags them. Roopa confirmed that validation uses Fuel ID when it is filled in and falls back to Measure Impact Type when it isn't. This ticket tightens Fuel ID validation for the 2027 claims spec and accounts for legacy measure packages that were built without a Fuel ID. "In the Q1-2 QC, we notice that, since Fuel Sub is no longer specified in the Delivery Type, many Fuel Sub measures are lacking FuelIDs and getting through the CEDARS validation process when we think they should have been errored."

SoCalREN 2025 data correction

SoCalREN discovered that some expenditures from 2025 were miscategorized and would like CEDARS to reflect the correct categorization. The total amounts are correct and do not need to be changed.

EE Dashboard vs CEDARS Summary - CE Ratios discrepancy

Reported by Yamini (Guidehouse). We are preparing a draft of the EE dashboard (including 2026-Q1-Q2 data) for publishing on CEDARS-2. As part of our QC, I am comparing the dashboard results against the CEDARS claims summary table and noticed a difference in the Cost Effectiveness (CE) ratios that we are trying to reconcile. Overall, our TSB, expenditures, and energy savings match the claims summary exactly. However, all CE ratios differ specifically for the Residential sector only. A deeper review shows that the discrepancy for TRC ratios is limited to PG&E, SDG&E, and SCG only. Could you help us understand what may be driving this difference? We are wondering whether the CEDARS summary table applies an additional field, filter, or calculation rule that affects the Residential CE ratios. Example 2026 TRC CE: Primary Sector Dashboard TRC CEDARS TRC Diff. Agricultural 1.01 1.01 0.00 Commercial 1.23 1.23 0.00 Cross-Cutting 0.33 0.33 0.00 Industrial 3.96

Exclude From Budget/CE Flagged Programs Record Level Data

CEDARS should not remove calculated values for programs with exclude from budget or exclude from CE in the record level downloads - the full data should be available and PAs apply the flags appropriately when filtering for specific values. Zeroing them out removes transparency in what was being excluded.

As a PA, I want the Q1/Q2 output files regenerated so the SavingsDate output field is populated

The SavingsDate output field was added as part of the Claims Spec update, but the Q1/Q2 output files were generated before that field was in place — we mistimed getting the output out ahead of the Claims Spec deadline. As a result, the existing Q1/Q2 outputs don't have SavingsDate populated. Which is blocking Eric Corona's testing. This ticket covers regenerating those output files so testing can proceed.

Update CEDARS Data Validation Rules to Support New DEER Delivery Types (PY2026+)

Business Justification: New DEER Delivery Types have been introduced for Program Year 2026 and must be incorporated into existing CEDARS data validation rules and business logic. This enhancement will ensure accurate validation, processing, and reporting of 2026+ claims while maintaining compatibility with legacy delivery types used for pre-2026 program years. Request Update all applicable CEDARS data rules and validations (e.g., DATE rules and other delivery type-dependent validations) to incorporate the new DEER Delivery Types. Ensure the new delivery types are supported for Program Year 2026 and future years. Maintain compatibility with the legacy delivery types for pre-2026 program years to avoid impacts on historical data and reporting. Review all rules, calculations, and reporting logic that reference delivery type values and update them as needed.

"Budget Filing Summary" table C/E

The Cost Effectiveness Ratios on the budget filing summary table seems to be buggy for specifically the cross-cutting sector. For PG&E’s 2028-2031 years, the values should be: Primary Sector Year TRC (dashboard) TRC (recalc) TRC Var PAC (dashboard) PAC (recalc) PAC Var RIM (dashboard) RIM (recalc) RIM Var Status Cross-Cutting 2028 1.98x 1.52x -0.4613 33.08x 18.98x -14.1042 0.94x 0.48x -0.4597 REVIEW Cross-Cutting 2029 2.08x 1.54x -0.5363 30.35x 16.98x -13.3720 1.05x 0.51x -0.5421 REVIEW

Understand how FuelID affects CET outputs

On behalf of BayREN, I’d like clarity on how populating the Measure table FuelID field affects CET outputs for fuel sub measures. In claims reporting, my team is considering using this field to identify all fuel sub claims because some fuel sub measure packages don’t use the fuel sub measure impact type values by default. With the Q1-Q2 claims we’ve filed, including/removing the fuel sub FuelID for only one fuel sub claim (using measure SWHC044-07) affected CET outputs (TRC, PAC, RIM, SCT, ElecBens). We don’t understand why this is the case and whether we should expect similar results for other fuel sub claims. For reference, I’ve attached our analysis comparing FuelID vs. no FuelID, along with a copy of the claims file with FuelID populated for BAYREN02 (the program in the Q2 submission containing fuel sub claims).

Managing Obsolete Load Shapes/Impact Profiles

When a measure package's TechIDs change after load shapes/impact profiles have already been uploaded, the original ("obsolete") upload data remains in Cedars even though it will never be used. We need a documented best practice for whether these obsolete uploads should be deleted or retained. Background/Example For SWCR018, load shapes were initially uploaded (Upload 447) using the original TechIDs for a non-modeled measure package, but with values borrowed from a modeled measure package (SWCR015). Following further discussion, it was decided that the TechIDs from the modeled measure package should be used instead, resulting in a new upload (Upload 453). As a result: Upload 453 will be the load shapes/impact profiles actually used going forward. Upload 447 is now obsolete and will never be used. Problem There is currently no defined process for handling obsolete uploads. Leaving unused, obsolete load shapes and impact profiles in the system risks: Duplication of records Confusion between correct and incorrect/outdated load shapes Potential for the wrong upload to be referenced downstream Questions for Discussion Should obsolete uploads be deleted outright, or is there a preferred archiving/flagging mechanism instead? Is there a technical or audit-trail reason to retain obsolete uploads? If deletion is the agreed approach, who is responsible for performing it — the original uploader or anyone on their team?

Data Record-level archived downloads available for 2028-2031 budget filings

As a user, I want to be able to download the archived 2028-2031 Budget Filings the are superseded.

Use the modeled load shapes from one Measure Package for a non-modeled measure package

Background PG&E wants to reuse the Measure Case load shape from SWCR015 (Glassdoor-LED refrigerated cases) as both the Measure Case and Base Case load shape for SWCR018 (standard-efficiency → high-efficiency refrigerator/freezer replacement). Why SWCR015's ACC/load shape pair models "always-open case" (base) vs. "glass door installed" (measure) — a door-addition measure. SWCR018 is an efficiency-upgrade measure where both base and measure cases have doors; only unit efficiency changes. Applying SWCR015's shapes as-is to SWCR018 would incorrectly bake in the "doors vs. no doors" load shape difference, which doesn't reflect SWCR018's actual measure logic. Proposed workaround Set both the "Measure Tech ID" and "Standard Tech ID" fields in the eTRM permutation to the identical value (NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond), differing only in UEC. This was tested locally and confirmed to work — CEDARS generates the impact profile fine as long as a permutation exists with matching Tech IDs on both sides and differing UEC values. Confirmed technically CEDARS has no structural issue generating an impact profile where Measure Tech ID = Standard Tech ID, provided the permutation is synced from eTRM with that configuration and UECs differ. Resulting ACC/Impact Profile ID: GroExAny | NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond | NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond Questions Precedent/policy question: Is reusing a measure-case load shape as both base and measure case an approach that should require sign-off from the broader load shapes group, given it's a workaround rather than a standard/intended use. Downstream clarity/misleading risk: When someone else (analyst, auditor, future CPUC reviewer) encounters an impact profile with identical Tech IDs on both the measure and base side, will they understand why? Scope/generalizability: Is this specific to SWCR018, or should we anticipate other measure packages with a similar "shape doesn't match base/measure logic" mismatch making the same request? If so, should we document a standard process/guidance for this pattern rather than a one-off answer?

Duplicate Hour in Impact Profile Exports

Load shapes Impact Profile export 8759 unique hours instead of 8760 — one hour appears twice while another is missing entirely, resulting in the output still containing 8,760 rows but with a duplicated hour timestamp rather than a duplicated impact value. Specifically, hour 1587 is missing and hour 1588 appears twice. Likely related to daylight saving time handling.

New review team file download

Request from Peter B’s team. New impact profile file for download that includes: a.  Impact Profile ID / E3MeaElecEndUseShape b.  PA / IOU c.  E3TargetSector d.  E3ClimateZone e.  avoided-cost version f.   avoided-cost combination ID / AC Elec Key g.  BldgType h.  BldgVint i.   BldgHVAC j.   Measure TechID k.  Baseline TechID l.   TechGroup and TechType, where applicable m. first-baseline vs second-baseline indicator, if applicable n.  source year/calendar used, e.g. 2009 non-leap Thursday-start o.  baseline load-shape ID used p.  measure load-shape ID used q.  baseline annual UEC used r.   measure annual UEC used s.  denominator/savings used in the impact formula t.   validation status/results u.  generation timestamp v. eTRM measure package ID w. eTRM permutation ID x. eTRM source snapshot/extract timestamp And also provides additional files containing: 1. baseline load-shape 8760 csv 2. measure load-shape 8760 csv Please give files descriptive names that include the Impact Profile ID or AC Elec Key.

Additional load shape derived impact profile validation

Request from Peter B’s team to add validation before impact profiles are generated/exported to confirm that each profile has exactly 8,760 rows no missing or duplicate hours hour_of_year values from 1 through 8,760 matching baseline and measure hour sequences input/output shapes that sum to 1.0 within an appropriate tolerance

Add 2023–2025 Statewide Claims "Record-level Measure Input and Cost Effectiveness Output" files to Data tab

The Statewide Claims "Record-level Measure Input and Cost Effectiveness Output" file was added for 2026 to the record-level data page. Equivalent files already exist for 2023–2025 on the Statewide confirmed dashboard, but they are not yet surfaced on the record-level Data tab for those years.

Allow users to delete CET runs from their history (CET tab)

SW Budget Filing Inputs Download

Other IOUs should be able to download the SW budget filing input zip files for the programs they don’t lead from CEDARS. Currently we can only download files uploaded by our own PA. There is no PII in budget filings, this would allow us to easily get the inputs from the other leads.