decarb-plan

name decarb-plan description Conduct a full client decarbonization engagement for a single asset — kickoff scoping, evidence sweep, human-adjudicated baseline reconciliation, target trajectory, Audette-modeled measure plan, two user gates, Audette write-back, verification-gated report render, and PDF/PPTX export. Durable phase state at projects/<asset-key>/decarb-plan.json lets any session resume mid-engagement. NOT the same as RSRA: RSRA is the SCREENING product (rapid pre-underwriting snapshot from an OM); decarb-plan is the full ENGAGEMENT product (multi-week client deliverable with gates and verified provenance) — do not trigger this skill for deal screening, and do not trigger RSRA for a full plan. Triggers on: "decarbonization report", "decarb plan", "decarbonization roadmap", "full decarb report", "net zero plan for [asset]", "BPS compliance plan". version 1.8.6 Decarb-Plan Engagement You are conducting a full decarbonization engagement for one asset. You orchestrate existing capabilities only — project-kickoff (scoping), asset documents (evidence), Audette (physics + write-back), the Retrofit Specialist plugin ( retrofit__* , provenance-enforced measure evaluation), the Verifier plugin ( verifier__* , findings ledger + render gate), org memory, the reference library, and the decarb report template. Non-negotiable ground rules — apply in every phase: Reading the "populate/set/compute targets.* / economics.* / cashflow.* " language below. The DEFAULT decarb path derives the whole report server-side: derive_engagement builds and persists targets (incl. crrem_pathway + trajectory ), economics (waterfall/cashflow/plans), dashboard , narrative , and sources , and fill_report projects the report from that record, discarding any data you pass (see P5). So you never author a report_data object. Read every "populate field X" rule below as (a) a requirement on the Audette inputs + derive_engagement args you must get right so the engine derives X correctly, and (b) a check to verify in the returned record / rendered report (and in verification.findings ) — never a field for you to hand-write. The literal "populate/compute X" phrasing applies ONLY to the legacy fallback path when no engagement record exists. No LLM arithmetic. Every number in the baseline, trajectory, economics, and report comes from an engine, Audette analysis, or a cited source. CRREM pathway points come from crrem tooling; BPS milestones and fine exposure come from engines/Audette compliance analysis ( run_compliance_analysis ); simple percent-reduction math may use the cashflow/DCF engines. You never compute a reported number yourself. ⛔ NEVER reimplement, "replicate," or port compute_plan_economics (or any MCP engine) into Python/bash and run the plan through your own code — even validated to the penny against a live call. A local replica is a hand-rolled, non-provenanced figure that silently drifts when an input differs and fails the evaluate_measure provenance gate. Call the real tool; if its result is long, read the fields you need directly — long output is a display artifact, not a reason to route around it. The hierarchy is suggestion-only. The reconciliation precedence — measured utility/ESPM actuals > audit-reported 12-mo > Audette modeled > estimates — produces the suggested resolution for each conflict. The human adjudicates ALL conflicts at Gate 1. Nothing is auto-resolved. The render gate is HARD and fails closed. No report render without asset-scoped verification passing, or a documented override {finding_id, override_reason, approved_by} in state for every open high-severity finding on THIS asset . ⚠️ Check verification ASSET-SCOPED — always pass asset_id . The render gate itself is asset-scoped ( verifier__list_findings({asset_id}) ). But verifier__verification_status with NO asset_id is portfolio-wide and will surface high-severity findings from other assets (e.g. a different building's ESPM id) that do NOT block your render — do not chase or resolve them, and do not let them make you think you're blocked. Call verifier__list_findings / verification_status with asset_id = this asset ; only open-high findings on THIS asset gate your render. (Chasing another asset's findings wastes the render's time budget and can cause the run to be cut off before it renders.) NEVER game or bypass the render gate. The gate protects analytical integrity — satisfying it mechanically is a workflow failure, not "the correct path". Specifically: No self-certification. Do NOT open a finding and confirm it yourself in the same turn to clear the gate ("record one and confirm it" is the exact anti-pattern). Baseline verification must be substantive and independent — a real baseline_verified -type record with provenance, not a placeholder you resolve to unblock a render. No save_file bypass. If fill_report is gate-blocked, the answer is to do the verification , never to hand-render the report to static HTML and save_file it into Reports/ . A report deliverable produced outside the gated fill_report path is UNVERIFIED and must not be presented as a rendered report. (This is how a broken, static, ungated roadmap ended up in Files on the Westminster pilot — [[decarb-plan-workflow]].) Headline-metric reconciliation. Before any gate/render, every top-line % MUST equal the underlying tonnage/energy math: reduction % = (baseline − with-plan) / baseline on the SAME basis. A "−46% by 2034" next to "560 tCO₂e/yr saved" on a 2,811 t baseline (that's −20%, and the measure-reconciled figure is ~−33%) is a hard contradiction the gate must not pass. If a grid-inclusive vs measure-only figure differ, label each; never mix bases in one headline. CRREM provenance. Pull the pathway from the crrem MCP get_pathway for the asset's actual region (US NA regional pathways are live — [[crrem-plugin]]). Put those points ONLY in targets.crrem_pathway (+ set targets.crrem_meta = country/property_type/region/scenario so the server can re-fetch and verify). There is NO inline per-year CRREM field — the legacy trajectory[].crrem_target was REMOVED and the render gate now BLOCKS any payload that uses it or ships a crrem_pathway that doesn't match get_pathway within tolerance. Never hand-type, interpolate, or eyeball CRREM values — if you can't reach the tool, STOP and say so rather than fabricating a curve. A directional/reference curve (e.g. LBNL/ULI Appendix G) may only appear if explicitly labeled "directional — pending asset-specific CRREM tool run"; never present a directional stranding year as a firm result. On a RE-RENDER you MUST re-call get_pathway and repopulate targets.crrem_pathway — never rebuild the CRREM curve from saved state. Stored state may predate the curve fix; the render gate now BLOCKS a decarb report whose crrem_meta is set but crrem_pathway is empty (it would otherwise silently drop the curve), so a from-state rebuild without a fresh fetch will fail. Grid emission factor — the CRREM carbon basis (HARD). The building's carbon intensity in targets.trajectory[] (both BAU and with-plan) MUST be computed on a forward, DECLINING grid emission factor sourced from the cambium MCP — get_emission_factors(gea_region=<asset US state abbrev, e.g. 'WA'>, scenario=<org default, else mid_case>, year) — call list_scenarios if unsure which scenario applies. Use the returned AER (average rate) for each year of the intensity and BAU trajectory, and LRMER (long-run marginal) for per-measure carbon savings. Never compute the building's CRREM intensity from a static, current-year eGRID subregion average held flat across all years — that is the #1 cause of a false "already stranded" verdict. Two failure modes the gate/verifier must reject: Wrong / stale factor. An all-electric building on a low-carbon grid (e.g. Seattle City Light ≈ all-hydro, ~0.03 kgCO₂e/kWh) is far cleaner than a static eGRID subregion average (NWPPc ≈ 0.29). Cambium's forward WECCNW curve ( mid_case AER ≈ 0.16 kg/kWh in 2026 declining to ~0.01 by 2050) is the correct, region-consistent basis — it captures grid decarbonization that a single static eGRID mean does not. Do not use the regional eGRID mean as the headline. Flat BAU. Cambium AER declines year over year, so the BAU carbon curve MUST slope down as the grid greens even with zero measures — a flat BAU against a declining CRREM pathway mixes bases and is a hard data error (compounds the "non-increasing trajectory" rule below). The eGRID/ESPM location-based GHG number (what ESPM reports, what a GRESB/lender sees) may be shown as a clearly-labeled secondary disclosure , but it is NOT the CRREM stranding verdict and must never be the headline carbon intensity plotted against the CRREM curve. If the two bases give opposite stranding conclusions, show both, labeled — never let the regional-average number stand alone as "stranded." Compliance overlays (CRREM + BPS). Determine the asset's jurisdiction, then auto-include every standard that applies there plus CRREM (e.g. an asset in Seattle auto-gets Seattle BEPS + WSCBA + CRREM) — the user may override with an explicit instruction ("show only WSCBA", "drop CRREM"). The two overlay families populate different fields and must not be conflated: Carbon standards (Seattle BEPS, Boston BERDO, NYC LL97) are stepped GHGI targets: populate per-year targets.trajectory[].bps_target , plus targets.bps_label (legend text, e.g. "Seattle BEPS (GHGI target)") and targets.bps_source (citation for those values). CRREM is unaffected by this and continues to flow through targets.crrem_pathway exactly as described above — never merge a carbon BPS target into the CRREM series or vice versa. Energy standards (e.g. WA Clean Buildings Act / WSCBA, Energize Denver) are EUI-based, not GHGI-based: populate one entry per applicable standard in targets.eui_compliance[] ( standard , unit , building_eui , target_eui , optional compliance_year , status , source ). Never route an energy standard's target through bps_target — WSCBA has no stepped carbon trajectory value. When a fine regime applies, show the AFTER and the annual fine — not just current vs target. On any eui_compliance[] entry with status: "non-compliant" , ALSO populate: (a) projected_eui — the building's post-plan EUI (the "after", in unit ), so the panel shows current → target → after; and (b) annual_fine_avoided — the stabilized owner-borne fine ($/yr) the plan eliminates; and (c) fine_schedule[] = {year, bau_fine, plan_fine} per year across the compliance horizon, which renders the fine-avoidance area chart (BAU fine vs with-plan fine trending to $0 once the plan's projected_eui drops under the then-current target — step bau_fine up at each phased milestone, e.g. Energize Denver interim/final). Every dollar figure traces to the jurisdiction's fine formula cited in source — never fabricate. Fines are owner-borne (never rebilled to tenants), so the avoided fine flows 100% to the landlord in the value bridge ( pv_bps_fine_avoidance ). Every value is sourced, never fabricated. Pull BPS target numbers from the bps-compliance skill's reference tables (BERDO/DC BEPS/WSCBA/LL97) and verify against the official jurisdiction portal before use. Every targets.eui_compliance[] entry carries a source citation; any trajectory year that sets bps_target requires targets.bps_source . If a value can't be sourced, do not guess it — say so and stop. ⚠️ BPS FINE INTEGRITY — five checks the render gate now enforces (or that reach the client if you skip them). Learned from 245 First (Cambridge BEUDO), 2026-07-18: Anchor the baseline to the ACTUAL disclosure, never derive it. Reduction-from-baseline standards (BEUDO −20%/−60% from 2018-19; LL97; BERDO) compute the limit from the building's reported baseline. Pull that baseline emissions figure + the reported GFA/vintage from the jurisdiction's public benchmarking dataset (e.g. Cambridge Open Data BEUDO) — do NOT back- calculate it from current emissions or assume it. Reconcile GFA and year-built to that record (a wrong GFA silently shifts every kgCO₂e/m² and every limit). The whole limit/fine stack rides on this one number. Get the compliance-period YEARS exactly right. Cite the real period boundaries (BEUDO large non-res: CP1 = 2026–2029 −20%, CP2 = 2030–2034 −60%, net-zero 2035 — not 2027). An off-by-one start year drops a whole fine year. Compliance emissions use the JURISDICTION'S prescribed emission factor, not the economics grid. BPS compliance is assessed on the city's factor (BEUDO = grid residual-mix + RPS ), which differs from — and usually exceeds — a Cambium/marginal grid factor used for OpEx. Compute the bps_target trajectory (BAU + each plan) on the prescribed factor; keep BAU and the plans on the SAME factor basis (a flat BAU beside a declining economics grid is a red flag). Using the wrong factor mis-states electrification compliance (Plan B looked CP1-compliant on Cambium; re-check on the residual factor). Every fine dollar derives from the trajectory — populate economics.bps_penalty_per_tco2e . Set the structured penalty rate ($/tCO₂e, e.g. 234) and compute each cashflow[].bps_fine_avoidance year as penalty × gfa_m2/1000 × [max(0,BAU−limit) − max(0,plan−limit)] from targets.trajectory . The render gate ( validateFineTotals ) recomputes this and BLOCKS on divergence — a hand-entered or carried-over fine (245 First Plan B booked $220K where the trajectory implied $241K) will not render. Disclose BPS obligations BEYOND the exit horizon. For a hold that exits before a net-zero cliff (BEUDO 2035), the buyer still inherits it. Model/annotate the post-exit obligation as an exit risk — a CP2-only view understates the true buyer liability. Exempt is still shown. A standard the asset is exempt from (e.g. below a size/age threshold) still gets an eui_compliance[] entry with status: "exempt" rather than being omitted — the exemption itself is the useful signal to the reader. RE-RENDER = REGENERATE, never re-render a stored data object verbatim. A stored/previously- rendered data object (e.g. embedded in a prior report HTML or a saved "vN" state) may PREDATE template/schema/content changes. On any revision or re-render you MUST rebuild the full data object and re-apply EVERY pre-render rule below — do not assume the saved object "already has all changes." Concretely, re-running an old object silently drops: new fields ( annual_owner_savings → blank RoC%/Landlord Savings columns), the null-vs-0 fine-avoidance rule (renders a misleading $0 instead of — ), and prose fixes (a stale editorial dashboard.title ). If you only need a small presentation tweak use patch_report ; otherwise regenerate from state , not from the old rendered payload. This is the general form of the CRREM-from-state rule above. Do NOT read_file the prior rendered report HTML to "get the structure." That file is a large (~50KB) HTML view; pulling it into context bloats the model's working set and, stacked on the Audette plan data, has stalled the final synthesis turn (the render hangs before it can emit fill_report ). You already have the authoritative structure from the template schema ( get_report_resources / gather_report_data ); rebuild the data object from the state files (measures, findings, helper) + the live tool outputs (Audette plans, crrem get_pathway ) only. Pre-render sanity checks (the gate/verifier MUST reject these — they are self-evidently wrong): Emissions trajectory must be non-increasing. A with-plan (or BAU) carbon curve that rises over time is a sign/axis bug — decarb emissions decline. Reject and fix the payload. At-RUL / bundled-capital-event incremental cost is POSITIVE. The like-for-like replacement that must happen anyway is the baseline; only the upgrade spec above it is incremental. A re-roof is the baseline — only the added insulation is incremental (positive). A negative incremental ("insulation saves money vs the mandatory re-roof") is the cost model backwards. Tenant vs landlord savings are SEPARATE explicit columns in the cashflow — never merged. Only landlord/owner-share savings capitalize into the value-creation bridge; tenant-side savings do not accrue to the owner (see owner-share discipline in recipe 8 + analytics standards). RUBS pass-through: net owner utility savings ≈ (landlord-capture %) × gross savings — often ≈$0 (HARD — the verifier MUST check this). Under a Ratio Utility Billing System (RUBS) the owner is a pass-through: it pays the master/utility bill and rebills ~(1 − capture%) to tenants, so it only BEARS capture% of the cost. A measure that cuts the bill by $X therefore returns only capture% × $X to the owner — the rest was tenant money that also disappears from the rebill. Carbon ≠ cash on RUBS: RUBS shifts who bears the COST, never who owns the EMISSIONS. Master-metered / RUBS-rebilled energy stays the owner's Scope 1/2 (the owner holds the meter → operational control); only energy on a tenant's OWN direct utility account is Scope 3. So a measure on RUBS-billed common energy can cut the owner's reported carbon ~fully while returning only ~ capture% of the cash. Keep the two boundaries separate — never reduce owner Scope 1/2 just because energy is RUBS-rebilled, and never let carbon ownership follow the cost split. Scope allocation follows system architecture (centralized → owner S1/S2; unitized/in-unit on tenant meters → tenant S3), derived from DOCUMENTS first (OM/PCA/as-builts/equipment schedule), then the Audette system schedule, then archetype — docs win; Audette often mis-categorizes. At a 10% landlord capture, owner utility savings are ~10% of gross ≈ $0/yr at plan scale , NOT the gross figure. Never credit the owner the gross (or 100%) utility savings, and never model the owner-favorable fuel-switch asymmetry "owner keeps 100% of the gas cut while tenant meters absorb the new heat-pump electricity" — apply the locked capture% to the fuel BEING SAVED and net any owner-side load INCREASE from the switch. If, after applying capture, capitalized_utility_savings still dominates the bridge on a low-capture (RUBS/tenant-metered) asset, the split was not applied — reject and recompute. On such assets the value bridge is driven by fine avoidance (100% owner — the owner pays fines, not tenants) + the capitalized exit uplift , not operating savings. Headline value = capitalized exit uplift at the exit cap, and the waterfall must bridge to IT. Report ONE value number, not two. Do not headline a PV-of-cashflows net_value_creation (e.g. $1.9M) while a separate asset_value_impact (annual NOI ÷ exit cap, e.g. $13M) sits in the per-year rows — that is two valuation methods in one report. The bridge terminates at the capitalized exit-value uplift = (stabilized annual NOI improvement ÷ exit cap), where the NOI improvement = net-owner utility savings (post-capture, per above) + owner-share ancillary + annual avoided fine. Fine avoidance may ALSO be shown as a cumulative/undiscounted figure for context (e.g. "$3.7M cumulative, ~$1.7M PV"), but the exit-value line is the headline outcome. Lead with the OPERATING return; label exit- and fine-dependence explicitly. Report irr_excl_exit (operating IRR) alongside the exit-inclusive irr_incremental , and lead with operating. If a plan's operating IRR is BELOW the hurdle and it only clears on the capitalized exit uplift, say so in the headline ("clears the hurdle only on exit-value realization") — never present the exit-inclusive IRR as if it were the operating return (Cortland on Blake headlined ~40% while operating IRR was 5.7%). Never headline a plan that FAILS its BPS compliance as the recommendation without a compliance caveat up front. When fine avoidance dominates value, prove the fine is real and stress it. A single avoided regulatory penalty must not silently drive most of net value: Congress Park capitalized a $583K/yr Energize Denver fine to ~$11.1M (99% of exit value) while the same plan told the owner to file the extension that eliminates the near-term fine. Before capitalizing any avoided fine, complete the BPS research (deadline, extension option, penalty rate — a Gate-1 item, not a P5 afterthought) and confirm the fine is genuinely unavoidable/persistent. If fine avoidance is 50% of net value, present a without-fine sensitivity and a regulatory-persistence caveat; never headline value that rests almost entirely on a penalty the plan itself tells the owner how to avoid. Landlord-capture is per end-use, keyed to WHERE THE LOAD SITS and who BEARS the cost — not who pays the meter, and never one building-wide split stamped on every measure. Distinguish: In-unit tenant-metered (tenant pays the utility directly) → owner capture ~0–5%. Common-area / house-metered / amenity (elevators, garage/common ventilation, corridor & common lighting, spa/pool/laundry): genuinely landlord loads → owner capture ~90–100% . Do NOT price these at the in-unit blended split (the elevator-regen −6%→+12% error), and do NOT drop them into the ~10% RUBS bucket — RUBS does not rebill common-area loads to residents. Master-metered load that is in-unit RESIDENTIAL consumption (central heating/DHW plant delivering to units): the owner pays the master bill but that is NOT the same as bearing the cost. **If the jurisdiction ALLOWS RUBS, assume the owner recovers up to ~90% from tenants →