Scope Change, an Overwritten Baseline, and a Dual-Purpose Request
A consulting firm is modeling a 300,000 ft² hospital retrofit for a utility custom-incentive program. The program requires a baseline reflecting 12 months of pre-installation conditions and a 10-year savings claim. Three weeks before submission the owner changes scope: the chiller replacement is dropped, and a BAS recommissioning effort plus a 500 kW PV array are added. Meanwhile a junior modeler has overwritten the file 'baseline_final_v2,' the assumptions log has not been updated since March, and the client asks whether the same model can be submitted both to the utility and to a green-building certification that uses Appendix G.
1. List, in priority order, what you do in the next three weeks and what you tell the client.
Read the worked answer
Priority 1 - recover or reconstruct the baseline. Do not simply rebuild from memory. Exhaust, in order: server backups and shadow copies, earlier file versions, the junior modeler's local drive and email attachments, and - critically - the simulation output reports from prior runs. Output reports plus the March assumptions log often let you reconstruct the input set well enough to defend the numbers. If reconstruction is impossible, rebuild from the as-built drawings and the 12-month utility data and disclose the change and its effect on the reported savings.
Priority 2 - institute version control today. Locked baseline file, dated names (not 'final_v2' - use project_baseline_YYYY-MM-DD_rN), a change log with who changed what and why, and one named owner per file.
Priority 3 - get the scope change in writing. What is in, what is out, who owns the PV production estimate, the revised delivery date, and the revised fee. A dropped chiller and two added measures three weeks before submission is a change order, not an email.
Priority 4 - re-scope technically.
- Recommissioning is not a physical change. You cannot model it by adding equipment. Savings must come from an operational baseline - schedules and setpoints as found versus as corrected - evidenced by trend data. Flag now that the program may not accept modeled commissioning savings without measurement and verification.
- PV is a supply-side measure and belongs outside the building model (see next task).
What you tell the client: the three-week date is not achievable with a defensible baseline; propose a phased submittal - building measures first, PV and commissioning in a second tranche - or a revised date. Saying this now is far cheaper than a rejected submittal.
2. How should the 500 kW PV array be treated in the model and in the savings claim?
Read the worked answer
Outside the building energy model, and separately documented.
Modelling: PV is on-site generation, not an efficiency measure. Represent it as a separate supply-side meter or as a post-model calculation; never place it in the baseline, and never net it into the building's modeled EUI without a clear label. Its production depends on irradiance, array tilt and orientation, inverter efficiency, soiling, shading, and degradation - none of which the building simulation engine should be inventing. Use a dedicated PV model and carry its assumptions separately.
Program rules: most custom-incentive programs pay for efficiency (kWh saved at the meter from building measures) and treat on-site renewables on a separate track, often ineligible for the efficiency incentive. Check before assuming it counts. There is also a double-counting trap: ECMs reduce consumption, PV reduces delivered electricity, and if both are measured against the same pre-installation baseline the same kWh can be claimed twice.
Reporting: three separate lines - baseline consumption, post-ECM consumption, PV production - with the net only shown as a clearly labelled derived figure. The 10-year claim needs PV degradation stated explicitly rather than held flat.
Also flag to the client: a 500 kW array on a hospital is likely sized to a specific investment or net-metering cap, and the savings claim should reconcile to that sizing intent rather than to whatever the model happens to produce.
3. The client asks whether the same model can serve both the utility program and the Appendix G certification. How do you answer?
Read the worked answer
No - not the same model file, and not the same baseline. Say so clearly and price the extra work.
Why the baselines are incompatible:
- Utility program: baseline = existing conditions, built from the as-found building and validated against 12 months of pre-installation bills.
- Appendix G: baseline = a budget building generated from the proposed design, with prescribed system types, efficiencies, and schedules defined by the edition in force. It is a hypothetical code-minimum building, not the building that exists.
These are different buildings. Attempting to serve both from one file produces a baseline that satisfies neither reviewer.
What can and should be shared: geometry, thermal zoning, envelope constructions, internal load densities where the rules permit, and above all the design/proposed model - maintain it as the single source of truth. The Appendix G baseline is then generated from it by substituting prescribed systems and efficiencies; the existing-conditions baseline is built independently from the survey.
Other divergences to check before promising anything: treatment of unregulated and process loads (significant in a hospital), the 90.1 edition each program cites, which may differ, weather file requirements, and the unmet-load and calibration criteria each imposes.
Deliverable package for either path: design model, each baseline as a separate file, assumptions log, change log, input and output reports, weather files, and a limitations statement. Naming the second baseline and the additional QA as a fee-bearing scope item is not bureaucracy - it is the difference between a submittal that survives review and one that does not.