PG&E outlines RAMP data-template approach; discussion focuses on RRU granularity, CSV/SQL tradeoffs and NPV reporting

Pacific Gas and Electric Co. presented a draft Risk Assessment Mitigation Phase (RAMP) data template and a companion ‘‘RRU supplemental’’ table intended to link project-level information to mitigation-level risk results, PG&E representatives said at a California Public Utilities Commission technical working group session.

The PG&E presentation, led by Elijah and Vincent Loh and Yumi Boon, described a set of tabular outputs derived from the utility’s earlier transparency pilot and a joint IOU proposal for reporting risk-reducing units (RRUs). ‘‘We use that as our kind of starting basis for our RAMP data templates,’’ Vincent Loh, a representative for PG&E, said during the session. He noted the transparency pilot was filed in R.20-07-013 on Aug. 5.

Why it matters: the templates are meant to let parties and regulators trace how high-level risk reductions reported at the mitigation level map to individual projects or RRUs, while keeping the dataset queryable for analysis. Participants and utilities discussed trade-offs among file size, format, and analytic flexibility — whether data should be delivered as CSVs for database queries or as denormalized Excel spreadsheets for easier ad-hoc sorting.

PG&E’s proposal and the RRU supplemental table

PG&E described three core tables from the transparency pilot — the risk results table, a sensitivity table and a risk model listing — and proposed a supplemental table linking RRUs to risk tranche, year, mitigation and attribute. The RRU table would include RRU name, description, status, estimated contribution (a percent attributed to the mitigation’s risk reduction) and estimated cost. PG&E said the approach is intentionally flexible: ‘‘additional results types can be added as necessary,’’ one presenter noted when describing how different result types (for example, ‘‘risk before’’ and ‘‘risk after’’) can be represented.

How the join works and what ‘‘RRU’’ means

PG&E said the risk results table is keyed by risk, tranche, year, mitigation and attribute; the RRU supplemental table would join on that same set of keys and then list one or more RRUs that roll up to the mitigation-level row. PG&E clarified that a single risk tranche and mitigation can contain multiple RRUs and that an RRU can span years or be split into per-year entries depending on how the utility records projects. ‘‘RU name might be project number 1, project number 2, project number 3. They all work on the same risk. They all work on the same tranche,’’ a PG&E presenter said.

Attribution of contribution and cost reporting

Participants pressed PG&E on what ‘‘RRU estimated contribution’’ means. PG&E clarified that the contribution percentage is intended to represent the share of the mitigation-level risk reduction attributable to an RRU for that tranche-year; PG&E said that, when detailed project-level information is missing far in advance, utilities would supply placeholders that sum to the mitigation-level total and refine them in later updates. PG&E also said the cost column in some submitted examples reflects a present-value (NPV) number pulled from more granular year-by-year CapEx and OpEx inputs.

NPV, discounting scenarios and result types

Parties asked how present-value calculations, cost–benefit ratios and different discount-rate scenarios would appear in the tables. PG&E said the data model is flexible: result types can be extended to represent different discounting scenarios or NPV calculations (for example, a result-type entry labeled with the discount scenario). PG&E also said the raw inputs at year-level granularity are available and that the single cost figure in the mitigation-level example was an NPV of multi-year capital and expense forecasts.

File format, scale and analytic tools

A central thread of discussion concerned file size and usability. PG&E’s output is a set of CSV files derived from Python code that reads the utility’s RAMP workpapers; PG&E stressed the files are database-friendly but cautioned that very granular denormalized tabular exports can be enormous. ‘‘Excel is kinda dangerous. Sometimes you read the file in, it only shows you the first million rows,’’ a PG&E representative said, urging parties to use database or pivot approaches for large datasets or to request focused extracts.

Sensitivity analysis and estimate quality

PG&E’s transparency pilot includes a sensitivity table and an ‘‘estimate quality’’ (EQ) score that rates the confidence of reported values. PG&E said sensitivity work (showing how small parameter changes change risk results) was completed for some risk areas but not all; parties asked for broader sensitivity and for tools that allow analysts to test alternate mitigation-effectiveness assumptions. PG&E agreed the sensitivity table can guide where to focus further detail but said full non-linear scenario testing is resource-intensive.

Portfolios, SB 884 and alignment with other reporting

Several participants pressed PG&E on how the RAMP template would accommodate portfolio-level comparisons (for example, comparing overhead hardening vs. undergrounding alternatives) and whether SB 884 and OAIS-derived requirements (which apply to undergrounding plans) should be captured consistently. PG&E said the model can represent portfolios by grouping mitigations and computing post-mitigation portfolio risk, but cautioned that modeling interactions among many overlapping mitigations can be complex and that portfolio comparisons have previously been done on a case-by-case basis rather than as a universal automated output. PG&E also said it would consider adding mitigation-specific supplemental tables where wildfire or other risks need extra detail.

Next steps from the workshop

Workshop participants and hosts agreed on a few immediate follow-ups: PG&E offered to share a live demo and the CSV outputs from its transparency pilot; the meeting facilitator said the Safety, Policy & Development team (SPD) would collect unanswered chat questions and circulate responses; and the workshop summary will be drafted by Sempra and circulated to participants for comment. No formal regulatory decision was made at the session.

Ending

Stakeholders signaled interest in continued work to balance database-ready normalized tables with user-friendly extracts for analysts who may not run SQL queries. Participants urged PG&E and other utilities to consider focused export subsets and clear instructions or example queries to help users reproduce common analyses without needing custom code.

Quotes included in this article are verbatim excerpts from the meeting transcript and are attributed to speakers listed in the meeting record.