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?