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.

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.

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

Export Load Shape Library Table

As a user of the Load Shapes Library, I want to export the library table to CSV or Excel, so that I can more easily search, filter, and review the full list of load shapes outside the application. Description Add an export function that lets users download the load shape library table (currently containing thousands of entries) as a CSV or Excel file, since searching/filtering within the current table interface is difficult at this volume.

eTRM Sync – Skip Measure Packages with Missing Draft References

Some eTRM records may reference a draft_measure_package_id that does not have a corresponding draft Measure Package record. When this occurs: Skip the affected Measure Package and continue syncing valid Measure Packages. Show the skipped Measure Package on the eTRM Sync History page being released as part of @Improve eTRM Sync Resilience for Invalid Measure Package Data. Include the reason it was skipped, for example: draft_measure_package_id referenced in impact_profiles_latestpermutation was not found in impact_profiles_draftmeasurepackage.

2026 Avoided Cost Calculator Update

The CET will require ACC table updates when the ACC updates are finalized in Q4.2026. There will undoubtedly be subtasks; this ticket is essentially a placeholder.

Access to prior CET versions

As an evaluator for the CPUC, I need to run evaluation data updates through the CET. However, this requires that the CET for that year be available with the correct specification and other database requirements. Alternatively, we need an efficient way to run CETs for prior versions. It needn’t be in production; at this stage we need the most straightforward pathway. If CET access needs to be limited in scope, then we can provide you with the year(s) for which we need access to an old CET version. Please contact me, Corina Jump, and Rachel Harcharik to discuss. Thank you!

Support Load Shifting Where Base and Measure UECs Are Equal

As a Measure Developer, I want CEDARS to accommodate measures with equal base and measure UECs so that future load-shifting measures can represent changes in consumption timing even when there are no overall energy savings. Investigate support for load-shifting scenarios where base and measure UECs are equal. Current calculations can result in a 0/0 condition, and supporting this may require changes to Impact Profile generation, avoided cost, and TSB calculations. Eligibility requirements for deemed measures also need stakeholder discussion.

Claims – Validate Claim.ClaimType Against Allowed Value List

As a Program Administrator and someones reviewing claims data, I want Claim.ClaimType to only accept valid claim type values, so that claim data remains consistent and invalid values are prevented from being submitted. The Claim.ClaimType field is intended to only accept the values defined in the Claim Specification Value List: Deemed Custom Currently, no validation is applied to this field. As a result, Program Administrators have been able to submit unsupported values (for example, NMEC), leading to inconsistent data. Update validation so that Claim.ClaimType must match one of the values defined in the Claim Specification Value List. Field Claim.ClaimType Reference Value List: https://cedars.cpuc.ca.gov/claims/specification/values-list/claim-type/

Allow users to reference load shapes in their CET input data instead of impact profiles

This would eliminate the need to pre-calculate impact profiles for every possible combination of load shapes in advance. This would also allow dual baseline measures to use the correct impact profile for the early retirement phase and the above standard phase of their measure, instead of having to use one impact profile for both baselines as the CET works currently.

Display UEC proportion values when selecting draft measure package

As a Measure Developer, I want to see proportion UEC values when selecting a Measure Package so that I can confirm I am uploading load shapes against the correct eTRM version. Description Multiple versions of the same Measure Package can appear in CEDARS following draft commits or discards in eTRM. The current Measure Package Values table does not display UEC proportion values, making it difficult to determine which version should be used. Selecting the wrong version may result in Impact Profiles and Avoided Cost Combinations being generated using outdated savings assumptions.

Support Baseline Tech Group and Tech Type in Load Shape Uploads

As a Measure Developer, I want CEDARS to recognise baseline technology information separately from measure technology information so that I can upload baseline load shapes using their correct Tech Group and Tech Type values. Background CEDARS currently only synchronise the measure case Tech Group and Tech Type from eTRM permutations. As a result, both measure and baseline load shapes are expected to use the measure case values during upload. For example: Measure: SWWH031-07 Measure Tech Type: HP_COP Baseline Tech Type: Stor_UEF Although the Tech ID correctly identifies the baseline technology, uploads currently fail unless the baseline load shape is generated using HP_COP. This behaviour has caused user confusion and ongoing troubleshooting effort.

Load Shape User Guide

As a Measure Developer or Program Administrator, I want clear documentation explaining how to use the Load Shape Library tool, so that I can correctly prepare, upload, load shapes.

Improve visibility of Impact Profile generation outcomes for Load Shape uploads

As a Measure Developer uploading deemed load shape 8760s, I want to see which Impact Profiles were generated, updated, or reused so that I can understand what impact profiles were generated or failed, and identify any existing impact profiles that were replaced. Following a load shape upload and Impact Profile generation, Measure Developers currently have limited visibility into what processing occurred. Users cannot easily determine: Which Impact Profiles were newly generated Which Impact Profiles failed to generate If possible why they failed to generate Which IOU AC territories and climate zones were impacted Whether existing Impact Profiles were replaced by the upload This lack of transparency makes it difficult for users to validate processing outcomes, troubleshoot issues, and understand the downstream impacts of their uploads. The summary should support partial success scenarios where some Impact Profiles generate successfully while others fail. Processing failures should only roll back the affected Impact Profiles and should preserve any unrelated or previously existing data. Related to bug ticket: https://cpuccedars.featurebase.app/p/load-shape-impact-profile-generation-can-become-stuck-after-errors Related to ticket around better visibility and traceability between eTRM and CEDARS: https://cpuccedars.featurebase.app/p/load-shapes-improve-traceability-and-visibility-of-load-shape-techid Proposed Improvement Introduce an Impact Profile generation summary, using the existing Claims QC Summary pattern as the UX model, to provide users with clear visibility into processing outcomes. The summary should display: Impact Profiles successfully generated Existing Impact Profiles updated Existing Impact Profiles reused with no changes Impact Profiles that failed to generate Associated IOU service territories Associated climate zones

Revise label at y-axis of load shape graph within Load Shape Library

Hi, CEDARS Team. Please update the y-axis label for the load shape from “Unit Energy Consumption” to “Monthly Average Normalized Energy Consumption”. Thank you!